Augmenter le budget sécurité après un incident cyber est un réflexe de moins en moins répandu. Les conseils d’administration adaptent leurs stratégies de gestion des risques… ou voient les attaques comme une conséquence inévitable de leur présence sur le marché.
Une idée reçue veut que les organisations investissent davantage dans la cybersécurité après une violation de données. La dernière étude annuelle d’IBM sur le coût d’un incident de ce type, fait état d’une baisse significative du nombre d’organisations mondiales déclarant prévoir d’investir dans la sécurité après une attaque : 49% en 2025, contre 63% en 2024.Les experts interrogés sont partagés quant à savoir si cette baisse est inconsidérée ou reflète une prise de conscience de l’inefficacité des dépenses réactives.« Historiquement, les investissements liés aux violations ont servi de signal d’alarme pour les conseils d’administration, mais les dernières données montrent une certaine lassitude, déclare Amiram Shachar, PDG de l’entreprise de sécurité cloud Upwind. Les dépenses réactives ne sont ni efficaces ni durables. »« Un coût inévitable associé à l’activité »Il ajoute que « les programmes de sécurité proactifs déployés en continu et qui évoluent à mesure que les applications migrent dans le cloud, de la protection de la couche de configuration à la protection des applications au niveau de la couche d’exécution, améliorent graduellement la couverture et réduisent le risque de violation. Ils ont un impact bien plus important ». Aaron Perkins, fondateur de Market-Proven AI, affirme que les entreprises se rendent compte qu’une fois un certain seuil atteint, les dépenses supplémentaires en cybersécurité ne se traduisent pas nécessairement par une réduction proportionnelle des risques.« Les organisations victimes de violations de données passent d’une gestion réactive de leurs dépenses à une gestion calculée des risques, privilégiant l’optimisation des investissements existants plutôt que la simple multiplication des couches de sécurité, explique Aaron Perkins. Cela témoigne d’une maturité organisationnelle qui dépasse la logique de la sécurité à tout prix et privilégie une prise de décision plus élaborée, axée sur le retour sur investissement ». Zach Lewis, DSI et RSSI à l’Université des sciences de la santé et de la pharmacie de Saint-Louis (États-Unis), n’est pas surpris par les chiffres d’IBM, car les violations de données ne suscitent plus le même sentiment d’urgence qu’auparavant. « Trop d’entreprises les considèrent comme un coût inévitable de leur activité et passent à autre chose, explique-t-il. « Le problème, c’est que les attaquants deviennent plus intelligents et plus rapides, et si vous ne mettez pas à jour vos défenses, notamment avec des outils capables de les suivre, vous laissez la porte grande ouverte à la prochaine attaque. » De plus, compte tenu de l’importance accordée à la cybersécurité par les conseils d’administration ces dernières années, le déblocage d’une enveloppe post-violation les met sur la sellette. « Augmenter les dépenses de sécurité après une violation oblige les dirigeants à reconnaître qu’ils ont sous-investi au départ », souligne Jason Rebholz, en charge du conseil aux RSSI chez Expel, fournisseur de solutions managées de détection et de réponse aux incidents.Transfert de risquesDe plus en plus de responsables en cybersécurité choisissent de transférer les risques plutôt que de les atténuer grâce à la cyberassurance, une décision métier qui peut modifier les réponses à toute faille de sécurité. « La baisse des dépenses post-intrusion suggère une divergence d’opinions : certaines entreprises s’appuient sur la cyberassurance pour absorber l’impact, tandis que d’autres ont déjà renforcé leur résilience grâce à des cadres comme le CSF [Cyber Security Framework] du NIST [National Institute of Standards and Technology, agence dépendant du ministère du Commerce des États-Unis]. Dans ces cas, les failles de sécurité permettent de tirer des leçons et d’effectuer des ajustements plutôt que de nouveaux investissements », explique Elliott Franklin, RSSI de la société de réassurance Fortitude Re.Todd Thorsen, RSSI chez CrashPlan, fournisseur de solutions de récupération de données, souligne que certaines victimes de failles de sécurité peuvent conclure qu’elles sont davantage exposées du fait de la complexité de leur environnement informatique qu’en raison d’investissements cyber insuffisants. « La complexité peut être un problème aussi important que le sous-investissement en sécurité : systèmes redondants, intégrations mal gérées, logiciels obsolètes, etc., explique-t-il. Cela peut inciter certaines organisations à simplifier leurs environnements après une faille de sécurité et à se concentrer sur les bons outils, l’optimisation et la consolidation. »Des processus défaillantsMark Wojtasiak, vice-président de la recherche et de la stratégie produits chez le fournisseur de solutions de sécurité Vectra AI, affirme que la baisse des intentions d’investissement après une violation suggère un changement de mentalité plus large parmi les professionnels du sujet : « de nombreux responsables de la sécurité considèrent désormais les violations moins comme un signal d’investissement, que comme un indicateur de processus défaillants, de lacunes de gouvernance ou de capacités sous-utilisées. « Par conséquent, plutôt que de rechercher de nouveaux budgets, les organisations se concentrent sur l’amélioration de leur utilisation des technologies et des partenariats existants. »D’autres experts se montrent beaucoup moins optimistes. AJ Thompson, directeur commercial au sein de la société de conseil IT Northdoor et membre du conseil consultatif mondial de sécurité d’IBM, y voit une évolution inquiétante. « Le fait qu’une organisation ait été victime d’une violation signifie qu’il existe déjà une vulnérabilité exploitable ; ne pas y remédier en renforçant la sécurité est imprudent », estime-t-il.Pas de ruée vers l’IASelon une autre conclusion clé du rapport d’IBM, moins de la moitié des entreprises qui prévoient d’investir après une faille de sécurité se concentreront sur des solutions ou services de sécurité basés sur l’IA. « Ce faible intérêt pour les solutions basées sur l’IA est surprenant, compte tenu de la manière dont l’IA et l’IA générative remodèlent le paysage de la menace, estime Amiram Shachar d’Upwind. Les organisations ont besoin d’outils capables de sécuriser les applications d’IA contre des risques tels que les fuites de données, les manipulations malveillantes et les accès non autorisés aux modèles, des failles que les défenses traditionnelles ne peuvent combler. »Elliott Franklin, le RSSI de Fortitude Re, ajoute : « l’IA a un rôle à jouer, mais elle ne résoudra pas les défaillances des processus. Le renforcement de la gouvernance et l’automatisation des fondamentaux restent la voie la plus judicieuse. »
Augmenter le budget sécurité après un incident cyber est un réflexe de moins en moins répandu. Les conseils d’administration adaptent leurs stratégies de gestion des risques… ou voient les attaques comme une conséquence inévitable de leur présence sur le marché.
Une idée reçue veut que les organisations investissent davantage dans la cybersécurité après une violation de données. La dernière étude annuelle d’IBM sur le coût d’un incident de ce type, fait état d’une baisse significative du nombre d’organisations mondiales déclarant prévoir d’investir dans la sécurité après une attaque : 49% en 2025, contre 63% en 2024.Les experts interrogés sont partagés quant à savoir si cette baisse est inconsidérée ou reflète une prise de conscience de l’inefficacité des dépenses réactives.« Historiquement, les investissements liés aux violations ont servi de signal d’alarme pour les conseils d’administration, mais les dernières données montrent une certaine lassitude, déclare Amiram Shachar, PDG de l’entreprise de sécurité cloud Upwind. Les dépenses réactives ne sont ni efficaces ni durables. »« Un coût inévitable associé à l’activité »Il ajoute que « les programmes de sécurité proactifs déployés en continu et qui évoluent à mesure que les applications migrent dans le cloud, de la protection de la couche de configuration à la protection des applications au niveau de la couche d’exécution, améliorent graduellement la couverture et réduisent le risque de violation. Ils ont un impact bien plus important ». Aaron Perkins, fondateur de Market-Proven AI, affirme que les entreprises se rendent compte qu’une fois un certain seuil atteint, les dépenses supplémentaires en cybersécurité ne se traduisent pas nécessairement par une réduction proportionnelle des risques.« Les organisations victimes de violations de données passent d’une gestion réactive de leurs dépenses à une gestion calculée des risques, privilégiant l’optimisation des investissements existants plutôt que la simple multiplication des couches de sécurité, explique Aaron Perkins. Cela témoigne d’une maturité organisationnelle qui dépasse la logique de la sécurité à tout prix et privilégie une prise de décision plus élaborée, axée sur le retour sur investissement ». Zach Lewis, DSI et RSSI à l’Université des sciences de la santé et de la pharmacie de Saint-Louis (États-Unis), n’est pas surpris par les chiffres d’IBM, car les violations de données ne suscitent plus le même sentiment d’urgence qu’auparavant. « Trop d’entreprises les considèrent comme un coût inévitable de leur activité et passent à autre chose, explique-t-il. « Le problème, c’est que les attaquants deviennent plus intelligents et plus rapides, et si vous ne mettez pas à jour vos défenses, notamment avec des outils capables de les suivre, vous laissez la porte grande ouverte à la prochaine attaque. » De plus, compte tenu de l’importance accordée à la cybersécurité par les conseils d’administration ces dernières années, le déblocage d’une enveloppe post-violation les met sur la sellette. « Augmenter les dépenses de sécurité après une violation oblige les dirigeants à reconnaître qu’ils ont sous-investi au départ », souligne Jason Rebholz, en charge du conseil aux RSSI chez Expel, fournisseur de solutions managées de détection et de réponse aux incidents.Transfert de risquesDe plus en plus de responsables en cybersécurité choisissent de transférer les risques plutôt que de les atténuer grâce à la cyberassurance, une décision métier qui peut modifier les réponses à toute faille de sécurité. « La baisse des dépenses post-intrusion suggère une divergence d’opinions : certaines entreprises s’appuient sur la cyberassurance pour absorber l’impact, tandis que d’autres ont déjà renforcé leur résilience grâce à des cadres comme le CSF [Cyber Security Framework] du NIST [National Institute of Standards and Technology, agence dépendant du ministère du Commerce des États-Unis]. Dans ces cas, les failles de sécurité permettent de tirer des leçons et d’effectuer des ajustements plutôt que de nouveaux investissements », explique Elliott Franklin, RSSI de la société de réassurance Fortitude Re.Todd Thorsen, RSSI chez CrashPlan, fournisseur de solutions de récupération de données, souligne que certaines victimes de failles de sécurité peuvent conclure qu’elles sont davantage exposées du fait de la complexité de leur environnement informatique qu’en raison d’investissements cyber insuffisants. « La complexité peut être un problème aussi important que le sous-investissement en sécurité : systèmes redondants, intégrations mal gérées, logiciels obsolètes, etc., explique-t-il. Cela peut inciter certaines organisations à simplifier leurs environnements après une faille de sécurité et à se concentrer sur les bons outils, l’optimisation et la consolidation. »Des processus défaillantsMark Wojtasiak, vice-président de la recherche et de la stratégie produits chez le fournisseur de solutions de sécurité Vectra AI, affirme que la baisse des intentions d’investissement après une violation suggère un changement de mentalité plus large parmi les professionnels du sujet : « de nombreux responsables de la sécurité considèrent désormais les violations moins comme un signal d’investissement, que comme un indicateur de processus défaillants, de lacunes de gouvernance ou de capacités sous-utilisées. « Par conséquent, plutôt que de rechercher de nouveaux budgets, les organisations se concentrent sur l’amélioration de leur utilisation des technologies et des partenariats existants. »D’autres experts se montrent beaucoup moins optimistes. AJ Thompson, directeur commercial au sein de la société de conseil IT Northdoor et membre du conseil consultatif mondial de sécurité d’IBM, y voit une évolution inquiétante. « Le fait qu’une organisation ait été victime d’une violation signifie qu’il existe déjà une vulnérabilité exploitable ; ne pas y remédier en renforçant la sécurité est imprudent », estime-t-il.Pas de ruée vers l’IASelon une autre conclusion clé du rapport d’IBM, moins de la moitié des entreprises qui prévoient d’investir après une faille de sécurité se concentreront sur des solutions ou services de sécurité basés sur l’IA. « Ce faible intérêt pour les solutions basées sur l’IA est surprenant, compte tenu de la manière dont l’IA et l’IA générative remodèlent le paysage de la menace, estime Amiram Shachar d’Upwind. Les organisations ont besoin d’outils capables de sécuriser les applications d’IA contre des risques tels que les fuites de données, les manipulations malveillantes et les accès non autorisés aux modèles, des failles que les défenses traditionnelles ne peuvent combler. »Elliott Franklin, le RSSI de Fortitude Re, ajoute : « l’IA a un rôle à jouer, mais elle ne résoudra pas les défaillances des processus. Le renforcement de la gouvernance et l’automatisation des fondamentaux restent la voie la plus judicieuse. »
Une étude montre que 69 % des RSSI ont été sommés par leur employeur de garder le silence sur les incidents cybersécurité affectant leur entreprise. Soit 27 points de plus qu’il y a deux ans. Malgré un environnement réglementaire qui, lui, réclame un signalement toujours plus rapide des attaques.
Les RSSI sont soumis à une pression croissante pour garder le silence sur les incidents de sécurité que connait leur organisation, car les préoccupations liées à la réputation de celle-ci priment souvent sur le respect de la conformité réglementaire. Selon une récente enquête de l’éditeur Bitdefender, plus des deux tiers (69 %) des RSSI ont été sommés de maintenir la confidentialité sur ces incidents. Ces chiffres sont en nette hausse : il y a deux ans, seuls 42 % des RSSI disaient avoir à faire face à ce type d’injonction.Martin Zugec, directeur des solutions techniques chez Bitdefender, explique que l’évolution des méthodes des cybercriminels pourrait avoir une influence directe sur la chape de plomb entourant certaines violations de données. « Les attaques traditionnelles par rançongiciel, qui chiffraient les données et imposaient leur divulgation publique, sont en baisse, souligne-t-il. Les attaquants se concentrent de plus en plus sur le vol de données sans interruption de service, rendant les violations moins visibles aux yeux des clients ou du public.»Même lorsque le chiffrement est utilisé, il est souvent limité à l’infrastructure back-end. Par exemple, une attaque récente du groupe RedCurl a spécifiquement ciblé les hyperviseurs, évitant les systèmes susceptibles d’impacter les utilisateurs finaux. « Cette approche minimise les retombées publiques et ouvre la voie à des négociations de gré à gré, ce qui accroît la pression exercée sur les RSSI en matière de divulgation », dit Martin Zugec.Malgré la pression réglementaireOr, les RSSI ont également une pression réglementaire, notamment issue des règles de protection des données, telles que le RGPD, et des réglementations des marchés financiers, qui exige, elle, la divulgation rapide des incidents cyber. D’autres réglementations, telles que la législation européenne sur la cybersécurité et la résilience (Cyber Security and Resilience Act), DORA et NIS2, renforcent cette surveillance réglementaire.Les RSSI sont contraints de minimiser ou d’éviter de signaler les problèmes de conformité, malgré le risque de responsabilité personnelle qu’ils encourent en cas de non-signalement des incidents de sécurité. Bryan Marlatt, directeur régional du cabinet de conseil en cybersécurité CyXcel et ancien RSSI, expliqué avoir quitté son ancien employeur après qu’on lui ait demandé de minimiser un incident de sécurité. « Chez cet employeur, le DSI m’avait demandé de ne pas partager les risques avec le comité d’audit et de sur-valoriser les capacités de sécurité sur le formulaire 10K de la SEC (le gendarme des bourses aux Etats-Unis, NDLR), raconte Bryan Marlatt. Cela fait suite à l’ordre que j’ai reçu de ne pas divulguer les détails d’une compromission de messagerie professionnelle survenue récemment. » L’ancien RSSI précise « le DSI était à un an avant de la retraite et ne voulait pas faire de vagues, comme il le prétendait.»« L’intégrité est plus importante pour moi que n’importe quelle somme d’argent. C’est pourquoi, lorsqu’on m’a demandé de ne pas divulguer les détails d’un incident et d’enjoliver les mérites des dispositifs de sécurité, j’ai démissionné », tranche Bryan Marlatt.« Intense pression » pour garder le silenceDeux autres anciens RSSI ont fait état de pressions afin qu’ils gardent le silence sur des suspicions d’incidents de sécurité. Tous deux ont souhaité garder l’anonymat en raison d’accords de confidentialité de fin de contrat conclus avec leurs précédents employeurs. « Lorsque je travaillais dans une entreprise européenne du Fortune Global 500, j’ai été témoin de ce phénomène à plusieurs reprises, explique l’un d’eux. La pression était particulièrement intense avant les assemblées générales des actionnaires ou la publication des rapports financiers trimestriels. »Le même indique : « chaque incident devait d’abord être transmis au DSI, qui le signalait à son équipe de direction ou au conseil d’administration – généralement au directeur financier – indépendamment de l’urgence ou des délais réglementaires. La justification était toujours la même : “Il ne s’agit pas nécessairement d’un incident de cybersécurité.” La décision finale de divulgation était systématiquement prise sans intervention du RSSI. »Cet ancien RSSI donne quelques exemples qu’il a personnellement rencontrés :- Vol de données dans le développement automobile : environ 500 Go de données techniques et personnelles sensibles ont été volés par un initié, puis vendus sur le dark web. Cause première : mauvaise configuration de la gestion des identités et des accès (IAM). Non divulguée, car il s’agissait « de données volées, et non d’un piratage ».- Abus de droits de super-administrateur par un responsable de la sécurité : un cadre supérieur dans la cyber a abusé de ses droits d’administrateur pour intimider ses subordonnés et accéder aux comptes de membres du conseil d’administration et d’autres personnes clefs de l’entreprise. Le centre des opérations de sécurité l’a détecté. Il a été qualifié de « mauvaise configuration » et non de cyberattaque.- Piratage d’une entité à l’étranger : des pirates ont détourné environ 50 millions d’euros de paiements de fournisseurs SAP via une faille de sécurité, bien aidés par l’absence d’authentification multifacteur. Non divulgué, car cela « ne tombait pas sous le coup des lois de l’UE ».- Identifiants administrateur volés : CrowdStrike a signalé un compte super-administrateur toujours actif. Les logs étaient manquants. Les Red Team et Blue Team ont recommandé la réinitialisation de l’IAM. Un conseil ignoré, car « aucun préjudice direct n’a été détecté ».- Scandale de corruption impliquant le RSSI : un fournisseur du Big Five a soudoyé le RSSI du groupe au niveau global et deux de ses subordonnés directs en leur accordant des vacances et d’autres avantages coûteux pour obtenir des contrats internationaux. Les preuves ont été ignorées. Le RSSI a été discrètement remplacé, non sans une importante indemnité de départ, et l’équipe a été priée de ne pas en parler.Un deuxième ancien RSSI nous a fait part d’un incident au cours duquel son employeur a été informé d’une suspicion de violation de données impliquant des informations privées : des adresses e-mail et des noms. Après avoir déterminé que la source du problème ne provenait pas de son organisation, mais du développeur d’un site web tiers, le RSSI s’est vu demander de ne pas signaler le problème, même si des données clients étaient concernées, car ce n’était « pas son problème » et l’entreprise souhaitait préserver sa relation commerciale avec le site web tiers.Pris au piègeCes situations illustrent la position inconfortable dans laquelle se trouvent souvent les RSSI : légalement responsables de la sécurité, mais contraints de faire fi des normes lorsque la divulgation des incidents entre des conflits avec les intérêts de leur organisation. « L’entreprise ne comprend pas vraiment ce que cela implique pour les personnes qui se soucient vraiment du sujet », explique notre première source, ajoutant que, face à des situations de ce type, elle a obtempéré aux demandes de silence. « Il n’existe aucune véritable protection, financière ou réputationnelle, pour les lanceurs d’alerte, qu’il s’agisse d’un RSSI ou de tout autre responsable de la sécurité qui dénoncerait une situation de cette nature », constate notre source.Témoigner peut mettre fin à une carrière« Dans mon cas, je suis sûr d’avoir été signalé, reprend notre source. Lors d’un entretien d’évaluation, on m’a expliqué que si je voulais atteindre le sommet de l’organisation, je devais me conformer davantage aux exigences de l’entreprise et moins à celles de mon équipe. Cette conversation a été l’une des principales raisons de mon départ. »Bryan Marlatt de CyXcel ajoute que les dirigeants d’entreprise tentent souvent de dissimuler la survenue d’un incident, même s’il est susceptible d’avoir un impact sur leurs clients ou partenaires commerciaux. « En tant que consultant, j’ai entendu parler de nombreux RSSI à qui l’on demandait de ne pas divulguer les détails d’un incident, ou de ne pas révéler qu’il s’était produit, indique-t-il. Avec la multiplication des rançongiciels et la nécessité de faire appel à des prestataires externes pour l’investigation numérique, la réponse aux incidents ou la déclaration de sinistres, il devient beaucoup plus difficile de dissimuler des incidents importants. »Le silence n’est pas d’orCaroline Morgan, associée chez CM Law, reconnait que, au sein des entreprises, la pression pour garder le silence est réelle, tout en avertissant que les régulateurs non seulement attendent, mais exigent la divulgation des incidents de sécurité. « Juridiquement, en gardant le silence, une entreprise ne fait probablement qu’aggraver ses problèmes, au lieu de les éviter, dit-elle. Le prix à payer peut être dévastateur, car il ne s’agit plus seulement de violation, mais aussi de dissimulation. »« Les régulateurs peuvent utiliser cette propension à garder le silence pour démontrer une tendance à la non-conformité et imposer des sanctions importantes, avertit la juriste. L’atteinte à l’image de marque, la perte de confiance des clients et, pire encore, des poursuites judiciaires peuvent également en résulter. »Et Caroline Morgan poursuit : « si un responsable de la sécurité informatique ou un autre responsable tente de dissimuler des incidents et est découvert, cela signifie souvent la fin de sa carrière et un risque de poursuites personnelles, une amende des régulateurs ou, pire encore, des poursuites pénales. » Ce risque est loin d’être théorique. Joe Sullivan, ancien directeur de la sécurité d’Uber, a été reconnu coupable d’avoir dissimulé une faille de sécurité en 2016 et condamné à une peine de probation.Un cadre préétabli pour la réponse aux incidentsCar le signalement rapide des incidents est le fondement des lois sur la protection des données. « Les entreprises peuvent réduire considérablement leur exposition [aux risques] en reconnaissant que la pression interne exercée pour ne pas signaler les incidents constitue une menace et en mettant en place des solutions pour la minimiser avant qu’une faille ne se produise, conseille Caroline Morgan. Et elles peuvent minimiser la pression interne en s’assurant de disposer d’un plan de réponse aux incidents solide, dont le cadre favorise la transparence, incluant des formations sur la gestion éthique des incidents et un pouvoir décisionnel séparé des fonctions commerciales ».
En 2024, les pirates ont multiplié les attaques et les exploits de failles dans les binaires de logiciels et applications du marché y compris celles d’intelligence artificielle. Les attaques contre la supply chain logicielle sont devenues particulièrement sophistiquées.
La multiplicité des failles dans les logiciels open source et les logiciels commerciaux tiers, ainsi que les campagnes malveillantes ciblant les pipelines de développement de l’IA, exacerbent les problèmes de sécurité de la supply chain logicielle. Selon ReversingLabs (RL), les incidents liés à l’exposition de secrets intégrés à des développements via de composants open source librement accessibles ont augmenté de 12 % l’année dernière par rapport à 2023.Une analyse de 30 logiciels libres parmi les plus populaires laisse apparaître une moyenne de six failles de gravité critique et de 33 failles de gravité élevée… pour chacun d’entre eux. Les progiciels propriétaires sont également une source fréquente de risques, selon d’autres conclusions du rapport de ReversingLabs sur la sécurité de la supply chain logicielle.Les risques liés à celle-ci sont devenus de plus en plus fréquents et complexes, car les environnements informatiques modernes reposent largement sur des fournisseurs et des composants open source. Le problème a pris de l’ampleur après le piratage de SolarWinds en 2020, qui a touché plus de 30 000 organisations, y compris des agences gouvernementales américaines.De nombreux incidents résultant d’attaques contre la supply chain logicielle – qu’elle que soit la forme qu’elle prenne – se sont produits depuis le piratage historique de SolarWinds Orion, attribué à une unité du Service de renseignement extérieur de Russie.Sous le microscopeL’analyse par RL de plus de deux douzaines de binaires de logiciels propriétaires largement utilisés – y compris des OS, des gestionnaires de mots de passe, des navigateurs web et des logiciels de réseaux privés virtuels (VPN) – montre la persistance de toute une série de problèmes tels que des secrets exposés, la présence de vulnérabilités logicielles activement exploitées, des preuves d’altération possible du code et un durcissement inadéquat des applications.Mais, selon RL, ce sont les modules open source et les référentiels de code qui représentent toujours la grande majorité des risques liés à la chaîne d’approvisionnement en 2024. L’analyse de packages populaires comme npm, PyPI et RubyGems montre que de nombreux modules open source largement utilisés contiennent des composants anciens et obsolètes – un phénomène connu sous le nom de « code rot » (pourriture de code). Par exemple, de npm, module comptant près de 3 000 téléchargements hebdomadaires et 16 applications dépendantes, a permis d’identifier 164 vulnérabilités de code distinctes, dont 43 de gravité « critique » et 81 de gravité « élevée ». La même analyse identifie sept vulnérabilités logicielles connues pour avoir été activement exploitées par des acteurs de la menace.L’IA : nouvelle frontière pour les attaques par la supply chainL’étude révèle également que les campagnes ciblant la supply chain logicielle visent désormais l’infrastructure de développement et le code utilisé par les développeurs d’applications de Machine Learning et d’IA. Par exemple, les chercheurs de RL ont découvert une technique malveillante baptisée « nullifAI », au sein de laquelle un code malveillant est placé dans les fichiers de sérialisation Pickle de Python. Cette technique a échappé aux protections intégrées dans la plateforme open source Hugging Face – un ensemble de ressources populaire pour les développeurs d’IA et de ML.« Les chaînes d’approvisionnement en IA sont une cible de plus en plus importante, les attaquants manipulant les données, les modèles d’entraînement et les bibliothèques logicielles », souligne Michael Adjei, directeur de l’ingénierie des systèmes chez l’éditeur de solutions de micro-segmentation Illumio. « De nombreuses organisations s’appuient sur des services tiers pour les modèles pré-entraînés et les outils basés sur le cloud, mais des ressources non sécurisées peuvent introduire des portes dérobées et des vulnérabilités. » Selon lui, « pour protéger la supply chain de l’IA, les couches cachées secrètes des modèles devraient être exposées à des tests de pénétration et à des entraînements contradictoires (adversarial training, consistant à réentraîner un modèle sur des examples permettant d’en dégrader la fiabilité, NDLR). »Peter Garraghan, CEO de Mindgard, fournisseur de tests de sécurité pour l’IA et professeur à l’université britannique de Lancaster, reconnaît que les menaces pesant sur la supply chain constituent une préoccupation émergente pour les développeurs d’IA. « Les composants d’IA – par exemple, LLM, RAG – sont intégrés dans la chaîne d’approvisionnement en logiciels, ce qui en fait une nouvelle frontière pour les attaques sophistiquées », dit-il. « Comme le souligne l’OWASP (voir LLM 03:2025), les LLM s’intègrent fréquemment à des API externes et à des sources de données, ce qui introduit des risques importants en raison de ces dépendances. »Et encourager les pratiques de codage sécurisé ne suffit pas « Les RSSI doivent adopter une posture de sécurité proactive qui inclut des tests continus des applications d’IA, une transparence sur la structure des logiciels et la détection automatisée des menaces tout au long du cycle de vie du développement de l’IA », conseille Peter Garraghan.Code généré par l’IA : un faux sentiment de sécuritéLes chaînes d’approvisionnement en logiciels s’appuient fortement sur des codes open source, émanant de tiers et/ou générés par l’IA, ce qui introduit des risques échappant au contrôle des équipes de développement. De meilleurs contrôles sur les logiciels que l’industrie construit et déploie sont nécessaires, selon ReversingLabs.« Les outils AppSec traditionnels passent à côté de menaces telles que l’injection de malwares, la modification malveillante de dépendances et les failles cryptographiques », indique Saša Zdjelar, Chief trust officer de ReversingLabs. « La véritable sécurité exige une analyse approfondie des logiciels, une évaluation automatisée des risques et une vérification continue tout au long du cycle de développement. »Les développeurs et les équipes chargées de la sécurité des applications doivent avoir accès à des outils leur permettant de s’assurer que leurs composants fondamentaux sont exempts de vulnérabilités connues ou, pire encore, de malwares cachés ou de manipulations diverses.L’introduction de codes générés par l’IA ne résout pas ce problème. On a observé que les logiciels générés par l’IA reprenaient des codes présentant des vulnérabilités connues, remettaient au goût du jour des algorithmes de chiffrement obsolètes ou contenaient des composants open source périmés.ReversingLabs affirme qu’il est nécessaire de mettre en place une nouvelle génération de solutions pour la supply chain logicielle, conçues pour identifier les malwares et les manipulations, ainsi que les changements de comportement d’une application entre deux versions successives.Extension de la nomenclature logicielleReversingLabs et des experts indépendants estiment encore qu’il est temps d’adopter et d’étendre le concept de nomenclature des logiciels (SBOM, pour software bill of materials). Un SBOM fournit un inventaire complet des dépendances logicielles – des données qui aident les organisations à atténuer les risques de sécurité et à répondre rapidement aux vulnérabilités dans les bibliothèques et autres composants.« Actuellement, le SBOM est simplement une liste d’ingrédients et, peut-être, de vulnérabilités existantes, dit Saša Zdjelar de ReversingLabs. Les récents ajouts visant à prendre en compte une nomenclature étendue – aux composants de machine learning, cryptographiques et SaaS – constituent un grand pas dans la bonne direction. »Darren Meyer, du fournisseur de tests de sécurité des applications d’entreprise Checkmarx, souligne que les entreprises devaient développer des programmes complets basés sur les risques afin de maîtriser les menaces pesant sur leur supply chain logicielle. « Pour rester au fait des codes tiers vulnérables et malveillants, il faut disposer d’une chaîne d’outils complète, notamment de fonctions d’analyse de la composition des logiciels (SCA) pour identifier les vulnérabilités connues dans les composants logiciels tiers, d’une analyse des conteneurs pour détecter les failles dans les paquets issus de tiers au sein des conteneurs, et de renseignements sur la menace centrés sur les paquets malveillants afin de repérer les composants compromis », énumère Darren Meyer.David Spillane, directeur de l’ingénierie des systèmes chez le fournisseur de cybersécurité Fortinet, fait valoir que les RSSI ont un rôle clé à jouer dans l’atténuation des risques potentiels liés à la sécurité de la supply chain : « outre les pratiques de développement sécurisé, les RSSI et les équipes informatiques au sens large peuvent prendre plusieurs mesures pour atténuer les attaques contre la supply chain logicielle des entreprises, à commencer par l’audit de l’infrastructure existante, afin d’identifier les vulnérabilités dont les cybercriminels pourraient tirer parti. Il est essentiel de disposer d’un inventaire actualisé des actifs logiciels pour réduire les vecteurs d’attaque potentiels en classant les solutions en fonction de leur degré de sécurité. »
Les dettes de sécurité non résolues exposent les entreprises à un risque accru de cyberattaque ; Le tout alors que les délais de correction s’allongent et que les écosystèmes applicatifs se complexifient.
Les entreprises mettent de plus en plus de temps à corriger les failles de sécurité de leurs logiciels. Conséquence : la dette de sécurité qui en découle devient de plus en plus critique. Selon le dernier rapport State of Software Security de l’éditeur de logiciels Veracode, le délai moyen de correction des failles de sécurité est en effet passé de 171 à 252 jours au cours des cinq dernières années.Par ailleurs, selon cette même étude, 50% des organisations ont aujourd’hui une dette de sécurité qualifiée “à haut risque”, soit une accumulation de failles laissées ouvertes pendant plus d’un an. La majorité de celles-ci proviennent de codes issus de tiers et de la supply chain logicielle, source récurrente de risques majeurs malgré l’attention grandissante qui lui est portée.Bien que le chiffre de 50% d’entreprises exposées à une dette à haut risque n’augmente que marginalement par rapport aux 46% enregistrés lors de l’édition 2024 de l’étude annuelle de Veracode, le résultat demeure préoccupant, car la tendance est mauvaise. Chris Wysopal, cofondateur et évangéliste en chef de la sécurité chez Veracode, souligne notamment un des aspects de la sécurité applicative qui s’est régulièrement dégradé au fil des ans : le temps nécessaire pour corriger les failles. « Il y a de nombreuses raisons à cela, mais la portée et la complexité sans cesse croissantes de l’écosystème logiciel en constituent une cause majeure, dit-il. Les organisations ont davantage d’applications et beaucoup plus de code à maîtriser, et cela ne fera qu’augmenter à mesure que de plus en plus d’équipes adoptent l’IA pour la génération de code. ». Sans même parler du fait que la génération de code avec l’IA pourrait en elle-même renforcer les problématiques de sécurité ou en créer de nouvelles, que cette pratique provienne de l’interne ou de tierces parties dont l’entreprise est dépendante.Appliquer des stratégies de réduction des risquesL’étude de Veracode révèle des différences marquées dans la façon dont les organisations gèrent cette dette de sécurité, avec des écarts importants entre les meilleurs et les moins performants. Selon l’éditeur, cinq mesures clés permettent d’évaluer la maturité de la sécurité et d’améliorer la capacité d’une organisation à réduire systématiquement ses risques :Prévalence des failles : les organisations les plus performantes ont des failles dans moins de 43% des applications, taux qui grimpe à 86% au sein des organisations les moins performantes.Capacité de correction : les leaders résolvent plus de 10% des failles par mois, tandis que les retardataires en corrigent moins de 1%.Vitesse de correction : les entreprises les plus performantes corrigent la moitié des failles en cinq semaines ; les moins performantes mettent plus d’un an à le faire.Prévalence de la dette de sécurité : moins de 17% des applications des organisations les plus avancées ont une dette de sécurité, contre plus de 67% parmi les retardataires.Dette en matière de logiciels libres : les organisations les plus performantes maintiennent la dette critique liée aux logiciels libres à moins de 15%, alors que 100% de la dette critique est liée aux logiciels libres dans les organisations les moins avancées.« La plupart des entreprises souffrent d’une visibilité fragmentée sur les failles logicielles et les risques au sein de leurs applications, avec des ensembles d’outils dispersés qui créent un sentiment de fatigue lié à la profusion d’alertes en même temps que des silos de données qu’il faut interpréter avant de prendre des décisions », souligne Chris Wysopal. Selon lui, un des leviers majeurs pour combler le retard en matière de sécurité réside dans la capacité à prioriser la remédiation des failles en fonction du risque qu’elles présentent.L’étude de Veracode est basée sur des résultats issus d’environ 1,3 million d’applications soumises à une combinaison d’analyse statique, d’analyse dynamique, d’analyse de la composition du logiciel et/ou de tests de pénétration manuels par le biais de la plateforme cloud de l’éditeur. Les logiciels mis à l’épreuve provenaient d’entreprises de toutes tailles, et étaient issus d’éditeurs, d’outsourceurs et de projets Open Source.Risques liés à la supply chain logicielleEn ce qui concerne la dette de sécurité liée aux logiciels libres, la société Black Duck, spécialisée dans la sécurité des applications, indique qu’une analyse de 965 bases de code dans 16 secteurs d’activité a révélé que 86% d’entre elles contenaient des vulnérabilités provenant des logiciels libres et que 81% d’entre elles présentaient des vulnérabilités à risque élevé ou critique.Huit des dix principales vulnérabilités à haut risque couvertes par le rapport Open Source Security and Risk Analysis de Black Duck ont été trouvées dans jQuery, une bibliothèque JavaScript largement utilisée. La faille à haut risque la plus fréquemment identifiée est CVE-2020-11023, une vulnérabilité XSS affectant les versions obsolètes de jQuery, mais toujours présente dans un tiers des bases de code analysées.Les risques issus des vulnérabilités provenant de codes d’éditeurs et de projets Open Source peuvent être atténués en analysant continuellement le code tout au long du cycle de vie du développement du logiciel, conseille Veracode. « L’analyse de la composition des applications (SCA pour Software composition analysis) permet d’atteindre cet objectif en détectant et en gérant les risques liés aux composants logiciels tiers et Open Source par le biais d’un processus automatisé, précise Chris Wysopal. Elle génère des nomenclatures logicielles (SBOM, pour Software bills of materials), recherche les vulnérabilités, évalue les risques et fournit des conseils de remédiation. »Mettre en place un programme de réduction de la detteSelon Veracode, en s’attaquant à la dette de sécurité et en s’appuyant sur les meilleures pratiques, les entreprises peuvent améliorer leur résilience, réduire les risques et se conformer à l’évolution réglementaire en matière de cybersécurité. Le spécialiste de la sécurité des applications propose une liste de facteurs permettant d’élaborer une stratégie efficace de réduction de cette dette :Tests automatisés : intégrer SAST (analyse statique de la sécurité du code), DAST (analyse dynamique), SCA (composition des applications) et d’autres frameworks de tests automatisés dans la chaîne CI/CD pour détecter les failles de façon précoce.Politiques fondées sur le risque : se concentrer sur les failles facilement exploitables et d’une certaine gravité, et appliquer des politiques strictes de non-passage en production.Développeurs responsabilisés : former, désigner des champions en matière de sécurité et considérer les tâches de sécurité comme un travail normal de développeur.Culture de la responsabilité : suivre les vulnérabilités en même temps que les bogues fonctionnels et les corriger au fur et à mesure de leur apparition.Surveillance des logiciels libres : maintenir un inventaire clair des bibliothèques open source exploitées, les mettre à jour régulièrement et automatiser les vérifications.Discipline : si les ressources sont utiles, une stratégie cohérente et des processus solides sont plus importants. Même les petites équipes, si elles sont bien alignées et disciplinées, obtiennent souvent de meilleurs résultats que des équipes pléthoriques moins focalisées sur le sujet.john le