Cyber Resilience Act : Comment on a automatisé la détection de CVE pour livrer un logiciel plus sûr et transparent

Le Cyber Resilience Act (CRA), entré en application progressive depuis 2024, impose désormais aux éditeurs de logiciels des obligations concrètes : tracer les vulnérabilités connues, notifier les clients, et fournir des correctifs gratuits pendant 5 ans. Ce n'est plus une recommandation, c'est une exigence légale avec des deadlines fermes.

• Suivre les KEV (Known Exploited Vulnerabilities) sur toutes les releases depuis 2024, deadline : septembre 2026.
• Fournir le SBOM à vos clients, avec toute nouvelle release CVE-free, deadline : décembre 2027.

Voici comment notre équipe a transformé cette contrainte réglementaire en processus automatisé, ancré dans notre pipeline CI/CD quotidien.

‍

Le problème : vous ne savez pas ce que vous livrez

Un logiciel moderne n'est jamais seul. Notre produit industriel embarque :

• Des dizaines de packages NuGet côté backend (.NET 8) ;
• Plus de 1000 dépendances npm côté frontend (Vue.js / TypeScript) ;
• Des composants tiers lourds livrés avec le produit : moteur de recherche, base de données, broker MQTT, protections logicelles.

À chaque release, la vraie question est : parmi tout ça, combien ont des vulnérabilités connues exploitables et notre client est-il au courant ?

‍

Avant le CRA, la réponse honnête était : on ne sait pas vraiment. Or, depuis le CRA, l'ignorance n'est plus une option.

‍

Un scénario concret : de la détection à la remédiation

Pour illustrer comment tout s'articule, voici un cas type représentatif de ceux rencontrés en pratique.

Le scan quotidien détecte que le package acme-utils (version 2.3.1), présent dans la chaîne de dépendances du frontend, affiche un CVSS de 7.5 et un score EPSS de 78%. Son CVSS n'est pas exceptionnel, mais un EPSS de 78% signifie que cette vulnérabilité est activement ciblée dans la nature. Sans scan automatisé, cette dépendance transitive, jamais référencée directement dans le code métier, serait passée inaperçue à chaque release.

‍

Chaîne d'actions déclenchée :

• Détection automatique : le scanner signale le package. Le badge Jenkins passe en "unstable". L'équipe est notifiée sans bloquer le build.
• Triage : le plan d'action est mis à jour. Le package est classé priorité 1 (EPSS > 50%).
• Analyse d'exposition : acme-utils est utilisé par un outil de build dans la chaîne de compilation, pas directement par le code de production. L'exposition réelle est limitée, mais le package est présent dans les artefacts livrés.
• Décision : mise à jour planifiée et intégrée dans le sprint suivant.
• Vérification : le scan suivant confirme la disparition du package de la liste CVE. Le plan d'action est clos avec la date et le numéro de build.

Ce flux, détecter → trier → analyser → décider → vérifier, est le cœur du processus. Tout le reste de l'article décrit comment on l'a industrialisé.

‍

L'outil central : le SBOM (Software Bill of Materials)

Un SBOM est l'inventaire exhaustif de toutes les dépendances d'un build — l'équivalent d'une liste d'ingrédients pour votre logiciel. C'est le document que le CRA exige de fournir à vos clients d'ici 2027, mais aussi le point de départ de toute démarche de sécurité sérieuse.

‍

Black Duck : l'outil qui fait le lien entre votre code et les bases CVE

Black Duck (Synopsys) est une plateforme d'analyse de composition logicielle (SCA — Software Composition Analysis). Son rôle : analyser les artefacts de votre build, identifier chaque composant et sa version, puis croiser cet inventaire avec plusieurs bases de données de vulnérabilités.

‍

Concrètement, Black Duck interroge :

• NVD (National Vulnerability Database) - la base de référence maintenue par le NIST, qui liste toutes les CVEs publiées avec leur score CVSS officiel.
• CISA KEV (Known Exploited Vulnerabilities) - la liste des vulnérabilités pour lesquelles une exploitation active dans la nature a été confirmée. C'est le signal d'alarme le plus fort : si votre produit contient un KEV, la menace est réelle et immédiate.
• Les bases propriétaires Synopsys - enrichies avec des données de recherche, des scores EPSS, et des informations de patch.

Ce qui différencie Black Duck d'un simple npm audit ou dotnet list package — vulnerable : il analyse les artefacts binaires compilés, pas seulement les manifests. Il peut détecter des dépendances embarquées dans des archives .zip ou des répertoires tiers — exactement ce dont on a besoin quand on livre des composants tiers avec son installeur.

‍

Comprendre les CVE et leur classification

Une CVE (Common Vulnerabilities and Exposures) est un identifiant unique attribué à une vulnérabilité de sécurité connue. Format : CVE-ANNÉE-NUMÉRO. Exemple : CVE-2021-44228 — la célèbre faille Log4Shell.

Le score CVSS : mesurer la gravité

Le CVSS (Common Vulnerability Scoring System) donne un score de 0 à 10 qui évalue la gravité d'une vulnérabilité selon plusieurs critères : vecteur d'attaque, complexité, privilèges requis, impact sur la confidentialité / l'intégrité / la disponibilité.

‍

‍

Le score EPSS : mesurer le risque réel d'exploitation

Le CVSS seul ne suffit pas. Un CVE CVSS 9.8 avec un EPSS à 2% sur une fonctionnalité que vous n'utilisez pas est moins urgent qu'un CVE CVSS 7.0 avec un EPSS de 80%.

