Gouvernance
Supply chain logicielle : le CRA sonne le réveil pour les éditeurs
Par La rédaction, publié le 01 janvier 2026
Entre dépendances transitives, briques open source et services tiers, la supply chain logicielle est devenue un actif critique… et une surface d’attaque. Face à la multiplication des cyberattaques contre cette supply chain, l’opacité des composants et la sécurité by design ne sont plus négociables pour les éditeurs, surtout à l’approche du Cyber Resilience Act.
De Guillaume Baudrit, Associate Architecture chez Onepoint
La supply chain logicielle n’a jamais été aussi complexe… et vulnérable. Chaque application déployée aujourd’hui repose sur un enchevêtrement de composants internes, de bibliothèques open source, de modules propriétaires, d’API et d’outils tiers. Ce maillage, qui permet certes d’innover plus vite, devient aussi le terrain de jeu idéal des attaquants. Des incidents comme SolarWinds ou Log4Shell ont montré qu’un seul maillon compromis peut avoir un effet domino mondial. Il ne s’agit plus de simples bugs, mais de brèches systémiques, capables de paralyser des chaînes industrielles entières ou d’ébranler la confiance des utilisateurs.
Pourtant, la sécurité de la chaîne logicielle reste encore trop souvent marginalisée. Le vrai problème ? L’opacité. Chaque composant embarque ses propres dépendances, dites transitives, formant un enchevêtrement difficile à auditer. Ce sont de véritables boîtes noires logicielles.
Sécurité by design : adopter une posture d’architecte
Dans un monde où l’industrialisation du développement est devenue la norme, ignorer cette réalité, c’est accepter de courir avec un bandeau sur les yeux. Pourtant, le principe du Shift Left Security, qui pousse à intégrer la sécurité dès les phases amont du développement, reste encore marginal. En cause : des freins financiers et humains. Les outils d’analyse de code, nécessaires pour cette approche, sont coûteux (licences, maintenance, intégration CI/CD) et doivent fonctionner en continu.
Même dans les grandes structures, les audits de sécurité n’évitent pas toujours l’exploitation de failles critiques. Pour les éditeurs plus modestes, le risque est de miser uniquement sur une vérification en bout de chaîne – une posture économiquement compréhensible, mais dangereusement naïve.
Surtout, la racine du problème est humaine. Les failles ne proviennent pas uniquement de technologies obsolètes, mais souvent de mauvaises pratiques de conception. Le Top 10 OWASP, qui recense les dix risques les plus critiques du moment en matière de sécurité des applications web, le montre clairement. Sans une équipe formée et dédiée à la dette technique, à la mise à jour des dépendances et à la veille sur les vulnérabilités, l’effort reste vain.
Aucun outil, aussi avancé soit-il, ne remplace le discernement humain. Beaucoup d’incidents sont liés à des erreurs ou des choix techniques non maîtrisés. D’autant qu’un facteur aggravant est apparu avec l’usage croissant de l’IA générative par des développeurs peu expérimentés. Copier-coller du code produit par une IA, sans en comprendre les implications, revient à importer de la complexité – voire des vulnérabilités – en aveugle. Pire encore lorsque ce code est mal documenté ou illisible. L’IA doit rester une assistante. Utile pour accélérer des tâches simples ou documenter du code, mais elle ne saurait se substituer à la compréhension critique des développeurs et architectes.
CRA, un référentiel partagé et un socle minimum pour tous les éditeurs
Paradoxalement, des cadres de bonnes pratiques existent déjà : SLSA (Supply chain Levels for Software Artifacts), SSDF (Secure Software Development Framework)… pour ne citer qu’eux. Mais aucun n’est contraignant. Résultat : chaque éditeur applique sa propre recette, avec des niveaux de rigueur très variables.
On ajoutera que malheureusement, la Loi de programmation militaire (LPM) ne prévoit rien concernant la traçabilité, la provenance ou la mise à jour des composants logiciels. Elle prévoit simplement que les éditeurs devront déclarer les vulnérabilités qu’ils jugent significatives. La certification ISO 27001 est également un cadre robuste pour intégrer la sécurité au coeur des processus, mais reste optionnelle pour de nombreuses entreprises.
C’est du niveau européen que viendra sans doute l’étincelle avec le Cyber Resilience Act (CRA) qui sera officiellement appliqué dans son intégralité en décembre 2027. Ce cadre juridique complet devrait enfin contraindre les éditeurs à prendre en compte la sécurité tout au long du cycle de vie de la solution. Avec le Cyber Resilience Act, qui imposera une sécurité « by design » sur l’ensemble du cycle de vie logiciel, c’est tout un socle de confiance cyber qui va émerger. Protecteur pour les utilisateurs, rassurant pour les éditeurs et essentiel pour la pérennité de tout l’écosystème numérique.
À LIRE AUSSI :
À LIRE AUSSI :
À LIRE AUSSI :
