OWASP Top 10 des risques de l’open source : au-delà des CVE

Ce référentiel part d’un constat que la plupart des outils de gestion de dépendances contredisent par leur existence même : une liste de vulnérabilités connues ne mesure qu’une petite part du risque qu’on prend en ajoutant une dépendance. La gestion du risque open source a commencé par les licences, a évolué vers les CVE, et n’a toujours pas d’approche d’ensemble couvrant les aspects de sécurité, juridiques et opérationnels. Les dix entrées de la liste, codées OSS-RISK-1 à OSS-RISK-10, cherchent à combler ce trou. Quatre d’entre elles ne décrivent aucune faille.

→ Lire l’explication complète de la marmotte

Les dix risques

Code	Titre officiel	Traduction
OSS-RISK-1	Known Vulnerabilities	Vulnérabilités connues
OSS-RISK-2	Compromise of Legitimate Package	Compromission d’un paquet légitime
OSS-RISK-3	Name Confusion Attacks	Attaques par confusion de nom
OSS-RISK-4	Unmaintained Software	Logiciel non entretenu
OSS-RISK-5	Outdated Software	Logiciel périmé
OSS-RISK-6	Untracked Dependencies	Dépendances non suivies
OSS-RISK-7	License Risk	Risque de licence
OSS-RISK-8	Immature Software	Logiciel immature
OSS-RISK-9	Unapproved Change	Modification non approuvée
OSS-RISK-10	Under/Over-sized Dependency	Dépendance sous- ou sur-dimensionnée

Attention à la forme du code : ce n’est pas « OSS1 » mais OSS-RISK-1. Le détail compte pour chercher une référence, et le référentiel est le seul de la famille à employer cette convention.

Quatre entrées qui ne décrivent aucune faille

C’est l’apport propre de ce document, et la raison de le lire même quand on dispose déjà d’un outil d’analyse de composition logicielle.

OSS-RISK-4, le logiciel non entretenu. Un composant n’est plus développé activement, donc les correctifs — fonctionnels comme de sécurité — ne viendront pas, ou pas à temps. La conséquence est transférée en aval : le développement du correctif incombe alors à des équipes qui connaissent moins bien le composant que ses auteurs, ce qui allonge les délais de résolution, et pendant ce temps il faut parfois restreindre l’accès ou la fonctionnalité pour limiter l’exposition. Les exemples cités par le référentiel sont des bibliothèques à très large diffusion : core-js, minimist, le Gorilla Web Toolkit. Aucune CVE n’apparaîtra jamais pour signaler qu’un projet s’est arrêté.

OSS-RISK-5, le logiciel périmé. Le risque n’est pas la version ancienne mais la distance accumulée. Prendre trop de retard sur les versions rend difficile une mise à jour d’urgence, par exemple quand une vulnérabilité est publiée pour la version en service ; les anciennes versions ne reçoivent pas forcément la même évaluation de sécurité que les récentes, de sorte qu’on ne sait pas toujours si elles sont concernées ; et si la nouvelle version est syntaxiquement ou sémantiquement incompatible, la migration demande un effort considérable. Le référentiel appuie son argument sur un chiffre : 89 % des bases de code contiennent du logiciel open source périmé de plus de quatre ans, et 91 % contiennent des composants sans nouveau développement depuis plus de deux ans. C’est le mécanisme de la dette de sécurité sous sa forme la plus mesurable.

OSS-RISK-7, le risque de licence. Un composant peut n’avoir aucune licence, en avoir une incompatible avec l’usage prévu, ou une dont les exigences ne sont pas — ou ne peuvent pas être — satisfaites en aval. Il peut aussi violer des termes de licence indépendamment de l’usage qu’on en fait, par exemple s’il est publié sous GPL tout en incluant des fichiers sous la licence BSD originale à quatre clauses. Le document mentionne enfin le conflit avec des exigences légales ou réglementaires, qui peut fermer l’accès à certains marchés. C’est la seule entrée de toute la famille des Top 10 OWASP dont la conséquence est une action en justice du détenteur des droits plutôt qu’une compromission.

OSS-RISK-8, le logiciel immature, et OSS-RISK-10, la dépendance mal dimensionnée. La première vise les projets qui n’appliquent pas de bonnes pratiques de développement : pas de schéma de versionnement standard, pas de suite de tests de régression, pas de règles de revue, pas de documentation — avec pour conséquence un composant qui peut ne pas fonctionner de façon fiable ni sûre. La seconde vise les deux extrêmes : le micro-paquet qui apporte trois lignes de fonctionnalité et une dépendance de plus à surveiller, et la bibliothèque massive dont on n’emploie qu’une fraction tout en embarquant la totalité de sa surface.

