Sans gouvernance, la sécurité de la chaîne logicielle reste une collection d'outils sans cap : personne ne sait ce qu'on protège, qui en répond, ni où on en est. Le domaine Gouvernance & conformité (GOV) donne ce cap : il transforme des contrôles épars en programme piloté, sponsorisé par la direction.
On ne sécurise bien que ce qu'on connaît et ce dont quelqu'un répond. La gouvernance pose pour cela cinq leviers complémentaires. L'inventaire des produits et chaînes de build, trié par criticité, dit quoi protéger en priorité. La politique formalisée et le RACI disent qui décide, qui applique et qui répond, plutôt que de laisser chacun improviser. Le suivi de conformité (CRA, NIS2/ReCyF) date et pilote les écarts avant que l'échéance n'arrive sans préparation. Le threat modeling de la chaîne oriente l'effort là où un attaquant entrerait réellement, au lieu de saupoudrer des mesures. Enfin la mesure de maturité (SAMM/DSOMM) fixe une trajectoire vérifiable. Le tout n'est pas un document figé mais un cycle continu : cartographier, définir, suivre, mesurer, puis recommencer.
Concrètement, ces exigences parent : la chaîne de build oubliée qui échappe à tous les contrôles, le point de défaillance unique chez un fournisseur critique, la non-conformité CRA/NIS2 découverte trop tard, et l'effort de sécurité dispersé faute de modèle de menace et de maturité mesurée. Cette page couvre les 19 exigences SOCLE du domaine, des fondamentales (R1) aux souveraines (R3).
Sans gouvernance, les contrôles techniques restent partiels et non opposables (CRA/NIS2).
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 »Six exigences forment la base : inventaire avec tiering, politique et rôles, conformité réglementaire, threat modeling, maturité mesurée et, au souverain, préparation à l'audit ANSSI.
inventaire des produits et chaînes de build, avec tiering par criticité, tenu à jour.#
On ne protège pas ce qu'on n'a pas recensé : une chaîne de build oubliée échappe à tous les contrôles. Un inventaire des produits et chaînes, trié par criticité, dit quoi protéger en priorité ; tenu à jour, il évite l'angle mort où le maillon le plus exposé est aussi le moins surveillé.
- Preuve attendue
- Inventaire des produits et chaînes de build avec tiering par criticité ; horodatage de dernière mise à jour.
Correspondances & menaces parées 6 standards · 1 menace
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.
politique de sécurité de la chaîne logicielle formalisée ; rôles et responsabilités définis.#
Sans politique écrite ni rôles définis, la sécurité de la chaîne dépend de la bonne volonté de chacun et s'effondre au premier départ. La formaliser et désigner les responsables rend les attentes explicites et opposables : on sait qui décide, qui applique et qui répond, au lieu de présumer.
- Preuve attendue
- Politique de sécurité de la chaîne logicielle documentée ; matrice des rôles et responsabilités.
Correspondances & menaces parées 7 standards · 3 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). 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 artefact légitime est utilisé de façon non prévue ou dans un contexte non sécurisé, créant un risque que la chaîne technique ne couvre pas. La sécurité dépend aussi de l'usage, pas seulement de la fabrication SLSA (I).
conformité réglementaire suivie (CRA, NIS2/ReCyF) : écarts identifiés et pilotés.#
Le CRA et NIS2 imposent des obligations dont le non-respect coûte cher (sanctions, marché perdu). Suivre la conformité, identifier les écarts et les piloter transforme une contrainte subie en plan maîtrisé, plutôt que de découvrir l'écart lors d'un contrôle ou d'un incident.
- Preuve attendue
- Registre de conformité (CRA, NIS2/ReCyF) : écarts identifiés et plan de mise en conformité suivi.
Correspondances & menaces parées 7 standards · 1 menace
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.
threat modeling de la chaîne réalisé et tenu à jour.#
Défendre sans modèle de menace, c'est répartir l'effort au hasard. Modéliser les menaces de la chaîne (et le tenir à jour) révèle par où un attaquant entrerait réellement (dépendances, runners, registres) et oriente les contrôles là où ils comptent, au lieu de saupoudrer des mesures génériques.
- Preuve attendue
- Modèle de menace de la chaîne documenté, daté et revu.
Correspondances & menaces parées 7 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. Le mainteneur saborde délibérément son propre composant pour des raisons idéologiques ou politiques (protestware) : code destructeur, messages, ou comportements ciblant certains utilisateurs. La confiance accordée au paquet se retourne contre ses consommateurs lors d'une simple mise à jour (cas node-ipc) CNCF Malicious Maintainer SoK. 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).
maturité mesurée via un modèle reconnu (SAMM/DSOMM) ; trajectoire définie.#
Sans modèle de maturité, « on s'améliore » reste une impression invérifiable. Mesurer via SAMM/DSOMM et définir une trajectoire situe où l'on est, où l'on va et à quel rythme : la progression devient pilotable et défendable en gouvernance, pas une suite d'efforts dispersés sans cap.
- Preuve attendue
- Évaluation de maturité (SAMM/DSOMM) et trajectoire cible documentées.
Correspondances & menaces parées 6 standards · 1 menace
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.
préparation à l'audit ex ante (ANSSI) : posture documentée et chiffrée.#
Un dossier d'audit improvisé sous pression est lacunaire et arrive trop tard. Préparer la posture, documentée et chiffrée, en vue d'un audit ex ante (ANSSI) garantit qu'on peut démontrer sa conformité à la demande, condition d'accès à certains marchés et preuve d'une maîtrise réelle.
- Preuve attendue
- Dossier de préparation à l'audit ex ante : posture documentée et chiffrée.
Correspondances & menaces parées 6 standards · 1 menace
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.
Inventorier et cartographier
Section intitulée « Inventorier et cartographier »On ne protège que ce qu'on cartographie : flux, dépôts, runners, registres, fournisseurs. On identifie les dépendances et fournisseurs critiques (points uniques de défaillance, concentration), et on tient cet inventaire à jour par revue périodique.
cartographie des chaînes de build/déploiement (flux, dépôts, runners, registres, fournisseurs).#
On ne sécurise pas des flux qu'on ne visualise pas : dépôts, runners, registres et fournisseurs forment un réseau dont les maillons faibles sont invisibles sans carte. Cartographier la chaîne de build/déploiement rend ces interconnexions explicites, préalable pour repérer les points d'entrée et placer le bon contrôle au bon endroit.
- Preuve attendue
- Cartographie des chaînes de build/déploiement (flux, dépôts, runners, registres, fournisseurs).
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). Une dépendance est retirée ou dépubliée (unpublish, yank), cassant les builds et poussant à des substitutions hâtives, parfois vers un remplacement malveillant. La disponibilité de la chaîne est attaquée (cas left-pad) SLSA (disponibilité).
identification des dépendances et fournisseurs critiques (concentration, points uniques de défaillance).#
Une dépendance ou un fournisseur unique est un point de défaillance : sa compromission ou sa panne fait tomber toute la chaîne. Identifier ces concentrations (SPOF) permet d'anticiper, de diversifier ou de surveiller davantage là où le risque est concentré, plutôt que de le découvrir le jour de l'incident.
- Preuve attendue
- Identification des dépendances et fournisseurs critiques.
Correspondances & menaces parées 2 standards · 2 menaces
Le mainteneur saborde délibérément son propre composant pour des raisons idéologiques ou politiques (protestware) : code destructeur, messages, ou comportements ciblant certains utilisateurs. La confiance accordée au paquet se retourne contre ses consommateurs lors d'une simple mise à jour (cas node-ipc) CNCF Malicious Maintainer SoK. Une dépendance est retirée ou dépubliée (unpublish, yank), cassant les builds et poussant à des substitutions hâtives, parfois vers un remplacement malveillant. La disponibilité de la chaîne est attaquée (cas left-pad) SLSA (disponibilité).
inventaire tenu à jour (revue périodique, déclencheurs de mise à jour).#
Un inventaire figé devient faux en quelques semaines : nouvelles chaînes, fournisseurs changés, dépôts archivés. Le tenir à jour (revue périodique, déclencheurs de mise à jour) garantit que les décisions de sécurité s'appuient sur la réalité actuelle, pas sur une photo périmée qui laisse des actifs hors radar.
- Preuve attendue
- Inventaire tenu à jour (revue périodique).
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). Une dépendance est retirée ou dépubliée (unpublish, yank), cassant les builds et poussant à des substitutions hâtives, parfois vers un remplacement malveillant. La disponibilité de la chaîne est attaquée (cas left-pad) SLSA (disponibilité).
Définir la politique et les responsabilités
Section intitulée « Définir la politique et les responsabilités »Une politique approuvée par la direction, diffusée et revue, fixe le cadre. Les rôles sont définis (RACI) avec un sponsor au niveau direction. Les équipes (dev, ops, achats) sont formées, et les exigences de sécurité sont intégrées aux marchés et contrats.
politique de la chaîne logicielle approuvée par la direction, diffusée et revue périodiquement.#
Une politique non portée par la direction n'a aucun poids face aux arbitrages de livraison. Approuvée au plus haut niveau, diffusée et revue, elle devient une référence opposable que les équipes ne peuvent écarter, et son sponsor lui donne les moyens d'être réellement appliquée.
- Preuve attendue
- Politique approuvée par la direction, diffusée et revue.
Correspondances & menaces parées 3 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). Un artefact légitime est utilisé de façon non prévue ou dans un contexte non sécurisé, créant un risque que la chaîne technique ne couvre pas. La sécurité dépend aussi de l'usage, pas seulement de la fabrication SLSA (I).
rôles et responsabilités définis (RACI), avec un sponsor au niveau direction.#
Sans RACI clair, chacun pense qu'un autre s'en occupe, et personne ne répond le jour J. Définir les rôles et responsabilités avec un sponsor en direction lève cette ambiguïté : chaque maillon de la chaîne a un responsable nommé, et l'autorité existe pour trancher et financer.
- Preuve attendue
- RACI documenté ; sponsor direction.
Correspondances & menaces parées 2 standards · 1 menace
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).
sensibilisation et formation des équipes (dev, ops, achats) à la sécurité de la chaîne.#
Une politique que les équipes ignorent ne change rien sur le terrain. Sensibiliser et former dev, ops et achats ancre les exigences là où les décisions se prennent, y compris au moment de contractualiser avec un fournisseur, point souvent oublié où entre une grande partie du risque de la chaîne.
- Preuve attendue
- Plan de formation/sensibilisation à la sécurité de la chaîne.
Correspondances & menaces parées 2 standards · 1 menace
Un artefact légitime est utilisé de façon non prévue ou dans un contexte non sécurisé, créant un risque que la chaîne technique ne couvre pas. La sécurité dépend aussi de l'usage, pas seulement de la fabrication SLSA (I).
exigences de sécurité de la chaîne intégrées aux marchés et contrats.#
Si la sécurité n'est pas dans le contrat, le fournisseur n'a aucune obligation et le risque entre par les achats. Intégrer les exigences de la chaîne aux marchés et contrats rend ces attentes opposables dès la sélection, quand on peut encore choisir, plutôt qu'après la signature où l'on est captif.
- Preuve attendue
- Clauses de sécurité de la chaîne dans les marchés/contrats.
Correspondances & menaces parées 2 standards · 2 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 artefact légitime est utilisé de façon non prévue ou dans un contexte non sécurisé, créant un risque que la chaîne technique ne couvre pas. La sécurité dépend aussi de l'usage, pas seulement de la fabrication SLSA (I).
Suivre la conformité réglementaire
Section intitulée « Suivre la conformité réglementaire »Le CRA et NIS2/ReCyF imposent des obligations datées. On tient un registre de conformité (écarts, plan, échéances), des preuves produisibles par domaine, et au souverain, la capacité de produire le dossier d'audit ex ante en temps limité, testée par un exercice à blanc.
suivi de conformité CRA et NIS2/ReCyF : écarts identifiés, plan piloté, échéances datées.#
Une conformité non suivie se découvre en retard, à l'échéance ou au contrôle. Suivre les écarts CRA/NIS2 avec un plan piloté et des échéances datées transforme l'obligation en feuille de route maîtrisée : on sait ce qui reste à faire et pour quand, au lieu de subir la pression réglementaire en bloc.
- Preuve attendue
- Registre de conformité CRA/NIS2/ReCyF : écarts, plan, échéances.
Correspondances & menaces parées 3 standards · 1 menace
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.
preuves de conformité maintenues et produisibles (posture par domaine, niveau atteint).#
Être conforme sans pouvoir le prouver ne sert à rien lors d'un audit ou d'un appel d'offres. Maintenir des preuves produisibles (posture par domaine, niveau atteint) permet de démontrer la conformité à la demande, en heures plutôt qu'en semaines de reconstitution sous stress.
- Preuve attendue
- Preuves de conformité maintenues et produisibles.
Correspondances & menaces parées 2 standards · 1 menace
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.
capacité de produire le dossier d'audit ex ante (ANSSI/ReCyF) en temps limité ; exercice à blanc réalisé.#
Produire un dossier d'audit complet en temps limité ne s'improvise pas le jour de la demande. S'entraîner à blanc vérifie qu'on en est réellement capable et révèle les manques pendant qu'on peut encore les combler, avant que l'enjeu soit un marché ou une qualification.
- Preuve attendue
- Exercice d'audit ex ante à blanc réalisé ; dossier produisible en temps limité.
Correspondances & menaces parées 2 standards · 1 menace
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.
Mesurer maturité et risque
Section intitulée « Mesurer maturité et risque »On pilote par la mesure : un threat modeling de la chaîne, à jour et relié au corpus de menaces ; une maturité évaluée (SAMM/DSOMM) avec trajectoire ; et des indicateurs de risque (KRI) reportés à la direction.
threat modeling de la chaîne logicielle réalisé, tenu à jour et relié au corpus de menaces.#
Un threat model déconnecté des attaques réelles rate les menaces du moment. Le relier au corpus de menaces (incidents observés) ancre l'analyse dans ce qui se produit vraiment dans l'écosystème, et le tenir à jour évite qu'il décrive une chaîne et des risques qui n'existent plus.
- Preuve attendue
- Threat model de la chaîne, à jour, relié au corpus de menaces.
Correspondances & menaces parées 3 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. Le mainteneur saborde délibérément son propre composant pour des raisons idéologiques ou politiques (protestware) : code destructeur, messages, ou comportements ciblant certains utilisateurs. La confiance accordée au paquet se retourne contre ses consommateurs lors d'une simple mise à jour (cas node-ipc) CNCF Malicious Maintainer SoK. 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).
maturité mesurée (SAMM/DSOMM) avec trajectoire et métriques suivies.#
Mesurer la maturité une fois ne pilote rien. La mesurer avec une trajectoire et des métriques suivies (SAMM/DSOMM) rend la progression visible dans le temps et permet d'arbitrer les investissements sur des faits, transformant l'amélioration de la chaîne en démarche pilotée plutôt qu'en intentions.
- Preuve attendue
- Évaluation de maturité (SAMM/DSOMM) et trajectoire.
Correspondances & menaces parées 2 standards · 1 menace
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.
indicateurs de risque de la chaîne (KRI) suivis et reportés à la direction.#
Des risques qui ne remontent pas à la direction ne sont jamais arbitrés ni financés. Suivre des indicateurs de risque (KRI) et les reporter au plus haut niveau ferme la boucle entre le terrain et la décision : la direction voit où la chaîne est exposée et peut allouer les moyens en conséquence.
- Preuve attendue
- Tableau de bord des indicateurs de risque (KRI) reportés à la direction.
Correspondances & menaces parées 2 standards · 1 menace
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.
Pièges courants
Section intitulée « Pièges courants »- Outils sans cap : empiler des scanners sans inventaire ni politique ne protège rien (GOV-0-1, GOV-0-2).
- Politique sans sponsor : sans portage direction, elle reste lettre morte (GOV-G2-2).
- Conformité en panique : découvrir l'échéance CRA sans registre ni preuves (GOV-0-3, GOV-G3-1).
- Maturité non mesurée : impossible de prioriser sans savoir où l'on est (GOV-0-5).
- Threat model figé : un modèle écrit une fois et jamais revu décroche du réel (GOV-G4-1).
À retenir
Section intitulée « À retenir »- GOV est le domaine chapeau : il donne le cap aux 15 autres.
- Les essentielles : inventaire, politique et rôles, conformité, threat modeling, maturité.
- La gouvernance est un cycle continu, pas un document figé.
- La conformité (CRA, NIS2) se prépare avec un registre et des preuves produisibles.
- On pilote par la mesure : maturité (SAMM) et indicateurs de risque reportés à la direction.