Aller au contenu
Sécurité medium

Gestion des dépendances open-source (SOCLE FRN)

5 min de lecture

Votre fournisseur consomme lui aussi de l'open source : son hygiène devient la vôtre. Cette famille (S4, domaine Fournisseurs) exige une politique de consommation OSS maîtrisée (référentiel S2C2F), un suivi des vulnérabilités des dépendances (OSV) avec capacité de réaction, et le verrouillage des versions pour la reproductibilité.

Tirer une dépendance OSS directement du registre public, sans politique, expose au typosquatting et aux paquets piégés : une consommation maîtrisée (référentiel S2C2F) impose proxy interne, validation et provenance. Une dépendance saine aujourd'hui devient vulnérable demain quand un CVE paraît : sans suivi continu (base OSV) et capacité de réaction, on l'apprend tard. Et sans lockfile, deux builds du même code tirent des versions différentes, ouvrant la porte à l'injection silencieuse d'une version remplacée entre-temps.

Concrètement, ces exigences parent : le typosquatting et les paquets piégés tirés sans politique, la dépendance devenue vulnérable non suivie, et l'injection de version entre deux builds faute de verrouillage. Trois exigences, des fondamentales (R1) aux renforcées (R2).

L'enjeu

Une dépendance OSS non suivie expose à une CVE ou à un retrait soudain.

Les erreurs les plus fréquentes sur ce périmètre :

consommation OSS non encadrée
vulnérabilités non suivies (OSV)
versions non verrouillées
Comment lire R1R2R3du fondamental au souverain Doitobligatoire Devraitrecommandé Chaque carte porte son énoncé, le pourquoi, la preuve attendue et ses correspondances aux standards.
Afficher
SOCLE-FRN-OSS-1 R1 Doit

politique de consommation OSS maîtrisée (référentiel S2C2F).#

Tirer une dépendance OSS directement du registre public, sans politique, expose au typosquatting et aux paquets piégés. Une consommation OSS maîtrisée (référentiel S2C2F) impose proxy interne, validation et provenance : on ne consomme plus n'importe quoi, n'importe comment, depuis n'importe où.

Preuve attendue
Politique de consommation OSS du fournisseur (réf. S2C2F).
Correspondances & menaces parées 3 standards · 2 menaces
Menaces parées

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.

SOCLE-FRN-OSS-2 R1 Doit

suivi des vulnérabilités des dépendances (OSV) et capacité de réaction.#

Une dépendance saine aujourd'hui devient vulnérable demain quand un CVE est publié : sans suivi continu (base OSV), vous l'apprenez tard. Surveiller les vulnérabilités des dépendances et garder une capacité de réaction (correctif, contournement) transforme une découverte en action, au lieu d'une exposition qui s'éternise.

Preuve attendue
Dispositif de suivi des vulnérabilités de dépendances et délais de réaction.
Outillage
OpenSSF Scorecard
Correspondances & menaces parées 3 standards · 2 menaces
Menaces parées

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 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é).

SOCLE-FRN-OSS-3 R2 Doit

verrouillage des versions et reproductibilité des dépendances.#

Sans lockfile, deux builds du même code tirent des versions différentes : une dépendance peut être remplacée entre-temps sans que personne ne le voie. Verrouiller les versions et viser la reproductibilité garantit que ce qui est audité est exactement ce qui est livré, et coupe l'injection silencieuse de versions piégées.

Preuve attendue
Lockfiles et preuve de reproductibilité fournis.
Outillage
OpenSSF Scorecard
Correspondances & menaces parées 3 standards · 1 menace
Correspondance
Menaces parées

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).

Ce site vous est utile ?

Sachez que moins de 1% des lecteurs soutiennent ce site.

Je maintiens +700 guides gratuits, sans pub ni tracking. Un soutien, même symbolique, m'aide à couvrir l'hébergement et à garder ces ressources gratuites. Merci pour votre appui.

Le formulaire ne s'affiche pas ? Ouvrir Ko-fi dans un onglet.

Abonnez-vous et suivez mon actualité DevSecOps sur LinkedIn