news

Le **30 juillet 2026**, la **Fondation Eclipse** et l'**OWASP** ont annoncé un protocole d'accord pour travailler ensemble sur la sécurité de l'open source. Un protocole d'accord n'est ni une norme, ni un outil, ni une échéance. À lui seul, il ne change rien à votre build cette semaine.

La date à noter est celle qui se trouve derrière. Au titre du **Cyber Resilience Act** européen, les **obligations de signalement des vulnérabilités et des incidents pour les fabricants entrent en vigueur le 11 septembre 2026**. Cela fait environ cinq semaines au moment où ces lignes sont écrites et, contrairement à un protocole, c'est une échéance juridique.

Ce que le CRA exige réellement

Le CRA est un règlement européen qui impose des exigences de cybersécurité obligatoires aux produits comportant des éléments numériques mis à disposition dans l'Union. L'expression *produits comportant des éléments numériques* est volontairement large : ce n'est pas une règle sur les logiciels de sécurité, c'est une règle sur tout ce qui est livré avec du code dedans.

La partie qui concerne ce site est plus discrète et plus structurelle. Le CRA **reconnaît formellement les intendants de logiciels open source comme des participants importants de la chaîne d'approvisionnement logicielle**. C'est un changement de statut. Les fondations, et les personnes qui maintiennent des composants très utilisés, cessent d'être un amont invisible pour devenir des participants nommés, avec leurs propres responsabilités.

Ce qui nous amène à l'acronyme au centre de l'annonce : le **SBOM**, la nomenclature logicielle. Parmi les priorités initiales listées par les deux fondations figurent des ressources destinées à soutenir l'adoption du SBOM et la sécurité de la chaîne d'approvisionnement logicielle.

Un SBOM est un problème de versions

Un SBOM gagne à être compris comme un **problème de versions**, parce que c'en est un. C'est l'inventaire de chaque composant présent dans un logiciel et, surtout, de **la version de chacun**. Non pas « nous utilisons OpenSSL » mais « nous livrons OpenSSL 3.2.1 ». L'écart entre ces deux phrases est celui qui sépare « nous sommes peut-être concernés par cette vulnérabilité » de « nous le sommes, ou non ».

• Des recommandations pratiques pour les intendants open source, ce rôle que le CRA vient de reconnaître
• Des webinaires communs de préparation au CRA
• Des ressources pour soutenir l'adoption du SBOM
• Des ressources sur la sécurité de la chaîne d'approvisionnement logicielle
• Des événements et ateliers communautaires
• Des tables rondes de mainteneurs

C'est pour cela que ce fichier est plus difficile à produire qu'il n'y paraît, et qu'il échoue exactement là où la gestion de dépendances échoue : les dépendances transitives que personne n'a choisies directement, les plages de versions qui ont résolu autre chose mardi dernier, les copies vendorisées sans manifeste, et les fichiers de verrouillage jamais commités. Si vous avez déjà été incapable de répondre à *quelle version de ceci tourne réellement*, vous connaissez déjà la forme du problème.

Les autres priorités annoncées sont pratiques plutôt que techniques, et elles disent quelque chose de qui, selon les deux fondations, est en difficulté. Les voici.

Il vaut la peine d'être précis sur ce que cet accord n'est pas. Ce n'est pas une certification, il ne rend personne conforme au CRA, et il ne déplace aucune responsabilité juridique. Les deux directeurs exécutifs l'ont présenté comme une affaire de traduction plutôt que d'autorité. Mike Milinkovich, de la Fondation Eclipse, a relevé que l'open source est une infrastructure numérique critique mais que la responsabilité de sa sécurisation est répartie sur un écosystème mondial complexe. Andrew van der Stock, de l'OWASP, a formulé le même constat par l'autre bout : les recommandations de sécurité ne font une différence que lorsque les développeurs, les mainteneurs et les organisations peuvent les mettre en pratique.

Le résumé honnête, pour quiconque livre du logiciel dans l'Union : le protocole est un signal organisationnel, et les signaux organisationnels sont lents. L'obligation du 11 septembre ne l'est pas. Si vous ne savez pas produire aujourd'hui une liste exacte de ce que vous livrez et dans quelles versions, c'est là qu'est le travail, et c'est un travail de gestion de versions avant d'être un travail de conformité.

Ce que l'accord n'est pas