L'EPSS (Exploit Prediction Scoring System) estime la probabilité qu'une vulnérabilité soit activement exploitée dans les 30 prochains jours, sur une échelle de 0% à 100%. C'est une donnée dynamique, recalculée chaque semaine, qui tient compte de l'existence de PoC publics, de l'activité sur les forums d'attaquants, et de la diffusion dans les outils d'exploitation.

Les KEV : la liste rouge

Les KEV (Known Exploited Vulnerabilities) constituent la liste publiée par la CISA des vulnérabilités pour lesquelles une exploitation active dans la nature a été confirmée. Si votre produit contient un KEV, ce n'est plus une probabilité — c'est une menace documentée qui peut toucher vos clients aujourd'hui. Le CRA exige leur signalement, et notre pipeline bloque toute release contenant un KEV.

‍

L'intégration CI/CD : scan intelligent, pas scan systématique

Faire tourner un scan CVE sur chaque commit serait prohibitif (chaque scan implique des appels API externes et une analyse d'archive). Notre stratégie de déclenchement :

Le stage Jenkins vérifie la cause du build (TimerTrigger, SCMTrigger, ou flag manuel) pour décider si le scan doit s'exécuter. Les builds à la demande des développeurs ne le déclenchent pas — seuls les scans programmés ou explicitement activés le font.

Résultat : cycle de build rapide au quotidien, couverture de sécurité systématique en arrière-plan.

‍

Le dashboard de visibilité : savoir en un coup d'oeil

Un scan qui produit un rapport de 200 pages que personne ne lit, ça ne change rien. Nous avons intégré un système de badges visuels directement dans Jenkins, visibles sur chaque build sans outil externe.

‍

Ces badges sont générés automatiquement depuis les variables d'environnement exposées par le scan (CVE_STATUS, CVE_TOTAL, CVE_CRITICAL, CVE_KEV, CVE_HIGHEST_CVSS). N'importe qui dans l'équipe — dev, lead, PO — connaît l'état de sécurité d'un build en un regard.

La logique est volontairement progressive : le build passe en unstable (jamais en failed) en cas de CVE critique, pour rester visible sans bloquer les livraisons pendant la phase de nettoyage.

‍

Des scripts pour automatiser l'analyse et tenir les plans d'action à jour

Le scan Black Duck produit un rapport brut. Pour le rendre exploitable au quotidien, nous avons développé deux scripts complémentaires.

Le premier transforme le rapport en livrables structurés : des fichiers CSV par composant du produit et un rapport HTML executive, publiés directement depuis Jenkins. Sans intervention manuelle, le développeur ouvre son rapport filtré et prêt à l'analyse.

Le second vérifie la couverture du scan : il compare les manifests de dépendances réels (yarn.lock, deps.json) avec ce que Black Duck a effectivement détecté. Résultat : une liste des packages absents du SBOM, qui alimente directement le rapport de gaps maintenu par l'équipe.

Pour chaque composant du produit, l'équipe maintient un plan d'action de remédiation CVE versionné dans le dépôt, mis à jour après chaque scan. L'objectif : que n'importe quel développeur qui reprend le dossier sache en 30 secondes où en est la remédiation, sans fouiller les archives Jenkins.

‍

L'objectif : livrer un produit dont le client connaît le contenu

Toute cette mécanique sert un objectif simple à formuler, mais complexe à atteindre : que le client sache exactement ce que contient notre produit, et que ce contenu soit le plus sûr possible.

‍

Conclusion

1. Détection continue avant la production.

Les vulnérabilités sont identifiées sur le trunk et les branches dès leur introduction, pas au moment de la release. Plus on détecte tôt, moins la correction coûte cher.

‍

2. Priorisation structurée.

Notre grille : KEV en priorité absolue (exploitation confirmée), puis CVSS ≥ 9 avec EPSS élevé (risque imminent), puis CVSS 7–8.9, puis migrations EOL planifiées. Le CVSS seul ne suffit pas — l'EPSS est le second critère indispensable.

‍

3. Un SBOM à jour à chaque build.

Le SBOM n'est pas un document produit une fois par an. C'est un artefact automatiquement généré, versionné, et archivé à chaque build. Le client a accès au SBOM correspondant à sa version installée.

‍

4. Transparence totale.

Conformément au CRA, toute vulnérabilité de type KEV est signalée et communiquée. Le client n'est pas uniquement livré avec un produit — il est livré avec la connaissance de ce qu'il contient.

‍

Les leçons apprises

• Le SBOM est un artefact vivant

Il se périme à chaque build. Un SBOM statique n'a aucune valeur opérationnelle.

‍

• CVSS sans EPSS, c'est incomplet.

Un CVSS 9.8 sur un vecteur non applicable vaut moins qu'un CVSS 7.5 avec EPSS 80%. Combiner les deux scores change radicalement les priorités.

‍

• La visibilité change les comportements.

Depuis que les badges CVE apparaissent sur chaque build Jenkins, les développeurs consultent spontanément l'état de sécurité. Un indicateur visible est un indicateur actionnable.

• Les composants tiers sont votre responsabilité.

Si vous livrez un moteur de recherche ou un broker MQTT avec votre produit, leurs vulnérabilités internes sont les vôtres. Les inclure dans le scope SBOM, c'est accepter cette réalité — et la gérer proactivement.

• Le CRA n'est qu'un problème de sécurité, c'est un problème de processus.

La partie technique est la plus simple. La vraie difficulté, c'est d'intégrer la culture de la remédiation dans le cycle de développement sans bloquer les équipes.