L’avènement des technologies Low Code-No Code ne garantit pas la sécurité des applications : le code généré par ces plateformes présente autant de vulnérabilités que le code écrit manuellement. L’intégration de la sécurité à toutes les étapes du cycle de vie du développement logiciel est essentielle pour anticiper, détecter et corriger les failles de sécurité.

L’accélération provoquée par l’irruption spectaculaire de l’IA dans les processus est en train de bouleverser bien des départements, notamment ceux de la production de code. L’avènement du Low Code-No Code promet de transformer la manière dont les applications sont créées, déployées et gérées. Ces technologies visent à simplifier le processus de développement logiciel, permettant à des personnes sans compétences techniques de concevoir et de développer des applications. Mais, au-delà de la prise en charge de ces tâches par des non spécialistes et l’accélération des livraisons d’applications, ces technologies sont porteuses de leurs propres inconvénients.

La prolifération des outils d’aide à la création de code s’accompagne d’un risque accru de code non sécurisé à grande échelle, ce qui peut se transformer en une « dette de sécurité » importante pour les organisations. Des études récentes révèlent des chiffres inquiétants. D’après les chiffres d’OpenAI, plus d’un tiers des réponses incorrectes de ChatGPT ne sont pas identifiées par les programmeurs, même expérimentés (OpenAI, 2023). Selon le rapport « State of Software Security 2023 », publié par Veracode, le code développé par l’IA contient autant de failles de sécurité que le code écrit par les humains.  

Toute faille qui n’est pas corrigée au bout d’un an est une dette de sécurité

C’est dans ce contexte que Veracode a exploré ses 18 années de données pour répondre aux questions relatives à l’accumulation des risques liés au code non sécurisé dans son rapport « State of Software Security » de 2024. La dette de sécurité est définie dans l’étude comme étant « toute faille qui demeure non corrigée pendant plus d’un an ». Cette dette de sécurité peut concerner diverses applications au sein des organisations et peut être classée en fonction de sa gravité. Par exemple, les failles critiques de sécurité sont des défauts graves qui persistent sans correction pendant plus d’un an. Ainsi, la dette de sécurité est un phénomène répandu au sein des organisations et demande une gestion proactive pour réduire les risques associés.

D’après Veracode, une grande majorité d’organisations (71 %) ont un certain niveau de dette de sécurité, avec près de la moitié de toutes les entreprises (46 %) ayant des failles persistantes de grande sévérité, classées comme dette de sécurité critique. Cela indique que la dette de sécurité est un défi important au niveau de l’organisation. Parmi les organisations ayant une dette de sécurité, l’entreprise type a une dette de sécurité dans un tiers de ses applications actives, avec plus de deux tiers des applications affectées dans un quart des organisations.  

Au moins une dette de sécurité dans au moins 90 % des applications

En outre, plus d’une entreprise sur dix a une dette de sécurité dans au moins 90 % de ses applications. Avec près de la moitié de toutes les failles (47 %) considérées comme une dette de sécurité, le ratio de la dette de sécurité critique tend à se situer dans un pourcentage à un chiffre pour la plupart des organisations, ce qui indique des niveaux variables de réussite dans la gestion de la dette critique.

Parmi les facteurs contribuant à la dette de sécurité, le rapport met en évidence différentes dynamiques qui conduisent à l’accumulation de la dette de sécurité dans les applications et les organisations. L’un des facteurs clés mis en évidence est l’âge de l’application. Les données suggèrent qu’au fur et à mesure que les applications vieillissent, la proportion de failles qualifiées de dettes de sécurité augmente de manière significative. Par exemple, environ 42 % de toutes les failles se transforment en dettes de sécurité après un an, pour atteindre environ 62 % après trois ans et 75 % après cinq ans.  

Intégrer la sécurité en combinant les tests

Cela souligne l’impact de l’âge de l’application sur l’accumulation de la dette de sécurité au fil du temps. Le rapport aborde également les facteurs endogènes, en soulignant que la gestion de la dette de sécurité relève en fin de compte de la responsabilité de l’organisation. Le rapport révèle par ailleurs une disparité de sept fois entre les organisations ayant les ratios les plus élevés et les plus bas de dette de sécurité critique, les grandes entreprises technologiques affichant des niveaux d’endettement plus élevés que les petites entreprises du commerce de détail et de l’hôtellerie.

Le rapport note que les organisations de taille moyenne et de grande taille ont généralement une dette de sécurité plus importante que les petites entreprises, ce qui reflète les défis associés au maintien de la sécurité dans des bases de code plus importantes, au fur et à mesure que les organisations se développent. Il fournit aussi des conseils et des stratégies basées sur des preuves pour les organisations afin de réduire la dette de sécurité. Le rapport souligne l’importance d’intégrer la sécurité tout au long du cycle de vie du développement logiciel (SDLC) pour améliorer la sécurité des logiciels.

Il suggère que l’intégration de la sécurité dans l’ensemble du cycle de développement logiciel est le premier pas pour une gestion efficace de la dette de sécurité. En combinant les résultats des tests statiques de sécurité des applications (SAST), des tests dynamiques de sécurité des applications (DAST) et de l’analyse de la composition des logiciels (SCA), les entreprises peuvent créer une approche globale de la sécurité.