Le code et les configurations passent des contrôles automatiques avant d'entrer. Cette famille (I5, domaine Intégration) impose un SAST intégré avec seuils bloquants, le scan des configurations (IaC, misconfigurations) et la revue avant fusion.
Détecter une faille après la mise en production coûte cher et expose les utilisateurs : un SAST intégré avec seuils bloquants sur les criticités hautes l'arrête dès le build. Une mauvaise configuration d'infrastructure (bucket public, port ouvert) est aussi dangereuse qu'une faille de code et bien plus fréquente : l'analyse IaC (Checkov, KICS) bloque la dérive avant le déploiement. Et un secret commité survit dans l'historique même supprimé : le secret scanning et la revue avant fusion forment le filet final côté code.
Concrètement, ces exigences parent : le secret commité qui survit dans l'historique, la mauvaise configuration IaC déployée, et la dépendance abandonnée ou sous licence incompatible non repérée. Trois exigences, des fondamentales (R1) aux renforcées (R2).
Une mauvaise config ou un secret commité crée une faille avant même l'exécution.
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 »détection de secrets dans le code et l'historique (pré-commit + CI).#
Un secret commité reste dans l'historique même après suppression du fichier : il est à considérer comme fuité. Le secret scanning en pré-commit et en CI, sur le code et l'historique, l'attrape avant la poussée ou alerte au plus tôt, fenêtre où la rotation reste maîtrisable.
- Preuve attendue
- Hooks de détection de secrets (pré-commit + CI) ; scan d'historique.
- Outillage
- OSV-Scanner cosign
Correspondances & menaces parées 2 standards · 1 menace
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.
analyse de configuration IaC (politiques de sécurité, absence de mauvaise configuration).#
Une mauvaise configuration d'infrastructure (bucket public, port ouvert) est aussi dangereuse qu'une faille de code et bien plus fréquente. L'analyse IaC (Checkov, KICS) applique des politiques au code d'infrastructure et bloque la dérive avant le déploiement, là où corriger ne coûte qu'un commit.
- Preuve attendue
- Rapport d'analyse de configuration IaC.
- Outillage
- OSV-Scanner cosign
Correspondances & menaces parées 2 standards · 1 menace
Le manifeste de déploiement est mal configuré (privilèges excessifs, montages sensibles, réseau ouvert), exposant la charge dès sa mise en service. La faiblesse n'est pas dans l'artefact mais dans la façon dont il est déployé (CIS Kubernetes) CIS K8s.
analyse de composition étendue (licences, qualité, score de maintenance).#
Une dépendance peut être saine côté CVE mais abandonnée, mal maintenue ou sous une licence incompatible : autant de risques futurs. Une SCA étendue (score de maintenance, licences, qualité) éclaire ces angles morts et oriente vers des composants durables, pas seulement « sans vulnérabilité connue aujourd'hui ».
- Preuve attendue
- Analyse de composition étendue (licences, score de maintenance).
- Outillage
- OSV-Scanner cosign
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é).