Plutôt que tirer directement depuis l'internet public, on filtre l'open source à l'entrée. Cette famille (I2, domaine Intégration) impose un miroir/proxy interne contrôlé, un délai de quarantaine (cooldown) avant d'adopter une nouvelle version, et la détection des paquets malveillants (typosquatting, analyse comportementale, pas seulement les CVE).
Tirer un paquet directement du registre public expose au typosquatting, aux paquets retirés et à la dépendance d'un service externe : un miroir/proxy interne contrôlé filtre, met en cache et trace ce qui entre. Les paquets malveillants étant souvent retirés en quelques jours, un délai de quarantaine avant adoption laisse la communauté détecter une charge. Et un scanner de CVE ne voit pas un paquet délibérément malveillant récent : l'analyse comportementale attrape le typosquatting et les charges cachées que les CVE ignorent encore.
Concrètement, ces exigences parent : le typosquatting et le paquet piégé tirés du registre public, la version malveillante adoptée trop vite faute de cooldown, la confiance aveugle au binaire amont (cas xz-utils), et la résolution détournée sans allowlist de registres. Quatre exigences, des renforcées (R2) aux souveraines (R3).
Sans filtrage, typosquatting et protestware entrent directement dans le build.
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élai de quarantaine (cooldown) avant adoption d'une nouvelle version de dépendance.#
Les paquets malveillants sont souvent retirés en quelques jours, une fois signalés. Observer un délai de quarantaine avant d'adopter une nouvelle version de dépendance laisse à la communauté le temps de détecter une charge : on évite la fenêtre où le paquet piégé est encore publié.
- Preuve attendue
- Politique de cooldown configurée avant adoption d'une nouvelle version.
- Outillage
- OpenSSF Scorecard
Correspondances & menaces parées 2 standards · 3 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. 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.
allowlist des registres et sources de paquets autorisés.#
Laisser un build tirer des paquets de n'importe quel registre ouvre la porte au détournement de résolution et aux sources non fiables. Une allowlist des registres et sources autorisés borne d'où viennent les dépendances, condition pour appliquer ensuite proxy, filtrage et vérification de provenance de façon cohérente.
- Preuve attendue
- Allowlist des registres et sources de paquets autorisés.
- Outillage
- OpenSSF Scorecard
Correspondances & menaces parées 2 standards · 1 menace
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.
reconstruction depuis les sources des dépendances critiques (pas de confiance aveugle aux binaires amont).#
Faire confiance au binaire amont d'une dépendance critique, c'est croire que le code publié correspond aux sources : l'attaque xz-utils a montré le contraire. Reconstruire depuis les sources les composants critiques élimine cette confiance aveugle et révèle un binaire qui divergerait de son code.
- Preuve attendue
- Pipeline de rebuild from source documenté pour les dépendances critiques ; artefacts reconstruits comparés à l'amont.
- Outillage
- Bazel
Correspondances & menaces parées 3 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).
correctifs de sécurité des dépendances remontés en amont (contribution upstream) plutôt que forks privés divergents non maintenus.#
Un correctif appliqué dans un fork privé non maintenu se reperd à la mise à jour suivante et accumule une dette invisible. Remonter les correctifs en amont (upstream) les pérennise dans la source commune, évite la divergence silencieuse et profite à tout l'écosystème plutôt qu'à une rustine locale fragile.
- Preuve attendue
- Politique de contribution upstream ; suivi des correctifs proposés/acceptés ou des forks temporaires tracés et résorbés.