Le rapport OSSRA 2026 : un doublement des vulnérabilités
Black Duck publie chaque année son OSSRA (Open Source Security and Risk Analysis), l'un des audits les plus larges du secteur. L'édition 2026 couvre 947 codebases commerciales dans 17 industries. Le constat est sans appel : en un an, le nombre moyen de vulnérabilités par codebase a doublé.
Les chiffres sont brutaux :
- +107% de vulnérabilités — 581 failles en moyenne par codebase
- 87% des codebases contiennent au moins un composant à risque
- 65% des organisations ont déjà subi une attaque supply chain
Ce n'est pas une dégradation progressive — c'est un doublement sur douze mois.
Le rapport établit un lien direct avec l'adoption massive des outils d'IA coding. Les assistants IA importent des dépendances à grande vitesse — sans vérification des licences, sans audit de sécurité, sans validation de la supply chain. Résultat : une prolifération de dépendances non-auditées en production.
Les chiffres clés du rapport OSSRA 2026
| Métrique | Valeur 2026 | Signal |
|---|---|---|
| Codebases avec composants à risque | 87% | Quasi-universelle |
| Augmentation des vulnérabilités / codebase | +107% (doublement) | Accélération critique |
| Vulnérabilités moyennes par codebase | 581 | Intraitable manuellement |
| Organisations ayant subi une attaque supply chain | 65% | Risque déjà matérialisé |
| Codebases auditées / industries couvertes | 947 / 17 | Échantillon représentatif |
Pourquoi l'IA coding amplifie-t-elle ce problème ?
Le mécanisme est simple : quand un développeur demande à un agent IA de coder une fonctionnalité, l'IA importe des packages sans analyser leur provenance, leur historique de vulnérabilités ou la compatibilité de leur licence.
C'est le paradoxe de productivité de l'IA coding : les équipes livrent plus vite, mais accumulent une dette de sécurité à un rythme inédit. Chaque sprint gagné peut cacher des dizaines de dépendances non-vérifiées.
Le problème est structurel. Sans ces deux garde-fous, la dette s'accumule silencieusement :
- Un SBOM (Software Bill of Materials) généré automatiquement à chaque build
- Une politique de cooldown sur les nouvelles dépendances introduites par l'IA
Quel impact pour les équipes DevSecOps ?
L'EU Cyber Resilience Act (CRA) impose ses premières obligations de signalement dès septembre 2026 — dans six mois. Le rapport Black Duck est clair : sans traçabilité des modèles IA dans la chaîne de production logicielle, la conformité est impossible.
Concrètement : si votre pipeline CI/CD intègre Copilot, Cursor ou Claude Code, chaque dépendance introduite par ces outils doit être traçable dans votre SBOM.
Le calcul qui fait mal
20 services × 29 dépendances chacun = 11 600+ points de dépendances à surveiller. Dont 87% contiennent potentiellement des composants à risque. À 581 vulnérabilités par codebase, traiter le problème manuellement est impossible.
Le coût FinOps est réel : un incident de sécurité coûte en moyenne 4,88 millions de dollars (IBM Cost of a Data Breach 2024, tous types de breaches confondus). Avec 581 vulnérabilités par codebase, la probabilité qu'un incident passe par une dépendance open source augmente mécaniquement.
Notre analyse
L'échantillon est biaisé vers des organisations qui auditent — les chiffres pourraient donc sous-estimer la situation réelle. Mais un doublement sur 1 000 codebases dans 17 industries est un signal d'alarme industriel.
Le lien avec l'IA coding est cohérent avec ce que tout le secteur observe : Copilot, Cursor et équivalents ont été adoptés massivement en 2024-2025. La production de code a explosé — sans que les pratiques de sécurité open source aient suivi.
La priorité n'est pas de bannir les outils IA. C'est d'intégrer la sécurité directement dans le flux IA. Trois actions avant septembre 2026 :
- Automatiser le SBOM dans chaque pipeline CI/CD
- Délai de validation d'une semaine avant l'adoption automatique d'une dépendance IA
- SCA (Software Composition Analysis) avec priorisation contextuelle pour rendre 581 vulnérabilités traitables