OSS-RISK-6 : la dépendance qu’aucun outil ne voit

C’est l’entrée la plus utile pour une équipe qui croit avoir le sujet sous contrôle, parce que son argument est logique plutôt que statistique : un composant qui passe sous le radar ne peut être vérifié ni surveillé pour aucun des neuf autres risques.

Le référentiel énumère les façons dont une dépendance échappe à l’inventaire, et la liste est instructive. Un inventaire logiciel incomplet reçu d’un composant amont, ou produit par un outil d’analyse. Du code tiers inclus dans une dépendance par ailleurs suivie : extraits de code recopiés, fichiers sources copiés tels quels dans les sources de la dépendance, code compilé rebundlé sous forme de binaires ou d’archives. Des dépendances installées hors des fichiers de manifeste des gestionnaires de paquets, par un script ou une commande système. Et les outils de développement eux-mêmes — extensions d’environnement, scripts de construction, dépendances de test — qui ne partent pas dans le produit livré mais portent des risques de sécurité et d’exploitation bien réels.

L’action recommandée est de comparer les outils d’analyse sur leur capacité à produire un inventaire exact à deux granularités : grossière, pour les dépendances déclarées dans un gestionnaire de paquets, et fine, pour les artefacts introduits hors bande. Le site traite le sujet dans savoir ce qui tourne vraiment et la généalogie des images de base.

OSS-RISK-2, 3 et 9 : quand le paquet change sans changer de nom

Ces trois entrées décrivent le volet offensif, et le référentiel les documente par des incidents nommés.

La compromission d’un paquet légitime passe par le détournement des comptes de mainteneurs ou l’exploitation de vulnérabilités dans les dépôts de paquets. Les exemples cités sont event-stream, dont la compromission visait les utilisateurs d’un portefeuille de cryptomonnaie, et SolarWinds. Le référentiel est explicite sur l’absence de solution unique : il n’existe aucune action isolée pour détecter et empêcher l’ingestion d’un paquet compromis, et il renvoie aux cadres existants — vérifier la provenance selon SLSA, construire le composant depuis les sources, relire le code, et ne récupérer les composants que depuis un dépôt interne sécurisé qui héberge les binaires maison et met en miroir les composants externes. Les niveaux SLSA et la signature des commits et des artefacts détaillent ces mesures.

La confusion de nom couvre trois techniques : la coquille typographique sur le nom d’un paquet légitime, l’usurpation d’un auteur digne de confiance, et le jeu sur les conventions de nommage entre langages ou écosystèmes. L’exemple canonique est Colourama, publié sur PyPI en 2018 en imitant le paquet légitime colorama et redirigeant des transferts vers un portefeuille contrôlé par l’attaquant. La recommandation contient une mise en garde qu’on oublie souvent : certaines métadonnées de paquet ne sont pas vérifiées par les dépôts, et peuvent donc être forgées sans difficulté. Le sujet a pris une tournure nouvelle avec l’hallucination de noms de paquets par les assistants de code, où l’attaquant n’a même plus besoin de choisir un nom proche d’un vrai : il suffit d’enregistrer celui qu’un modèle invente.

La modification non approuvée vise les cas où un composant change sans que les développeurs puissent le remarquer, le relire ou l’approuver : un lien de téléchargement qui pointe vers une ressource non versionnée, une ressource versionnée modifiée après coup, ou un transfert non sécurisé. C’est l’argument technique derrière l’épinglage par condensat plutôt que par étiquette, et derrière le verrouillage du comportement des dépendances et la confiance accordée aux mises à jour automatiques.

OSS-RISK-1 : les vulnérabilités connues ne sont pas le sujet

L’entrée existe, elle est première, et le document explique pourquoi elle ne suffit pas. Les vulnérabilités publiées capturent, écrivent les auteurs, les erreurs commises par des développeurs bien intentionnés : il faut les corriger, mais elles ne couvrent pas le spectre des risques que fait prendre une dépendance. Les exemples qu’ils donnent sont les deux plus cités du métier — la faille d’Apache Struts qui a mené à la brèche Equifax, et celle de Log4j connue sous le nom de Log4Shell.

Le chiffre qui recadre le sujet vient d’un travail de recherche cité par le référentiel : 95 % des vulnérabilités se trouvent dans des dépendances transitives, celles qu’un gestionnaire de paquets a installées automatiquement pour satisfaire les dépendances choisies. Beaucoup ne sont pas réellement atteignables depuis le code de l’application, et leur mise à jour provoquerait un enchaînement d’incompatibilités. D’où la priorisation recommandée : scores CVSS et EPSS, renseignement sur la disponibilité et la maturité du code d’exploitation, catalogue des vulnérabilités activement exploitées, et outils capables de déterminer si le code vulnérable est exécutable dans le contexte du logiciel dépendant. Le site traite ce point dans les dépendances transitives, un risque non choisi et comment lire un rapport OWASP Top 10.

