trailofbits/open-sourcing

Ouvrir un dépôt en open source

Préparer un dépôt pour une publication publique afin qu'un externé sans contexte préalable puisse le construire, l'utiliser et y contribuer — et qu'aucune information sensible ne soit diffusée avec. Suivez les étapes dans l'ordre ; l'audit des secrets vient en premier car son résultat (conserver ou recréer le dépôt) affecte tout le reste.

Quand utiliser

• Rendre un dépôt privé public
• Auditer un dépôt public existant pour sa qualité de publication (« le rendre officiel »)
• Choisir une licence pour un projet
• Configurer le packaging, le versionnage ou l'automatisation de publication avant un lancement public

Quand NE PAS utiliser

• Développement courant sur un projet déjà publié (pas d'événement de publication)
• Audit de code tiers pour des vulnérabilités (utiliser une compétence de revue de sécurité)
• Publier un package depuis un dépôt qui restera privé — seules les étapes de gestion de publication s'appliquent ; ignorez le reste

Workflow

Étape 1 : Détecter le profil de l'organisation

bash {baseDir}/scripts/detect_org.sh

Le script inspecte les dépôts distants git et les emails des derniers contributeurs, et affiche un nom de profil. S'il affiche trailofbits, lisez references/trailofbits.md maintenant et appliquez sa politique de licence, ses comptes de publication et ses notes de processus tout au long des étapes suivantes. S'il affiche generic, procédez uniquement avec les conseils génériques. Si l'utilisateur dit que la détection est erronée, faites-lui confiance.

Étape 2 : Auditer les secrets — avant toute autre chose

Un dépôt qui a jamais contenu des secrets (clés API, identifiants, données clients) ne doit pas être rendu public. La réécriture de l'historique est sujette à erreur et n'atteint pas les forks, les caches ou les artefacts CI. La solution fiable est un dépôt frais : copiez l'arborescence actuelle, commitez, et archivez l'ancien dépôt en privé.

1. Demandez si le projet a déjà manipulé des secrets ou des données confidentielles clients. Pour un outil de conseil en sécurité, demandez également si les fixtures de test ou les exemples de données provenaient d'engagements clients.
2. Scannez tout l'historique avec un outil dédié si disponible — gitleaks git . ou trufflehog git file://. — plutôt que de le faire à l'œil.
3. Vérifiez au-delà de l'arbre git : les journaux et artefacts GitHub Actions, les anciennes versions, l'historique des issues et PR, et le wiki du dépôt deviennent tous publics avec le dépôt.
4. Après être passé en public, activez la détection de secrets et la protection de push dans les paramètres du dépôt.

Rejetez ces rationalisations — c'est l'étape qui ne peut pas être corrigée après publication :

• « La clé a été révoquée, donc l'historique est correct. » Les identifiants révoqués divulguent toujours les noms d'infrastructure, les URL internes et les motifs que les attaquants utilisent pour cibler.
• « Nous allons réécrire l'historique avec git-filter-repo. » Les réécritures manquent les forks, les clones, les caches et les artefacts CI ; l'approche du dépôt frais ne le fait pas.
• « Ce ne sont que des données de test. » Les fixtures dérivées d'engagements clients ou de systèmes de production sont confidentielles quelle que soit leur étiquette.

Étape 3 : Exécuter la vérification de conformité

bash {baseDir}/scripts/check_readiness.sh

Le script affiche une liste de vérification des indicateurs de présence (README, LICENSE, CONTRIBUTING, SECURITY.md, IC, tests, tags semver, ...) et avertit des fichiers suivis qui contiennent couramment des secrets. Traitez les éléments non cochés comme des invitations à discuter, pas comme des échecs absolus — un prototype de recherche n'a pas besoin de tout ce dont une bibliothèque phare a besoin. Parcourez les lacunes avec l'utilisateur et corrigez celles qui comptent pour ce projet.

Étape 4 : Documentation

Le README est la porte d'entrée du projet. Confirmez qu'il explique :

• Ce qu'est le projet et le problème qu'il résout (premier paragraphe)
• Comment l'installer — gestionnaire de paquets, image conteneur, ou compilation depuis les sources ; une construction à partir d'un clone frais doit fonctionner en utilisant uniquement ce qui se trouve dans le dépôt
• Comment l'utiliser — au moins un exemple concret et copiable
• Comment contribuer — en ligne ou via CONTRIBUTING.md
• La licence — une courte section la nommant

Ajoutez également :

• SECURITY.md avec les instructions de signalement de vulnérabilité (une adresse de contact ou le signalement privé de vulnérabilité GitHub). Pour un outil de sécurité, c'est une condition sine qua non.
• Documentation API, construite et hébergée (GitHub Pages via CI est le chemin habituel), liée depuis le README et le champ site web du dépôt. Voir les références linguistiques ci-dessous pour les outils de documentation par écosystème.
• Un code de conduite si le projet attend des contributeurs externes.

Étape 5 : Licence

Pas de licence signifie pas d'open source, quelle que soit la visibilité. Lisez references/licensing.md pour les critères de sélection et la mécanique. La version courte :

1. Appliquez la politique de l'organisation si elle a été détectée à l'étape 1.
2. Sinon : Apache 2.0 comme valeur par défaut permissive, AGPLv3 lorsque la modification privée par les concurrents est une préoccupation réelle, Creative Commons pour les artefacts non logiciels.
3. Ajoutez le fichier LICENSE, définissez les identifiants SPDX dans les métadonnées du paquet, indiquez la licence dans le README, et vérifiez que les trois concordent.

Étape 6 : Tests et IC

• Confirmez que la suite de tests existe et passe ; un dépôt public avec une branche par défaut en échec signale un abandon.
• Assurez-vous que l'IC exécute les tests sur chaque PR, sur toute la matrice des versions de langage et des plateformes prises en charge.
• Imposez le formatage et le linting dans l'IC (outils par langage dans les références ci-dessous), afin que les débats de style n'atteignent jamais la revue.
• Respectez les outils existants. Ne remplacez pas un formateur, linter ou vérificateur de types fonctionnel dans le cadre de l'open-sourcing. S'il est en retard sur la génération actuelle (les références linguistiques nomment les outils actuels), avertissez le mainteneur et laissez-le décider ; seulement lorsqu'une catégorie est totalement absente — pas de vérificateur de types, pas de formateur — ajoutez la valeur par défaut actuelle.
• Envisagez un seuil de couverture qui fait échouer l'IC lorsque la couverture baisse.
• Renforcez les workflows eux-mêmes avant qu'ils ne deviennent une surface d'attaque publique :
  • Épinglez les actions tierces sur des SHA de commit complets ; activez Dependabot pour github-actions afin que les épingles restent à jour.
  • Définissez des blocs permissions: avec le moindre privilège (commencez par permissions: {}).
  • Auditez avec zizmor .github/workflows/ et lintez avec actionlint.

Étape 7 : Paramètres du dépôt

• Protection de branche sur la branche par défaut : pas de push forcé, PR obligatoires. Préférez les jeux de règles pour les nouveaux dépôts ; la protection de branche classique reste prise en charge.
• Protection des fusions : vérifications de statut obligatoires pour que les PR ne puissent pas fusionner avec des tests en échec.
• Dependabot ou Renovate pour les mises à jour des dépendances et des Actions. Regroupez les mises à jour pour réduire le bruit des PR, et définissez une fenêtre de temporisation (par exemple 7 jours) afin que les versions fraîchement publiées — et parfois détournées — vieillissent avant d'être adoptées.
• .editorconfig pour que les éditeurs des contributeurs s'accordent sur les bases des espaces.
• Étiquettes : créez-les dès que plus d'une issue ou PR en a besoin ; les préfixes pour les facettes évoluent bien (C: composant, P: plateforme). Voir les étiquettes de blight pour un exemple concret.

Étape 8 : Versions et versionnage

• Étiquetez chaque version vX.Y.Z, en suivant le semver ; utilisez les suffixes -rc.N / -pre.N pour les versions candidates et les préversions.
• Faites en sorte que les versions soient pilotées par l'IC : pousser une étiquette (ou publier une version GitHub) déclenche la construction, le packaging et le téléchargement sans étapes manuelles. Une version devrait être git tag vX.Y.Z && git push origin vX.Y.Z.
• Publiez les packages sous un compte appartenant à l'organisation, pas un compte personnel, et utilisez la publication de confiance (OIDC) au lieu de jetons à longue durée de vie partout où l'index le prend en charge.

Étape 9 : Pratiques spécifiques au langage

Identifiez les langages du projet à partir de ses fichiers marqueurs et lisez la référence correspondante pour le packaging, la publication et les outils de qualité :

Fichier marqueur	Référence
pyproject.toml, setup.py	references/python.md — délègue à la compétence python-moderne pour les outils
CMakeLists.txt, Makefile (C/C++)	references/c-cpp.md
Cargo.toml	references/rust.md
go.mod	references/go.md
package.json	references/javascript.md
Gemfile, *.gemspec	references/ruby.md

Pour d'autres écosystèmes, appliquez les principes transversaux : constructions reproductibles à partir d'un clone frais, versions pilotées par l'IC, publication de confiance ou comptes appartenant à l'organisation, et métadonnées de licence dans le manifeste du paquet.

Vérification finale

Avant de basculer la visibilité, vérifiez du point de vue d'un externé :

1. Clonez dans un répertoire propre et suivez les instructions de construction du README à la lettre — fonctionnent-elles sans connaissance tribale ?
2. Relancez {baseDir}/scripts/check_readiness.sh et confirmez que les lacunes restantes sont des choix délibérés, communiqués à l'utilisateur.
3. Confirmez que l'audit des secrets (étape 2) a bien eu lieu ; c'est l'étape qui ne peut pas être corrigée après publication.

Rendre le dépôt public est ensuite un changement de paramètres du dépôt. Accompagnez la publication d'une annonce là où l'organisation a un processus pour en faire une.

Ressources supplémentaires

Fichiers de référence

• references/licensing.md — critères de sélection de licence, métadonnées SPDX, forks et relicensing
• references/trailofbits.md — superposition de la politique Trail of Bits (chargée uniquement lorsqu'elle est détectée à l'étape 1)
• references/python.md, references/c-cpp.md, references/rust.md, references/go.md, references/javascript.md, references/ruby.md — packaging, publication et outils de qualité par langage

Scripts

• scripts/detect_org.sh — affiche le profil de l'organisation (trailofbits ou generic) à partir des dépôts distants git et des emails des contributeurs
• scripts/check_readiness.sh — affiche les indicateurs de présence pour les fichiers de préparation à la publication et signale les fichiers suivis qui contiennent couramment des secrets