L'intégration assemble votre code avec des centaines de dépendances tierces et les construit en artefact : c'est là qu'entre la majorité des compromissions. Le domaine Intégration : dépendances & build (INT) maîtrise ce qu'on consomme (dépendances open source) et sécurise le build qui les assemble.
Un projet moderne tire des centaines de dépendances transitives, exécute des scripts d'installation, et construit sur une plateforme CI avec des actions tierces. Chaque maillon est un point d'entrée : une dépendance malveillante ou vulnérable (Log4Shell), une action réécrite par tag (cas tj-actions), une image de base substituée. La parade tient en quatre réflexes : savoir ce qu'on intègre (SBOM, lockfiles, inventaire des transitifs), filtrer l'ingestion OSS (miroir/proxy interne, cooldown, allowlist de registres), tracer le build (plateforme isolée, provenance attachée et vérifiable) et figer les outils de la chaîne (images par digest, actions par commit SHA).
Concrètement, ces exigences parent : la dépendance vulnérable ou piégée tirée sans contrôle, l'action tierce réécrite, la faille de code non détectée par le SAST, l'image substituée par un tag mutable, et le build opaque sans provenance. Cette page couvre les 27 exigences SOCLE du domaine en cinq familles, des fondamentales (R1) aux souveraines (R3).
Les quatre réflexes : savoir, filtrer, tracer, figer
Section intitulée « Les quatre réflexes : savoir, filtrer, tracer, figer »Derrière les 27 exigences, le domaine tient en quatre réflexes simples à retenir, qui structurent toutes les familles.
Savoir ce qu'on intègre. Une application moderne agrège des centaines de dépendances transitives ; sans analyse de composition (SCA) et sans SBOM (Software Bill of Materials, l'inventaire des composants), on ignore tout simplement ce qui tourne. On ne protège pas ce qu'on ne connaît pas : la première compromission joue toujours sur cet angle mort. Les lockfiles figent en prime les versions exactes, pour qu'un même commit produise toujours le même arbre de dépendances.
Filtrer l'open source à l'entrée. Plutôt que tirer directement depuis l'internet public, on passe par un miroir ou proxy interne qui contrôle les sources, et on impose un délai de quarantaine (cooldown) avant d'adopter une nouvelle version. Ce délai désamorce à lui seul une grande part des attaques par publication malveillante : les paquets piégés sont souvent détectés et retirés dans les heures qui suivent leur sortie.
Tracer le build. Le passage du code à l'artefact doit produire une provenance vérifiable : qui a construit, à partir de quelle source, avec quels paramètres. C'est le standard SLSA qui formalise cette attestation. Sans elle, un build piégé ne laisse aucune preuve et reste indétectable a posteriori.
Figer les briques tierces. Les actions CI sont épinglées par commit SHA,
les images par digest, jamais par un tag mutable comme latest. Un tag peut
être réécrit en silence pour pointer vers du code malveillant ; un digest, non.
L'incident tj-actions de 2025 a montré qu'une seule action non épinglée suffit à
compromettre des milliers de pipelines.
Les cinq familles de l'intégration
Section intitulée « Les cinq familles de l'intégration »L'intégration se décline en cinq familles : l'inventaire des dépendances, l'ingestion maîtrisée de l'OSS, le build sécurisé, la chaîne d'outils CI et la vérification du code.
Le build consomme des dépendances tierces : maillon le plus exploité (typosquat, confusion, build piégé).
Où l'intégration s'articule avec les autres domaines
Section intitulée « Où l'intégration s'articule avec les autres domaines »L'intégration ne se suffit pas à elle-même : elle reçoit et transmet. En amont, elle dépend de la source (le code et son historique) et de l'orchestration qui fournit des runners isolés et dignes de confiance. En aval, elle alimente le packaging et la release, qui signeront et publieront l'artefact dont l'intégration a établi la provenance.
Cette position centrale explique pourquoi le domaine porte autant d'exigences essentielles : neuf sur vingt-sept. Une faille à l'intégration contamine tout ce qui suit, parce que l'artefact compromis hérite d'une provenance valide et traverse ensuite les contrôles aval sans éveiller de soupçon. Inversement, un build bien maîtrisé donne aux étapes suivantes une base de confiance solide : elles n'ont plus à se demander si l'artefact a été produit proprement, c'est déjà prouvé. C'est la logique de défense en profondeur appliquée à la chaîne logicielle : chaque domaine ferme une classe de risques, et l'intégration ferme la plus exploitée. C'est pourquoi une organisation qui débute son chantier supply chain a tout intérêt à commencer par l'intégration : c'est là que le rapport entre l'effort fourni et le risque réellement réduit est le plus élevé.
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 »Neuf exigences forment la base : SCA à chaque build, lockfiles, miroir OSS, SAST bloquant, détection des dépendances malveillantes, build tracé, images CI épinglées, actions épinglées par SHA, et outils détournables durcis.
analyse de composition (SCA) des dépendances à chaque build.#
Une dépendance saine à l'ajout devient vulnérable dès qu'un CVE paraît (cas Log4Shell). L'analyse de composition (SCA) rejouée à chaque build rattrape ces vulnérabilités au plus tôt, au lieu de les découvrir en production. C'est le contrôle minimal sur des dépendances qui représentent l'essentiel du code livré.
- Preuve attendue
- Rapport d'analyse de composition (SCA) produit à chaque build.
- Outillage
- OSV-Scanner Trivy
Correspondances & menaces parées 10 standards · 2 menaces
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). Une bibliothèque de l'écosystème IA (serving, orchestration, agents) est compromise comme n'importe quelle dépendance, mais avec un accès privilégié aux données et aux modèles. La surface supply chain classique appliquée à la pile IA OWASP A03.
provenance et builder des images de base vérifiés avant usage.#
Une image de base est un artefact comme un autre : compromise, elle contamine tout ce qui en dérive. Vérifier sa provenance et son builder avant usage garantit qu'elle vient bien de la source attendue et n'a pas été substituée, fermant un vecteur d'empoisonnement en amont de toute la production.
- Preuve attendue
- Vérification de provenance/builder tracée pour les images de base.
- Outillage
- OSV-Scanner Trivy
Correspondances & menaces parées 7 standards · 2 menaces
L'image de base utilisée pour construire les conteneurs contient une charge malveillante ou une vulnérabilité, héritée par tous les artefacts qui en dérivent. Le socle d'exécution contamine toute la production CNCF SLSA. Une version malveillante persiste dans des miroirs ou caches même après retrait à la source, continuant d'être servie aux clients qui s'y approvisionnent. Le retrait à la source ne suffit pas à éradiquer la menace CNCF SLSA.
images analysées (malware et secrets, pas seulement CVE) avant usage.#
Un scan CVE d'image ne détecte ni une charge malveillante ajoutée ni un secret oublié en couche. Analyser les images pour le malware et les secrets, pas seulement les vulnérabilités connues, attrape ce qu'un attaquant glisse délibérément et ce qu'un développeur a laissé fuiter par accident.
- Preuve attendue
- Rapport de scan image (malware + secrets) avant promotion.
- Outillage
- OSV-Scanner Trivy
Correspondances & menaces parées 7 standards · 1 menace
L'image de base utilisée pour construire les conteneurs contient une charge malveillante ou une vulnérabilité, héritée par tous les artefacts qui en dérivent. Le socle d'exécution contamine toute la production CNCF SLSA.
versions verrouillées (lockfiles) ; provenance des dépendances maîtrisée.#
Sans lockfile, deux builds tirent des versions différentes : une dépendance peut être substituée entre-temps. Verrouiller les versions et maîtriser leur provenance garantit que ce qui est audité est exactement ce qui est construit, et coupe l'injection silencieuse de versions piégées entre deux exécutions.
- Preuve attendue
- Lockfiles versionnés ; configuration de provenance des dépendances.
- Outillage
- OSV-Scanner Trivy
Correspondances & menaces parées 10 standards · 2 menaces
Un paquet public est publié sous le nom d'un paquet interne ; le gestionnaire, mal configuré, préfère la version publique de plus haut numéro et tire le code de l'attaquant. La confusion entre registre interne et public livre l'exécution au build SoK CICD-SEC-3. Une bibliothèque applicative porteuse d'une vulnérabilité connue est exploitée faute de détection (SCA) et de mise à jour. L'absence d'inventaire et de correctif transforme une CVE publique en brèche (cas Log4Shell, Equifax) OWASP Top 10 2025 OWASP CICD-SEC-3 OWASP ASVS.
consommation OSS via miroir/proxy interne contrôlé (pas de tirage direct non filtré).#
Tirer un paquet directement du registre public expose au typosquatting, aux paquets retirés et à la panne d'un service externe. Un miroir/proxy interne contrôlé filtre, met en cache et trace ce qui entre : on ne consomme plus n'importe quoi depuis n'importe où, et un retrait amont ne casse plus le build.
- Preuve attendue
- Configuration du miroir/proxy interne ; preuve d'absence de tirage direct non filtré.
- Outillage
- OSV-Scanner Trivy
Correspondances & menaces parées 9 standards · 4 menaces
Un paquet public est publié sous le nom d'un paquet interne ; le gestionnaire, mal configuré, préfère la version publique de plus haut numéro et tire le code de l'attaquant. La confusion entre registre interne et public livre l'exécution au build SoK CICD-SEC-3. 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é). Le registre de paquets ou un miroir est compromis, permettant d'altérer ou de substituer des artefacts pour tous ses utilisateurs. L'infrastructure de distribution devient le point de défaillance unique CNCF Publishing. Une version malveillante persiste dans des miroirs ou caches même après retrait à la source, continuant d'être servie aux clients qui s'y approvisionnent. Le retrait à la source ne suffit pas à éradiquer la menace CNCF SLSA.
SAST intégré au pipeline, seuils bloquants sur criticités hautes.#
Détecter une faille de code après la mise en production coûte cher et expose les utilisateurs. Le SAST intégré au pipeline, avec des seuils bloquants sur les criticités hautes, arrête la livraison d'une vulnérabilité grave dès le build, là où la corriger ne coûte qu'une revue.
- Preuve attendue
- Intégration SAST au pipeline ; seuils bloquants configurés sur criticités hautes.
- Outillage
- OSV-Scanner Trivy
Correspondances & menaces parées 11 standards · 2 menaces
Une donnée contrôlée par l'attaquant (titre de PR, nom de branche, message de commit) est interpolée sans échappement dans un script de workflow, provoquant une exécution de commande dans le pipeline. C'est l'injection classique portée au CI CICD-SEC-4. Un plugin ou une extension de l'outil de build (Gradle, Maven, bundler) exécute du code au moment de la construction, hors de toute revue du code applicatif. Le build devient un vecteur d'exécution tierce SoK LOTP.
détection des dépendances malveillantes / typosquatting (analyse comportementale, pas seulement CVE) ; délai de quarantaine (cooldown) avant adoption d'une nouvelle version.#
Un scanner de CVE ne voit pas un paquet délibérément malveillant récemment publié : il n'a pas encore de CVE. L'analyse comportementale détecte le typosquatting et les charges cachées, et un délai de quarantaine avant adoption laisse le temps à la communauté de retirer un paquet piégé.
- Preuve attendue
- Outil de détection de dépendances malveillantes/typosquatting ; politique de cooldown configurée.
- Outillage
- OSV-Scanner Trivy
Correspondances & menaces parées 10 standards · 5 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. Un paquet malveillant porte un nom très proche d'un paquet légitime (faute de frappe, tiret, ordre des mots) pour être installé par erreur. L'attaque mise sur l'inattention au moment d'ajouter une dépendance SLSA (H) CNCF Negligence SoK. L'attaquant usurpe la réputation d'un projet légitime (nom de marque, étoiles, métadonnées pointant vers un dépôt populaire) pour faire passer un paquet malveillant pour de confiance. La crédibilité empruntée trompe l'évaluation SoK. Le consommateur choisit, par erreur ou tromperie, un paquet ou une version différente de celle voulue (homonyme, mauvais canal, mauvaise version). L'erreur de sélection court-circuite toutes les protections en amont SLSA (H). Une bibliothèque de l'écosystème IA (serving, orchestration, agents) est compromise comme n'importe quelle dépendance, mais avec un accès privilégié aux données et aux modèles. La surface supply chain classique appliquée à la pile IA OWASP A03.
build sur plateforme hébergée et tracée, générant une provenance.#
Un artefact construit sur un poste ou une plateforme opaque est invérifiable : on ignore où et comment il a été produit. Builder sur une plateforme hébergée et tracée qui génère une provenance rend l'origine de chaque artefact reconstituable, base de toute confiance en aval (SLSA).
- Preuve attendue
- Plateforme de build hébergée et tracée ; provenance générée.
- Outillage
- OSV-Scanner Trivy
Correspondances & menaces parées 9 standards · 2 menaces
Le build est lancé depuis une source ou un fork non officiel, produisant un artefact d'apparence légitime à partir de code non vérifié. L'origine du build n'est pas garantie sans provenance liant artefact et source SLSA (D) SLSA (E). Le build est compromis en amont, si bien que la provenance est techniquement valide mais atteste d'un artefact malveillant. La provenance prouve l'origine, pas l'innocuité : un build corrompu produit une attestation correcte d'un mauvais résultat SLSA (D) SLSA (E).
images de base et d'outils CI épinglées par digest (jamais de tag mutable).#
Un tag mutable (:latest) peut pointer demain vers une image différente, piégée, sans changer une ligne de votre code. Épingler par digest (@sha256:) fige exactement l'image utilisée : la reproductibilité est garantie et personne ne substitue le socle d'exécution de vos builds à votre insu.
- Preuve attendue
- Images CI épinglées par digest ; vérification de provenance/builder ; scan malware.
- Outillage
- OSV-Scanner Trivy
Correspondances & menaces parées 11 standards · 6 menaces
Un attaquant écrit dans un cache partagé du CI (dépendances, couches d'image, artefacts intermédiaires) une charge réutilisée par d'autres builds. Le cache, supposé sûr, propage la compromission entre exécutions ou projets CICD-SEC-4. L'image de base utilisée pour construire les conteneurs contient une charge malveillante ou une vulnérabilité, héritée par tous les artefacts qui en dérivent. Le socle d'exécution contamine toute la production CNCF SLSA. Un tag mutable (latest, une version) est réécrit pour pointer vers un artefact malveillant, livré aux consommateurs qui font confiance au tag plutôt qu'au digest. La mutabilité brise l'immuabilité attendue d'une version publiée CNCF Publishing. L'attaquant publie avec des identifiants d'éditeur valides (volés ou détournés), rendant la publication indistinguable d'une légitime côté registre. La détection repose alors sur le comportement, pas sur l'authentification CNCF Publishing. Le canal par lequel le logiciel est distribué (site de téléchargement, CDN, miroir, mise à jour) est compromis pour livrer une version trojanisée aux utilisateurs finaux. La compromission frappe en aval de la production, au plus près des victimes SLSA (G). Une version malveillante persiste dans des miroirs ou caches même après retrait à la source, continuant d'être servie aux clients qui s'y approvisionnent. Le retrait à la source ne suffit pas à éradiquer la menace CNCF SLSA.
actions/steps CI tiers épinglés par commit SHA, depuis une liste autorisée.#
Une action CI référencée par tag peut être réécrite par son mainteneur ou un attaquant (cas tj-actions, mars 2025). Épingler par commit SHA et n'autoriser qu'une liste validée garantit que le code tiers exécuté dans votre pipeline est exactement celui que vous avez revu, pas une version repoussée après coup.
- Preuve attendue
- Actions/steps tiers épinglés par commit SHA ; liste autorisée.
- Outillage
- OSV-Scanner Trivy
Correspondances & menaces parées 10 standards · 1 menace
Une action ou un step tiers référencé par tag mutable (non épinglé par digest) est remplacé par une version malveillante, exécutée dans tous les pipelines qui l'utilisent. Le défaut d'épinglage transforme une dépendance CI en porte dérobée (cas tj-actions) CICD-SEC-3.
outils détournables de la chaîne (CLI, linters, formateurs, runners de test ; réf. LOTP) inventoriés et durcis : fonctionnalités d'exécution de code arbitraire désactivées ou confinées.#
Les outils légitimes de la chaîne (linters, runners de test) peuvent exécuter du code arbitraire : un attaquant les retourne sans déposer de malware (« living off the pipeline »). Les inventorier et désactiver leurs fonctions d'exécution non nécessaires retire à l'attaquant des binaires de confiance déjà présents.
- Preuve attendue
- Inventaire des outils détournables (LOTP) ; preuve de désactivation/confinement de l'exécution arbitraire.
- Outillage
- OSV-Scanner Trivy
Correspondances & menaces parées 10 standards · 5 menaces
Un linter, formateur, framework de test ou outil de build exécute du code arbitraire par conception, via un fichier de configuration, un plugin ou une variable d'environnement contrôlés par l'attaquant (Living Off the Pipeline). Aucune faille n'est nécessaire : la fonctionnalité légitime sert d'exécution LOTP CICD-SEC-4. Une donnée contrôlée par l'attaquant (titre de PR, nom de branche, message de commit) est interpolée sans échappement dans un script de workflow, provoquant une exécution de commande dans le pipeline. C'est l'injection classique portée au CI CICD-SEC-4. Un paquet exécute du code arbitraire via ses scripts de cycle de vie (postinstall, preinstall) dès l'installation, avant tout usage. L'ajout d'une dépendance suffit à déclencher la charge SoK LOTP. Un plugin ou une extension de l'outil de build (Gradle, Maven, bundler) exécute du code au moment de la construction, hors de toute revue du code applicatif. Le build devient un vecteur d'exécution tierce SoK LOTP. 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.
Les familles de ce domaine
Section intitulée « Les familles de ce domaine »Le détail est organisé par famille de contrôle. Chaque famille a sa page dédiée.