Le rapport de forces vaut d’être retenu : les auteurs rappellent qu’entre le code écrit pour le projet lui-même et celui des composants open source qu’il embarque, le ratio est de un pour quatre ou moins. La partie du logiciel qu’on a écrite est la partie qu’on surveille le mieux, et c’est la plus petite.

Maturité et usage

Le document a été relu et enrichi par plus de vingt responsables de la sécurité et directeurs techniques, ce qui explique la présence des volets juridique et opérationnel : ce sont les risques qu’un comité de direction rencontre et qu’un outil de détection ignore. Il est en revanche daté de 2023 et son dépôt n’a reçu que des mises à jour mineures depuis ; il n’existe qu’une édition, donc aucune ambiguïté de numérotation.

Comme les autres référentiels de la famille, ce n’est pas une norme et personne n’est en conformité avec OSS-RISK-7. Le complément à ouvrir pour transformer ces risques en exigences vérifiables est le SCVS (Software Component Verification Standard) de l’OWASP, auquel le document renvoie lui-même entrée par entrée. Pour l’articulation avec une obligation réelle — notamment les exigences du règlement européen sur la cyberrésilience en matière d’inventaire et de gestion des vulnérabilités de composants —, c’est la rubrique Normes qui porte le sujet, et la façon de citer ces documents est traitée dans la page chapeau des Top 10 de l’OWASP.

🐝 Ce qui arrive si on s’en passe

Sans inventaire fin, une bibliothèque recopiée à l’intérieur d’une autre dépendance ou installée hors du gestionnaire de paquets n’apparaît dans aucun rapport : elle échappe simultanément aux neuf autres contrôles, et la question « sommes-nous concernés » reste sans réponse le jour de l’annonce. Sans suivi de l’entretien des projets, un composant abandonné depuis deux ans reste en service jusqu’à ce qu’une vulnérabilité soit publiée pour lui : il n’y aura pas de correctif amont, et l’équipe devra écrire le sien dans l’urgence, sur un code qu’elle ne connaît pas. Sans gestion de la distance aux versions courantes, la mise à jour d’urgence devient une migration, et l’exposition dure le temps de la migration. Sans épinglage par condensat, une ressource non versionnée change de contenu sans changer d’adresse, et la construction suivante intègre du code que personne n’a relu. Sans revue des licences, une dépendance incompatible se découvre au moment de la vente, et le risque se solde devant un tribunal plutôt que dans un correctif.

🦫 Explication de la marmotte 🍫

Presque tous les logiciels modernes sont construits à partir de briques gratuites, écrites par d’autres et récupérées sur Internet. Ces briques en utilisent elles-mêmes d’autres, qui en utilisent d’autres encore, et tout cela s’installe automatiquement. Dans un projet typique, le code écrit par l’équipe représente un cinquième du total, parfois moins.

Une association internationale de spécialistes publie la liste des dix risques que l’on prend en acceptant ces briques. Son apport est de ne pas se limiter aux failles de sécurité. Quatre des dix risques ne décrivent aucune erreur de programmation.

Le premier de ces quatre est l’abandon : une brique dont l’auteur a cessé de s’occuper ne recevra plus de correction, et le jour où un problème est découvert, c’est à ceux qui l’utilisent de le réparer — sur un code qu’ils ne connaissent pas. Le deuxième est le retard : plus on s’éloigne de la version actuelle, plus une mise à jour urgente devient un chantier. Le troisième est juridique : une brique sans licence, ou avec une licence incompatible avec l’usage qu’on en fait, expose à une action en justice. Le quatrième est l’immaturité : un projet sans tests, sans documentation et sans numérotation cohérente de ses versions peut simplement mal fonctionner.

Deux autres risques concernent les attaques. On peut prendre le contrôle du compte de l’auteur d’une brique connue et y glisser du code malveillant. Et on peut publier une brique au nom presque identique à une brique légitime, en espérant une faute de frappe.

Enfin, le risque qui conditionne tous les autres : ne pas savoir qu’une brique est là. Une brique invisible ne peut être vérifiée pour aucun des neuf autres problèmes.

Pages voisines

La citent

OWASP Top 10 des risques de l'open source : au-delà des CVE

Elle cite

: les deux pages se citent l’une l’autre.