On ne croit pas un fournisseur sur parole : il prouve qu'il développe proprement. Cette famille (S2, domaine Fournisseurs) exige un cycle de développement sécurisé documenté (référentiel SSDF), un processus de gestion des vulnérabilités avec délais de correction, et des pratiques de pipeline cohérentes avec l'OWASP CI/CD Top 10.
Un fournisseur qui code sans SDLC sécurisé vous livre des failles introduites en amont, que vos propres scans ne rattrapent pas toujours. Sans processus de gestion des vulnérabilités ni délais annoncés, une faille découverte dans son produit reste exploitable chez vous, sans visibilité ni échéance. Et comme son pipeline est votre surface d'attaque indirecte (c'est là qu'un attaquant injecte une charge dans l'artefact que vous installerez), des pratiques alignées sur l'OWASP CI/CD Top 10 (secrets, permissions, intégrité du build) réduisent le risque qu'une compromission amont vous soit livrée signée.
Concrètement, ces exigences parent : les failles introduites en amont par un fournisseur sans cycle sécurisé, la vulnérabilité jamais corrigée ni divulguée, et la compromission de son pipeline qui vous livre une charge de confiance. Trois exigences de niveau renforcé (R2).
Un fournisseur aux pratiques faibles propage ses failles dans vos produits.
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 »cycle de développement sécurisé documenté (référentiel SSDF).#
Un fournisseur qui code sans SDLC sécurisé vous livre des failles introduites en amont, que vos scans ne rattrapent pas toujours. Exiger un cycle de développement documenté (référentiel SSDF, couvrant PO/PS/PW/RV) atteste qu'il intègre la sécurité dès la conception, pas comme un vernis de fin de chaîne.
- Preuve attendue
- Documentation du SDLC sécurisé du fournisseur (réf. SSDF).
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.
gestion des vulnérabilités : processus, délais de correction, politique de divulgation.#
Une faille dans un produit tiers ne vaut que si le fournisseur la corrige et la divulgue vite. Sans processus de gestion des vulnérabilités ni délais annoncés, vous restez exposé sans visibilité. Une politique de divulgation (et des avis CSAF) vous permet de planifier vos propres correctifs à temps.
- Preuve attendue
- Politique de gestion des vulnérabilités et de divulgation du fournisseur.
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).
pratiques de sécurité du pipeline cohérentes avec l'OWASP CI/CD Top 10.#
Le pipeline du fournisseur est votre surface d'attaque indirecte : c'est là qu'un attaquant injecte une charge dans l'artefact que vous installerez. Demander des pratiques alignées sur l'OWASP CI/CD Top 10 (secrets, permissions, intégrité du build) réduit le risque qu'une compromission amont vous soit livrée signée.
- Preuve attendue
- Éléments attestant des pratiques CI/CD du fournisseur.
Correspondances & menaces parées 3 standards · 1 menace
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.