Peut mieux faire. C'est l'appréciation qui vient en tête en parcourant les résultats d'une étude sur la sécurité des applications développées par les entreprises, publiée par Checkmarx, éditeur spécialisé dans la sécurité applicative. Trois populations différentes ont été interrogées pour cette enquête : développeurs, responsables de la sécurité applicative et RSSI. Et les résultats sont préoccupants. En effet, 86% des développeurs et responsables de la sécurité applicative interrogés admettent que du code vulnérable a été déployé en connaissance de cause au cours de l'année passée, et pour près d'un quart (23%), cela s'est même produit souvent. Pour 40% de ces professionnels, ce choix a été fait afin de tenir des délais et respecter des échéances. Mais ce pari risqué s'est bien souvent révélé perdant : en 2022, 88% des entreprises interrogées ont connu au moins une violation de données liée à une application développée en interne, car celle-ci comportait des vulnérabilités.
Les raisons derrière ces chiffres très élevés sont malheureusement connues. Ainsi, 35% des développeurs interrogés subissent une pression accrue pour livrer plus rapidement applications et mises à jour. Face à cela, la crainte que la sécurité ralentisse la livraison des applications peut inciter à faire des compromis potentiellement périlleux. Et souvent, cette crainte s'avère fondée : 66% des développeurs interrogés estiment que les solutions qui scannent le code pour déceler des problèmes de sécurité sont peu, mal, voire pas du tout intégrées à leurs autres outils quotidiens : environnements de développement, gestionnaires de code et autres maillons de la chaîne CI/CD. Et 41% des responsables de la sécurité applicative pointent la mauvaise adoption des outils d'AppSec par les développeurs comme un frein majeur. Malgré cela, six vulnérabilités sur dix sont détectées lors des phases de développement, de build ou de test, un chiffre qui montre l'intérêt de mettre en place des contrôles à différents niveaux de la chaîne, et le plus en amont possible. Fluidifier l'intégration de la sécurité dans les processus de développement s'avère donc être un levier important pour passer du DevOps au DevSecOps.
Des politiques de sécurité applicative portées par plusieurs acteurs
Un autre sujet d'attention porte sur les politiques de sécurité applicative. Près d'un tiers des RSSI interrogés admettent que les règles de sécurité établies ne sont pas toujours appliquées dans leur organisation. Mais l'étude a également interrogé les répondants pour savoir qui établissait ces politiques (avec plusieurs réponses possibles), et les réponses révèlent une certaine dilution des responsabilités en la matière : ainsi, 56% des RSSI indiquent que cela fait partie de leurs prérogatives, mais 41% d'entre eux indiquent que les développeurs sont impliqués, 38% que l'équipe chargée de la sécurité applicative l'est également, 38% encore ajoutent le département de gestion des risques et de la conformité et dans 37% des cas, l'équipe dirigeante elle-même rentre dans le jeu. Dans la plupart des entreprises, cette responsabilité semble donc partagée entre différents acteurs, une situation qui ne favorise pas forcément la mise en oeuvre de règles claires et communes à tous. Dans ce contexte, 72% des répondants RSSI travaillent activement pour s'assurer que les règles en place sont suivies.
L'étude met également en évidence des différences de perception entre les trois populations interrogées. Parmi les causes fréquemment impliquées dans les violations, les responsables de la sécurité applicative pointent en premier lieu les attaques par supply chain qui exploitent du code open source (41%), suivies par le vol d'identifiants, de secrets ou des procédures d'authentification faibles (40%) et la présence (connue ou non) de vulnérabilités dans le code déployé en production (39%). Du côté des développeurs, ceux-ci placent en tête le recours au cloud, à l'infrastructure-as-code et les mauvaises configurations de conteneurs (40%). Vient ensuite la présence de vulnérabilités, connues ou non dans leurs applications (38%) et, enfin, l'usage de composants ou packages tiers contenant du code malveillant (38%). Enfin, du côté des RSSI, les risques prioritaires sont liés à l'usage accru des API (37%), à la supply chain (37%) et à la conteneurisation des applications (37% également). L'utilisation de bibliothèques open source et l'infrastructure-as-code génèrent également leur lot de risques, cités par 36% des RSSI interrogés.
Formation insuffisante des développeurs
Enfin, des efforts peuvent également être engagés sur la formation des développeurs à la sécurité applicative. Seuls 47% des développeurs interrogés reçoivent ainsi des formations régulières sur le sujet, et 36% seulement jugent celles-ci efficaces. Du côté des RSSI, le constat est encore plus sévère, puisque 22% seulement considèrent que leurs développeurs maîtrisent parfaitement les bonnes pratiques de sécurité applicative. Mais 37% des RSSI estiment également que les développeurs manquent de temps et de ressources pour sécuriser leur code, et 36% reconnaissent que les développeurs n'ont pas eu de formation adaptée sur le sujet. De son côté, Checkmarx pointe les cinq erreurs les plus récurrentes dans le code analysé par sa plateforme : contrôles d'accès défaillants, problèmes autour du chiffrement, injections de code, architectures non sécurisées et enfin dysfonctionnements sur le monitoring et les logs de sécurité.