Veracode vient de publier la 11ème édition de son toujours très instructif rapport « State of Software Security » sur la sécurité des logiciels développés par les entreprises. Une édition qui s’attache particulièrement à l’application des principes du « security by design » et au parcours des développeurs dans leur quête d’un développement d’applications mieux sécurisées.

Le rapport de Veracode s’appuie sur l’étude de plus de 130 000 applications actives rencontrées dans les entreprises. Et le résultat n’est guère plus optimiste que les précédentes années : 76% des applications souffrent de défauts de sécurité avec quand même 24% des applications présentant des failles graves et critiques. Le résultat n’est pas brillant, certes, mais il est plus encourageant que l’an dernier qui avait marqué une nette dérive (avec 83% des applications scannées détectées comme vulnérables).

Quelles sont les failles cyber les plus rencontrées ?

Mais au juste de quelles failles parle-t-on ? Veracode s’attache chaque année à créer un palmarès des failles les plus fréquemment rencontrées dans ses analyses applicatives. Un palmarès relativement stable au fil des années. L’année dernière, ce palmarès était dominé par les fuites d’informations, les problèmes cryptographiques, l’injection CRLF et les défauts de qualité de code. Le TOP 3 n’évolue pas cette année même si les problèmes de chiffrement rétrogradent d’une place.
Les problèmes de qualité de code demeurent en quatrième position alors que les outils de développement embarquent de plus en plus d’aides et d’IA pour aider les développeurs en la matière.
Deux grandes failles classiques, pourtant depuis bien longtemps pointées du doigt et plutôt aisées à corriger demeurent dans le TOP 10 : les XSS (Cross-Site Scripting) et les injections SQL !
Au moins les failles « buffer overflow » se font désormais vraiment rares, les compilateurs embarquant désormais des protections contre cet ancien fléau.

Comment les applications sont-elles créées ?

Les analystes de Veracode se sont particulièrement intéressés à la façon dont les applications sont conçues. L’un des problèmes régulièrement évoqués les précédentes années est celui de l’utilisation et la réutilisation à profusion de bibliothèques populaires, généralement open source, qui comme tout code ne sont pas dénuées de vulnérabilités et défauts.
Cette année, Veracode publie un graphique très instructif sur l’usage de telles bibliothèques tierces selon les habitudes des développeurs et leurs langages de prédilection.
Les applications Java sont de très loin celles qui utilisent le plus fort pourcentage de bibliothèques et frameworks tiers. Il en va de même, sans surprise, des applications Python et JavaScript.
S’il n’est pas étonnant de voir à l’opposé du spectre les applications C++ très largement composées de codes « maison », on s’étonnera de voir PHP l’accompagner de façon très similaire sur cette tendance. Seules les applications .NET semblent être assez uniformément dispersées, suggérant que les développeurs .NET ont tendance à être plus flexibles dans la façon dont les bibliothèques sont utilisées.

Des failles en open source

Ce problème des bibliothèques tierces doit alerter les DSI. Un précédent rapport de Veracode rappelait que les entreprises avaient tendance à ne pas mettre à jour ces bibliothèques et à trainer durant plusieurs mois et même plusieurs années des vulnérabilités depuis longtemps corrigées simplement parce qu’elles ne mettaient pas à jour les bibliothèques utilisées. Il est vrai que plus une application utilise de bibliothèques tierces, plus la mise à jour des unes et des autres peut entraîner des différences comportementales dans l’application et générer des bugs difficiles à tracer.
L’an dernier, Veracode indiquait que 7 applications sur 10 disposaient de failles provenant des bibliothèques open source utilisées.

Mais il manquait une information de répartition que dévoile le nouveau rapport : 3 applications sur 10 ont davantage de failles dans leur partie open source que dans leur partie écrite « maison ». Autrement dit, dans près de 70% des applications d’entreprise, Veracode a trouvé plus de bugs de sécurité dans les lignes de code écrites dans l’entreprise que dans les lignes de codes des bibliothèques open source utilisées.

Des corrections qui trainent

L’étude rappelle une donnée connue : 50% des failles corrigées l’ont été dans les 86 jours après leur découverte.
S’intéresser aux bugs corrigés est instructif. Mais beaucoup de failles ne sont en réalité pas corrigées. Or plus une faille est ancienne, moins il y a de chances qu’elle soit corrigée.
L’étude de Veracode montre que 50% des failles sont restées non corrigées pendant au moins 216 jours ! Et si un quart des failles sont effectivement comblées dans les 32 jours qui suivent leur découverte, également un quart des failles restent non résolues pendant plus d’une année et demie.

L’étude Veracode s’intéresse également aux facteurs qui jouent sur la vitesse de correction des failles de sécurité, sur les problématiques de gouvernance des développements, sur les différences repérées entre les régions du globe et livrent quelques conseils pratiques aux DSI. Elle revient bien sûr sur l’importance des scans. Elle rappelle que toutes les failles de sécurité de l’entreprise ne proviennent pas des développeurs, que certaines peuvent être résolues par l’infrastructure (ce qui explique pourquoi elles ne sont pas corrigées au niveau du code) et que le « Security by Design » n’est qu’une facette de la cybersécurité.


Source :
Veracode : The State of Software Security v11