Le code source est la matière première de toute la chaîne : le compromettre, c'est injecter du code malveillant à la racine, avant même le build. Le domaine Source & dépôt (SRC) est donc la première ligne de défense de la supply chain.
Avant d'être un artefact signé, un logiciel est un dépôt Git où plusieurs personnes poussent du code. Si un attaquant y glisse une modification sans revue, ou réécrit l'historique pour cacher ses traces, la compromission se propage à tout l'aval (build, artefact, déploiement), comme lors du piratage du dépôt PHP en 2021. La parade tient en un principe : aucune modification non revue, non tracée ni non signée sur les branches qui comptent. Chaque contribution suit alors un chemin contrôlé : un commit signé, une pull request soumise aux contrôles obligatoires (revue, CI verte, secret scanning, CODEOWNERS), puis la fusion sur une branche protégée à l'historique verrouillé ; en parallèle, les accès au SCM restent au moindre privilège et les forks sont isolés.
Concrètement, ces exigences parent : le push direct de code non revu, l'accès SCM volé sans MFA, le commit usurpé faute de signature, le secret poussé dans l'historique, et la PR de fork hostile qui exfiltre des secrets via le pipeline. Cette page couvre les 19 exigences SOCLE du domaine en quatre familles (protection des branches, intégrité de l'historique, accès au SCM, contributions externes), des fondamentales (R1) à la revue à deux personnes souveraine (R3).
Le dépôt est le point d'entrée du code : sans contrôle, on y injecte ou réécrit la source.
Les pièges à éviter
Section intitulée « Les pièges à éviter »Les erreurs les plus fréquentes sur ce périmètre :
Les exigences essentielles
Section intitulée « Les exigences essentielles »Cinq exigences transverses forment la base à satisfaire en priorité : branches protégées, MFA sur le SCM, signature des commits, détection de secrets et revue renforcée des forks.
branches protégées : revue obligatoire, pas de push direct.#
Un push direct sur la branche principale fusionne du code sans aucun regard : une erreur ou une malveillance passe sans filtre. Des branches protégées avec revue obligatoire imposent qu'un second œil valide chaque changement, premier rempart contre l'introduction discrète de code non vérifié.
- Preuve attendue
- Configuration de protection de branche : revue obligatoire, push direct interdit.
- Outillage
- Gitleaks Legitify
Correspondances & menaces parées 8 standards · 8 menaces
Une personne disposant légitimement du droit de publier (mainteneur, éditeur) introduit volontairement une modification nuisible dans le code ou l'artefact. L'attaque vient de l'intérieur de la chaîne de confiance : ni la revue ni la signature ne la détectent, puisque l'auteur est autorisé. Cas typiques : rachat de paquet, compte de mainteneur revendu, contributeur de longue date devenu hostile SLSA (A) CNCF Malicious Maintainer. Un collaborateur autorisé (développeur, ops, admin) abuse de ses accès pour introduire un changement non autorisé dans le code, la configuration ou la chaîne de build. Disposant déjà des droits, il contourne les contrôles d'entrée ; seules la séparation des privilèges, la revue à deux et la traçabilité limitent l'impact SLSA (A) SLSA (B). Du code malveillant est poussé directement sur une branche protégée sans revue obligatoire (push direct, protection absente). Sans contrôle à quatre yeux, une modification hostile entre dans la base de code de référence SLSA (B1). Un attaquant contrôlant plusieurs comptes (ou un compte et un bot) approuve sa propre contribution, contournant l'exigence de revue par un tiers indépendant. La règle de revue existe mais est neutralisée par collusion d'identités SLSA (B1). Un compte de service ou bot autorisé à fusionner sans revue à deux est détourné pour introduire du code, court-circuitant le contrôle humain. Les automatismes sur-privilégiés deviennent un chemin d'injection SLSA (B1). Une exception aux règles de protection (ex. fichiers de documentation exemptés de revue) est exploitée via un fichier déguisé pour faire passer du code non revu. Les angles morts de la politique deviennent une porte d'entrée SLSA (B1). Un administrateur retire temporairement la protection de branche, pousse une modification, puis rétablit la protection, effaçant la trace du contournement. Le pouvoir d'administration sur les contrôles annule les contrôles eux-mêmes SLSA (B1) SLSA (verification). Poisoned Pipeline Execution directe : l'attaquant modifie la définition du pipeline (fichier de CI) pour y injecter des commandes exécutées avec les privilèges du build. Le contrôle du fichier de workflow donne le contrôle de l'exécution CICD-SEC-4.
MFA et moindre privilège sur les accès au SCM.#
Le SCM détient tout le code : un accès volé sans MFA donne les clés du royaume. Imposer la MFA et le moindre privilège sur ses accès bloque l'usage d'identifiants dérobés et limite ce qu'un compte compromis peut atteindre, sur le système le plus convoité de la chaîne.
- Preuve attendue
- Configuration MFA et moindre privilège sur le SCM.
- Outillage
- Gitleaks Legitify
Correspondances & menaces parées 8 standards · 1 menace
Le système de gestion de source lui-même (forge self-hosted, serveur Git) est compromis, donnant à l'attaquant le contrôle du code, des droits et des workflows. La racine de confiance du code tombe : tout en aval devient suspect SLSA (C) CNCF Source Code.
commits et tags signés et vérifiés.#
L'auteur d'un commit Git est une simple chaîne, trivialement usurpable. Signer commits et tags et vérifier ces signatures prouve l'origine réelle des changements et empêche qu'un attaquant se fasse passer pour un mainteneur de confiance, condition d'un historique auquel on peut accorder foi.
- Preuve attendue
- Configuration et vérification de la signature des commits et tags.
- Outillage
- Gitleaks Legitify
Correspondances & menaces parées 8 standards · 1 menace
L'absence de signature vérifiée des commits et tags permet d'usurper l'auteur ou d'introduire des objets non authentifiés dans l'historique. Sans signature imposée, l'identité du contributeur n'est pas prouvable SLSA (B2).
détection de secrets dans le code (pré-commit + CI).#
Un secret poussé sur le dépôt survit dans l'historique même supprimé : il est à considérer comme fuité. Le détecter en pré-commit et en CI l'arrête avant la poussée ou alerte au plus tôt, fenêtre où la rotation reste maîtrisable, sur la fuite la plus exploitée par les scanners d'attaquants.
- Preuve attendue
- Hooks de détection de secrets (pré-commit + CI) ; résultats de scan.
- Outillage
- Gitleaks Legitify
Correspondances & menaces parées 8 standards · 2 menaces
Un secret est stocké ou laissé en clair (fichier, variable d'environnement, historique shell, dépôt) et récupéré par un attaquant. La fuite d'un secret transforme un accès local en compromission étendue (cas Codecov) CICD-SEC-6. Une clé, un jeton ou un mot de passe est commité dans le code et exposé à quiconque accède au dépôt ou à l'artefact. La détection en pré-commit et en CI est la parade OWASP CICD-SEC-6 OWASP ASVS.
politique de revue renforcée des contributions externes / forks non fiables.#
Une PR depuis un fork non fiable peut introduire du code hostile ou tenter d'exfiltrer des secrets via le pipeline. Une politique de revue renforcée des contributions externes traite ces apports avec la méfiance qu'ils méritent, là où une revue ordinaire laisserait passer une attaque déguisée en contribution.
- Preuve attendue
- Politique de revue renforcée des contributions externes / forks non fiables.
- Outillage
- Gitleaks Legitify
Correspondances & menaces parées 7 standards · 3 menaces
Un workflow déclenché sur pull_request_target (ou équivalent) exécute le code d'un fork non fiable avec le contexte et les secrets du dépôt cible. Une simple pull request d'un inconnu obtient l'exécution privilégiée et les jetons du projet CICD-SEC-4. Un pipeline déclenché par une contribution publique exécute du code non fiable dans un contexte privilégié, exposant secrets et droits du projet. La surface vient de l'ouverture du pipeline aux contributions externes CICD-SEC-4. Un écart entre le moment de la vérification et le moment de l'usage (TOCTOU), exploité via un bot, permet de substituer un contenu validé par un contenu malveillant. La fenêtre entre contrôle et action est l'angle d'attaque CICD-SEC-4.
Protéger les branches et la revue
Section intitulée « Protéger les branches et la revue »Le cœur du domaine : personne ne pousse seul sur une branche qui compte. La revue obligatoire bloque l'injection unilatérale, les status checks imposent une CI verte, et CODEOWNERS force la revue des responsables sur les chemins sensibles. Le piège classique : un administrateur qui contourne la protection. La revue à deux personnes (R3) ferme cette porte sur les dépôts sensibles.
checks de statut obligatoires (CI verte) avant fusion ; pas de merge sur échec.#
Fusionner malgré une CI rouge, c'est intégrer sciemment du code cassé ou non vérifié. Des checks de statut obligatoires (CI verte exigée, pas de merge sur échec) garantissent qu'aucun changement n'entre sans avoir passé tests et analyses, rendant la barrière de qualité non contournable sous pression.
- Preuve attendue
- Status checks obligatoires configurés ; merge bloqué si CI en échec.
- Outillage
- Legitify Allstar
Correspondances & menaces parées 2 standards · 1 menace
Du code malveillant est poussé directement sur une branche protégée sans revue obligatoire (push direct, protection absente). Sans contrôle à quatre yeux, une modification hostile entre dans la base de code de référence SLSA (B1).
propriété du code (CODEOWNERS) : revue par les responsables sur les chemins sensibles.#
Sur un chemin sensible (auth, build, secrets), une revue par n'importe qui ne vaut pas une revue par celui qui maîtrise le sujet. CODEOWNERS impose l'approbation des responsables de ces zones : le changement critique est vu par ceux qui peuvent réellement en juger les conséquences.
- Preuve attendue
- Fichier CODEOWNERS ; revue par responsables sur les chemins sensibles.
- Outillage
- Legitify Allstar
Correspondances & menaces parées 2 standards · 6 menaces
Une personne disposant légitimement du droit de publier (mainteneur, éditeur) introduit volontairement une modification nuisible dans le code ou l'artefact. L'attaque vient de l'intérieur de la chaîne de confiance : ni la revue ni la signature ne la détectent, puisque l'auteur est autorisé. Cas typiques : rachat de paquet, compte de mainteneur revendu, contributeur de longue date devenu hostile SLSA (A) CNCF Malicious Maintainer. Du code malveillant est poussé directement sur une branche protégée sans revue obligatoire (push direct, protection absente). Sans contrôle à quatre yeux, une modification hostile entre dans la base de code de référence SLSA (B1). Un compte de service ou bot autorisé à fusionner sans revue à deux est détourné pour introduire du code, court-circuitant le contrôle humain. Les automatismes sur-privilégiés deviennent un chemin d'injection SLSA (B1). Une exception aux règles de protection (ex. fichiers de documentation exemptés de revue) est exploitée via un fichier déguisé pour faire passer du code non revu. Les angles morts de la politique deviennent une porte d'entrée SLSA (B1). Poisoned Pipeline Execution indirecte : l'injection passe par un fichier consommé par le pipeline (Makefile, script, configuration d'outil) plutôt que par le fichier de CI. Le résultat est identique : exécution de code attaquant dans le pipeline CICD-SEC-4 LOTP. Une GitHub App ou un bot disposant de permissions élevées est détourné pour agir sur les dépôts ou les workflows. Les privilèges de l'automate dépassent souvent le besoin, élargissant l'impact d'un abus CICD-SEC-8.
rejet des approbations obsolètes à chaque nouveau push sur la PR.#
Une PR approuvée puis modifiée par un nouveau push peut faire passer du code que personne n'a relu sous une approbation périmée. Rejeter les approbations obsolètes à chaque push force une nouvelle revue du contenu réellement fusionné, fermant la fenêtre du « approuvé puis altéré ».
- Preuve attendue
- Option de rejet des approbations obsolètes activée.
- Outillage
- Legitify Allstar
Correspondances & menaces parées 1 standard · 1 menace
Un écart entre le moment de la vérification et le moment de l'usage (TOCTOU), exploité via un bot, permet de substituer un contenu validé par un contenu malveillant. La fenêtre entre contrôle et action est l'angle d'attaque CICD-SEC-4.
revue à deux personnes (two-person rule) sur les dépôts sensibles.#
Sur un dépôt sensible, une seule approbation peut être contournée par un compte compromis ou un acteur interne isolé. La revue à deux personnes (two-person rule) exige deux validations indépendantes : aucun acteur seul ne peut introduire un changement, contre-pouvoir essentiel là où l'enjeu est maximal.
- Preuve attendue
- Politique de revue à deux personnes sur les dépôts sensibles.
- Outillage
- Legitify Allstar
Correspondances & menaces parées 2 standards · 3 menaces
Une personne disposant légitimement du droit de publier (mainteneur, éditeur) introduit volontairement une modification nuisible dans le code ou l'artefact. L'attaque vient de l'intérieur de la chaîne de confiance : ni la revue ni la signature ne la détectent, puisque l'auteur est autorisé. Cas typiques : rachat de paquet, compte de mainteneur revendu, contributeur de longue date devenu hostile SLSA (A) CNCF Malicious Maintainer. Un collaborateur autorisé (développeur, ops, admin) abuse de ses accès pour introduire un changement non autorisé dans le code, la configuration ou la chaîne de build. Disposant déjà des droits, il contourne les contrôles d'entrée ; seules la séparation des privilèges, la revue à deux et la traçabilité limitent l'impact SLSA (A) SLSA (B). Un attaquant contrôlant plusieurs comptes (ou un compte et un bot) approuve sa propre contribution, contournant l'exigence de revue par un tiers indépendant. La règle de revue existe mais est neutralisée par collusion d'identités SLSA (B1).
Garantir l'intégrité de l'historique
Section intitulée « Garantir l'intégrité de l'historique »Un historique Git est réécrivable : un force-push peut effacer un commit
malveillant et brouiller l'enquête. Cette famille verrouille l'historique des
branches protégées (pas de force-push, pas de suppression) et, sur les dépôts
sensibles, rejette les commits non signés par politique.
historique protégé : force-push et suppression des branches protégées interdits.#
Un force-push ou la suppression d'une branche protégée réécrit l'histoire et peut effacer des traces ou réintroduire du code retiré. Interdire ces opérations préserve l'intégrité de l'historique, socle de l'auditabilité : ce qui a été commis reste vérifiable et ne peut être maquillé.
- Preuve attendue
- Force-push et suppression interdits sur les branches protégées.
- Outillage
- Legitify Allstar
Correspondances & menaces parées 2 standards · 2 menaces
Un administrateur retire temporairement la protection de branche, pousse une modification, puis rétablit la protection, effaçant la trace du contournement. Le pouvoir d'administration sur les contrôles annule les contrôles eux-mêmes SLSA (B1) SLSA (verification). Un force-push réécrit l'historique de la branche pour dissimuler ou injecter des commits (suppression d'un commit malveillant, antidatage). Sans interdiction du force-push ni vérification d'intégrité, l'historique n'est plus une preuve fiable SLSA (B2).
signature imposée par politique sur les dépôts sensibles : rejet des commits non signés.#
Vérifier les signatures ne sert à rien si les commits non signés sont quand même acceptés. Imposer la signature par politique sur les dépôts sensibles, en rejetant le non-signé, ferme la porte : un attaquant ne peut plus injecter de commit anonyme, chaque changement porte une identité prouvée.
- Preuve attendue
- Politique de rejet des commits non signés sur les dépôts sensibles.
- Outillage
- git verify-commit gitsign
Correspondances & menaces parées 2 standards · 1 menace
L'absence de signature vérifiée des commits et tags permet d'usurper l'auteur ou d'introduire des objets non authentifiés dans l'historique. Sans signature imposée, l'identité du contributeur n'est pas prouvable SLSA (B2).
intégrité de l'historique vérifiée : pas de réécriture sur les branches protégées.#
Une réécriture silencieuse d'une branche protégée peut altérer du code déjà revu. Vérifier l'intégrité de l'historique (pas de réécriture) garantit que la base auditée reste celle qui est déployée, et qu'aucune modification ne s'est glissée après la revue sans laisser de trace.
- Preuve attendue
- Protection contre la réécriture d'historique des branches protégées.
- Outillage
- git verify-commit gitsign
Correspondances & menaces parées 1 standard · 1 menace
Un force-push réécrit l'historique de la branche pour dissimuler ou injecter des commits (suppression d'un commit malveillant, antidatage). Sans interdiction du force-push ni vérification d'intégrité, l'historique n'est plus une preuve fiable SLSA (B2).
Maîtriser les accès au SCM
Section intitulée « Maîtriser les accès au SCM »Un compte sur-privilégié ou un jeton qui traîne est une porte d'entrée directe. Cette famille applique le moindre privilège (RBAC revu périodiquement), des jetons scopés et expirants en lecture seule par défaut, un SSO centralisé avec révocation à la sortie, et la journalisation des actions sensibles (changements de protection de branche compris).
RBAC au moindre privilège (dépôt/org/groupe) ; accès revus périodiquement.#
Des droits SCM trop larges ou jamais revus s'accumulent et multiplient les accès exploitables. Un RBAC au moindre privilège (dépôt/org/groupe) avec revue périodique maintient les accès au strict nécessaire et retire les droits dormants, principale cause d'accès oubliés qu'un attaquant exploite.
- Preuve attendue
- Matrice RBAC dépôt/org ; revue périodique des accès.
- Outillage
- Legitify
Correspondances & menaces parées 2 standards · 2 menaces
Un collaborateur autorisé (développeur, ops, admin) abuse de ses accès pour introduire un changement non autorisé dans le code, la configuration ou la chaîne de build. Disposant déjà des droits, il contourne les contrôles d'entrée ; seules la séparation des privilèges, la revue à deux et la traçabilité limitent l'impact SLSA (A) SLSA (B). Le système de gestion de source lui-même (forge self-hosted, serveur Git) est compromis, donnant à l'attaquant le contrôle du code, des droits et des workflows. La racine de confiance du code tombe : tout en aval devient suspect SLSA (C) CNCF Source Code.
clés de déploiement / jetons d'accès scopés, en lecture seule par défaut, expirants.#
Un jeton d'accès large, en écriture et sans expiration, fuité, donne un contrôle durable sur le code. Les rendre scopés, en lecture seule par défaut et expirants réduit l'impact d'une fuite : le jeton volé n'ouvre qu'un périmètre minimal et cesse vite de valoir quoi que ce soit.
- Preuve attendue
- Deploy keys / jetons scopés, lecture seule, expirants.
- Outillage
- Legitify
Correspondances & menaces parées 2 standards · 2 menaces
Le système de gestion de source lui-même (forge self-hosted, serveur Git) est compromis, donnant à l'attaquant le contrôle du code, des droits et des workflows. La racine de confiance du code tombe : tout en aval devient suspect SLSA (C) CNCF Source Code. Un jeton d'accès de longue durée est volé et réutilisé tant qu'il n'est pas révoqué, sans nouvelle authentification. La durée de vie sans rotation maximise la valeur du vol CICD-SEC-6.
SSO / IdP centralisé pour le SCM ; désactivation des accès à la sortie.#
Des accès SCM non centralisés survivent aux départs et échappent au contrôle. Un SSO/IdP centralisé avec désactivation à la sortie garantit qu'un compte révoqué côté entreprise perd immédiatement l'accès au code, fermant la porte du « partant qui garde ses accès », vecteur classique de fuite et de sabotage.
- Preuve attendue
- SSO/IdP pour le SCM ; procédure de désactivation à la sortie.
- Outillage
- Legitify
Correspondances & menaces parées 1 standard · 2 menaces
Un collaborateur autorisé (développeur, ops, admin) abuse de ses accès pour introduire un changement non autorisé dans le code, la configuration ou la chaîne de build. Disposant déjà des droits, il contourne les contrôles d'entrée ; seules la séparation des privilèges, la revue à deux et la traçabilité limitent l'impact SLSA (A) SLSA (B). Le système de gestion de source lui-même (forge self-hosted, serveur Git) est compromis, donnant à l'attaquant le contrôle du code, des droits et des workflows. La racine de confiance du code tombe : tout en aval devient suspect SLSA (C) CNCF Source Code.
journalisation et audit des actions SCM (accès, changements de protection de branche).#
Sans journal des actions SCM, une modification de protection de branche ou un accès anormal passe inaperçu. Journaliser et auditer ces actions (accès, changements de configuration) donne la visibilité pour détecter un abus et la trace pour investiguer, sur la plateforme qui garde l'intégralité du code.
- Preuve attendue
- Journaux d'audit SCM (accès, changements de protection).
- Outillage
- Legitify
Correspondances & menaces parées 2 standards · 1 menace
Un administrateur retire temporairement la protection de branche, pousse une modification, puis rétablit la protection, effaçant la trace du contournement. Le pouvoir d'administration sur les contrôles annule les contrôles eux-mêmes SLSA (B1) SLSA (verification).
Encadrer les contributions externes et les forks
Section intitulée « Encadrer les contributions externes et les forks »Les forks sont le terrain de la pwn request : un workflow déclenché par une PR de fork qui obtiendrait les secrets ou un runner de confiance offre une exécution de code à l'attaquant. Cette famille isole les workflows de fork (ni secrets, ni runners de confiance, en cohérence avec le module runners), impose le secret scanning en pré-réception et la revue de dépendances sur les PR.
détection de secrets sur les poussées et les PR (en pré-réception).#
Un secret poussé est fuité dès qu'il atteint le serveur, même rejeté ensuite. La détection en pré-réception (avant que la poussée ne soit acceptée) bloque le secret au seuil du dépôt, fenêtre la plus précoce possible, plutôt que de le découvrir une fois déjà présent dans l'historique distant.
- Preuve attendue
- Secret scanning en pré-réception sur poussées et PR.
Correspondances & menaces parées 2 standards · 2 menaces
Un workflow déclenché sur pull_request_target (ou équivalent) exécute le code d'un fork non fiable avec le contexte et les secrets du dépôt cible. Une simple pull request d'un inconnu obtient l'exécution privilégiée et les jetons du projet CICD-SEC-4. Un secret est stocké ou laissé en clair (fichier, variable d'environnement, historique shell, dépôt) et récupéré par un attaquant. La fuite d'un secret transforme un accès local en compromission étendue (cas Codecov) CICD-SEC-6.
les workflows déclenchés par des forks n'accèdent ni aux secrets ni aux runners de confiance.#
Un workflow déclenché par un fork hostile qui accéderait aux secrets ou aux runners de confiance permettrait l'exfiltration ou l'exécution malveillante. Lui couper l'accès à ces ressources neutralise cette attaque classique, où une PR externe sert de cheval de Troie vers le pipeline.
- Preuve attendue
- Configuration : workflows de fork sans accès aux secrets ni aux runners de confiance.
- Outillage
- zizmor poutine
Correspondances & menaces parées 2 standards · 2 menaces
Un workflow déclenché sur pull_request_target (ou équivalent) exécute le code d'un fork non fiable avec le contexte et les secrets du dépôt cible. Une simple pull request d'un inconnu obtient l'exécution privilégiée et les jetons du projet CICD-SEC-4. Un pipeline déclenché par une contribution publique exécute du code non fiable dans un contexte privilégié, exposant secrets et droits du projet. La surface vient de l'ouverture du pipeline aux contributions externes CICD-SEC-4.
revue de dépendances sur les PR (dependency review) ; blocage des ajouts vulnérables ou malveillants.#
Une PR peut ajouter une dépendance vulnérable ou malveillante sans que le relecteur le remarque. La revue de dépendances automatisée sur les PR signale et bloque ces ajouts à risque avant la fusion, attrapant à l'entrée ce qu'un humain ne peut pas vérifier manuellement dans un arbre de dépendances.
- Preuve attendue
- Dependency review sur les PR ; blocage des dépendances vulnérables.
- Outillage
- zizmor poutine
Correspondances & menaces parées 3 standards · 2 menaces
Un workflow déclenché sur pull_request_target (ou équivalent) exécute le code d'un fork non fiable avec le contexte et les secrets du dépôt cible. Une simple pull request d'un inconnu obtient l'exécution privilégiée et les jetons du projet CICD-SEC-4. La charge malveillante n'est pas dans la dépendance directe mais dans une dépendance de dépendance, invisible sans analyse du graphe complet. La profondeur de l'arbre de dépendances masque l'origine du risque SLSA (dépendances).
Pièges courants
Section intitulée « Pièges courants »- Protéger
mainmais pas les branches de release : l'attaquant cible la branche oubliée. - Signer sans vérifier : sans politique de vérification, une signature ne bloque rien (SRC-0-3, SRC-SR2-3).
- Admin au-dessus des règles : si les administrateurs contournent la protection de branche, la revue ne garantit plus rien (SRC-SR1-5).
- Workflows de fork avec secrets : la pwn request la plus courante (SRC-SR4-3).
- Jetons PAT permanents : un jeton non expirant volé reste exploitable indéfiniment (SRC-SR3-3).
À retenir
Section intitulée « À retenir »- La source est la première ligne de défense : tout compromis ici contamine l'aval.
- Les essentielles : branches protégées, MFA, signature vérifiée, secret scanning, revue des forks.
- L'historique doit être verrouillé (pas de force-push) pour préserver la traçabilité.
- Les forks ne doivent jamais toucher aux secrets ni aux runners de confiance.
- Le niveau R3 ajoute la revue à deux et la signature imposée sur le sensible.