Comme dans le domaine de l’IT, les questions de dette touchent le sujet de la cybersécurité en entreprise. Veracode met en lumière ce sujet moins connu et qui recense les failles non corrigées depuis un an encore présentes dans le parc applicatif. L'étude est basée sur les données recueillies par l’éditeur lors de récents tests de sécurité des applications statiques (Static Application Security Testing, SAST), tests de sécurité des applications dynamiques (Dynamic Application Security Testing, DAST) et l’analyse de composition logicielle (Software component analysis, SCA) de plus d'un million d'applications.
« La prolifération du code généré par l'IA s'accompagne d'un code non sécurisé à grande échelle et de la probabilité qu'il devienne une dette de sécurité », a déclaré Chris Eng, directeur de la recherche chez Veracode. « Compte tenu de l'ampleur de la dette de sécurité que nous avons constatée, il convient de se demander si les outils de remédiation assistés par l'IA peuvent être utiles pour réduire cette dette, sans avoir à réorienter les équipes de développement ou à en augmenter la taille ». L'étude a également révélé un nombre considérable de failles dans les codes de première main et de tierce partie, soulignant l'importance de les tester tous les deux tout au long du cycle de vie du développement logiciel.
Les failles critiques en baisse, mais pas éliminées
L'étude a révélé qu’en 2023, la prévalence des failles de grande gravité avait chuté (dans 17,9 % des applications) à la moitié de son niveau de 2016 (dans 37,9 % des applications). Et si, 3,2 % seulement de toutes les failles ont été jugées très graves (score CVSS supérieur ou égal à 9), près de 16 % de ces brèches étaient « fortement susceptibles » d'être exploitées. Cela signifie qu'un peu moins de 1 % (0,7 %) de toutes les vulnérabilités détectées en 2023 étaient à la fois critiques et hautement exploitables. Globalement, d’après les analyses SAST, DAST et SCA de Veracode, 80 % de toutes les applications actives présentent des failles non résolues, alors que ce chiffre était de 73 % pour les analyses SAST uniquement, qui prennent en compte les problèmes spécifiques à la phase de développement des applications. Les failles détectées dans les composants tiers et open-source étaient comparables à celles détectées dans les codes de première main. En fait, 63,4 % des applications présentaient des failles dans les codes d’origine, tandis que 70,2 % des applications présentaient des failles dans les codes de tierce partie.
Selon l'étude, cette situation est liée à l'adoption plus large de l'IA et nécessite une analyse approfondie des deux sources dans le cycle de développement. En outre, l’étude a mis en évidence le fait qu'en moyenne, une application typique comporte 42 failles pour 1 Mo de code. Les scripts intersites XSS, les injections, les traversées de répertoire et les composants vulnérables et obsolètes sont les principales failles dans les applications à forte intensité (moyenne des résultats par application) et à fort volume (pourcentage d'applications).
Des recommandations pour réduire la dette technique
La dette de sécurité logicielle concerne 42% de toutes les applications. Ce chiffre tombe à 23 % si l'on ajoute les applications de moins d'un an, ce qui signifie que 57 % des applications présentent des failles, mais n'ont pas de dette. La situation est un peu différente si l'on prend en compte l’héritage de sécurité critique (failles critiques non corrigées). « Une grande majorité des entreprises (71 %) ont peu ou prou une dette de sécurité », selon l'étude. « Près de la moitié des entreprises (46 %) présentent des failles persistantes de grande gravité que l’on peut classer dans la catégorie des dettes de sécurité critiques.
En moyenne, près de la moitié de toutes les failles (47 %) d'une entreprise peuvent être attribuées à la dette de sécurité. Pour faire face à celle-ci, l'étude formule quelques recommandations, notamment l'intégration de la sécurité dans la gestion du cycle de développement, la remédiation continue avec une priorisation sur les dettes de sécurité critiques, le renforcement des compétences des développeurs en matière de sécurité et la connaissance du profil de la dette pour le langage de programmation concerné.