Connaître précisément ce qu'on intègre est le préalable de tout : composition directe et transitive. Cette famille (I1, domaine Intégration) impose une analyse de composition (SCA) à chaque build, des lockfiles (versions verrouillées) et un SBOM complet par artefact.
Une faille arrive le plus souvent par une dépendance transitive que personne n'a choisie explicitement : sans inventaire des directes et transitives, répondre à « suis-je exposé à ce CVE ? » est impossible. Sans lockfile, deux builds tirent des versions différentes, ouvrant la porte à une substitution silencieuse. Et un SBOM généré au build puis conservé est l'archive interrogeable qui, des mois plus tard, retrouve en minutes quels artefacts embarquent un composant compromis, comme lors de Log4Shell.
Concrètement, ces exigences parent : l'exposition inconnue à un CVE faute d'inventaire, la faille cachée dans une dépendance transitive, le SBOM introuvable le jour de l'incident, et le maillon d'origine douteuse invisible sans graphe de provenance. Trois exigences, des fondamentales (R1) aux renforcées (R2).
Une dépendance transitive malveillante passe inaperçue sans inventaire complet.
Les pièges à éviter
Section intitulée « Les pièges à éviter »Les erreurs les plus fréquentes sur ce périmètre :
Exigences
Section intitulée « Exigences »inventaire des dépendances directes et transitives à chaque build (analyse de composition).#
Une faille arrive le plus souvent par une dépendance transitive que personne n'a choisie explicitement. Inventorier directes et transitives à chaque build donne la liste complète de ce qui s'exécute réellement : sans cet inventaire, répondre à « suis-je exposé à ce CVE ? » est impossible.
- Preuve attendue
- Rapport SCA listant dépendances directes et transitives à chaque build.
- Outillage
- OSV-Scanner Trivy Dependency-Track Renovate
Correspondances & menaces parées 4 standards · 1 menace
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).
SBOM de build généré et conservé pour chaque artefact.#
Un SBOM généré puis jeté ne sert à rien le jour d'un incident. Générer et conserver un SBOM par artefact crée l'archive interrogeable qui permet, des mois plus tard, de retrouver en minutes quels artefacts embarquent un composant vulnérable, au lieu de tout reconstruire pour le savoir.
- Preuve attendue
- SBOM de build (CycloneDX/SPDX) conservé par artefact.
- Outillage
- OSV-Scanner Trivy Dependency-Track Renovate
Correspondances & menaces parées 4 standards · 1 menace
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).
graphe de provenance des dépendances (origine, intégrité) tracé.#
Savoir qu'on dépend d'un composant ne dit pas d'où il vient ni s'il est intègre. Tracer un graphe de provenance (origine, intégrité) révèle un maillon substitué ou d'origine douteuse, et transforme l'arbre de dépendances en chaîne de confiance vérifiable plutôt qu'en boîte noire.
- Preuve attendue
- Graphe de provenance des dépendances (origine, intégrité).
- Outillage
- OSV-Scanner Trivy Dependency-Track Renovate
Correspondances & menaces parées 3 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. 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).