Comment répondre aux frustrations les plus courantes liées à la sécurité
Les frustrations en matière de sécurité sont souvent perçues comme un problème de culture d'organisation et occultent le rôle essentiel des infrastructures technologiques.
Les dirigeants doivent s’attaquer à des enjeux plus concrets, comme la complexité des environnements techniques et la gestion des vulnérabilités. Ces derniers ne constituent pas uniquement des défis culturels, mais aussi des freins systémiques à l’évolution des systèmes de sécurité des organisations.
Une enquête réalisée en 2024 par GitLab auprès des professionnels du DevSecOps a pointé plusieurs freins culturels entravant une meilleure coordination entre les équipes d’ingénierie et de sécurité. Une majorité des répondants évoluant dans le domaine de la sécurité (58 %) déclarent rencontrer des difficultés dans leurs équipes lorsqu’il s'agit du traitement prioritaire des vulnérabilités identifiées. De plus, 52 % indiquent que les tâches administratives ralentissent leurs efforts pour corriger rapidement les failles. En effet, les répondants ont également signalé plusieurs frustrations spécifiques à leur travail : interpréter les résultats des analyses de sécurité, le nombre excessif de faux positifs, ou encore des tests de sécurité qui interviennent trop tard dans le processus de développement logiciel. Ces constats révèlent un problème organisationnel plus profond, qui ne relève pas uniquement de la culture d’entreprise, mais aussi des processus et de la technologie.
L’approche DevSecOps promet une meilleure intégration entre ingénierie et sécurité mais il est clair que les tensions persistent. Et pour cause : ces défis sont souvent les symptômes d’un problème plus profond, lié à la manière dont les organisations perçoivent la sécurité, collaborent en interne et allouent leurs ressources à ces enjeux.
Rompre avec le cycle infernal des vulnérabilités
Les outils d’analyse de vulnérabilités détectent l’ensemble des failles potentielles, cependant le fait qu’un composant logiciel présente une vulnérabilité ou une exposition commune (CVE) ne signifie pas forcément qu’elle est exploitable ou accessible. Depuis que les analyses authentifiées sont devenues la norme, les équipes de sécurité et de développement passent un temps considérable à trier un volume de rapports de vulnérabilités toujours plus croissant, et ce phénomène ne cesse de croître depuis la généralisation de ces analyses. Par ailleurs, l’analyse authentifiée a renforcé l’efficacité des dispositifs de sécurité, mais elle a aussi enfermé les équipes de développement dans un cycle sans fin de corrections inutiles. Consacrer du temps à appliquer des correctifs à des failles inoffensives revient à négliger les vulnérabilités réellement critiques, ce qui alimente les tensions actuelles entre équipes de sécurité et d’ingénierie.
Alors, comment les organisations peuvent-elles s’attaquer à la racine de ces problèmes et favoriser une meilleure intégration entre l'ingénierie et la sécurité ? Voici trois leviers pour réduire les frustrations courantes en matière de sécurité.
1. Réduire le bruit, se concentrer sur les signaux exploitables
Les faux positifs arrivent en deuxième position des plus grandes frustrations mentionnées par les répondants de l’enquête. Ils constituent clairement un défi, mais sont souvent révélateurs d’un défaut dans la gestion des vulnérabilités.
Si une organisation observe un grand nombre de faux positifs, cela peut indiquer qu’elle n’a pas mis en place toutes les mesures nécessaires pour garantir la fiabilité de ses résultats et qu’elle doit diriger ses efforts vers ce qui compte réellement. Les solutions traditionnelles de test statique de sécurité des applications (SAST) sont donc probablement insuffisantes. Bien que puissant, le SAST perd une grande partie de sa valeur lorsque ses résultats sont difficilement exploitables ou dénués de contexte pertinent. Pour être réellement efficace, le SAST doit s’intégrer de manière fluide aux autres outils de sécurité et de développement, tout en restant accessible aux équipes de développement
Autre limite : la plupart des outils d’analyse disposent d’une fenêtre de contexte très restreinte pour comprendre les résultats des analyses de vulnérabilités. Un domaine dans lequel l’intelligence artificielle peut aider, grâce à des fonctionnalités alimentées par l’IA qui permettent d’expliquer plus clairement les vulnérabilités.
2. Alléger la pile technologique pour réduire la surface d’attaque
Rester concentré sur l’essentiel ne s’applique pas uniquement aux tests de sécurité, mais commence dès la conception des logiciels.
Bien que l’IA promette de simplifier les processus de développement logiciel, l’enquête montre que de nombreuses organisations ont encore un long chemin à parcourir. Un paradoxe qui suggère que la multiplication des solutions spécialisées fonctionnant chacune avec leur propre modèle d’IA pourrait être un facteur de complexité supplémentaire, plutôt qu’un levier de simplification.
Cette complexité croissante des piles technologiques est un facteur majeur de frustration en matière de sécurité. Une certaine sophistication est inévitable lorsqu’on développe des systèmes logiciels vastes et multifonctionnels. Cependant, les organisations devraient prendre des mesures pour éviter la complexité issue de décisions de conception sous-optimales, comme un code difficile à maintenir ou des dépendances redondantes. Elle élargit inutilement la surface d’attaque et génère davantage de résultats d’analyse de sécurité que les équipes doivent trier, hiérarchiser et traiter.
Les organisations devraient adopter une approche du développement centrée sur la minimisation logicielle, c’est-à-dire faire des choix réfléchis sur les outils utilisés et sur ce qui est intégré dans leurs bases de code. Cela permettra de mieux maîtriser les dépendances, d’améliorer la sécurité de la chaîne d’approvisionnement logicielle, de réduire le bruits des scanners ainsi que la charge de travail des équipes de développement.
3. Standardiser les pratiques efficaces
Le fait que les tests de sécurité arrivent trop tard dans le cycle de développement logiciel fait partie des principales sources de frustration identifiées par les répondants. Les équipes peuvent être en difficulté lorsque la livraison est bloquée à cause d’une vulnérabilité détectée trop tard, mais dans de nombreux cas, il n’aurait pas été possible de la détecter plus tôt. Par contre, il est envisageable de rendre la sécurité modulaire, réutilisable et automatisable.
Les équipes peuvent éviter les mauvaises surprises en fin de parcours en adoptant des modèles de conception éprouvés et validés, basés sur des cas d’usage reproductibles : c’est ce qu’on appelle l’approche des « routes balisées ». Il s’agit d’une recommandation d’outils, de processus et de composants soigneusement sélectionnés, que les équipes peuvent utiliser pour développer des applications sécurisées plus efficacement, en utilisant par exemple GitOps pour concevoir une infrastructure bien architecturée, testée, et déployable à grande échelle pour toutes les charges de travail.
Adopter cette approche peut réduire la flexibilité, mais cela diminue la charge opérationnelle et les reprises pour les équipes d’ingénierie, tout en renforçant la sécurité. Cela doit être un effort collaboratif entre les équipes de sécurité et de développement. La sécurité peut contribuer à concevoir ces procédures structurées, mais l’ingénierie doit être impliquée pour les faire fonctionner et les maintenir dans le code.
La sécurité est une responsabilité collective
On observe déjà que la sécurité, en tant que pratique, est en train de s’intégrer aux équipes d’ingénierie, et il est probable que les frontières entre les deux continuent de s’estomper du fait de l’adoption rapide de l’IA et de l’accélération qui en découle dans le développement logiciel. En effet, 66 % des répondants affirment livrer des logiciels deux fois plus vite, voire davantage, qu’en 2023.
C’est pourquoi l’idée du fossé culturel entre le développement et la sécurité ne suffit pas à expliquer les tensions identifiées. Favoriser une culture de la collaboration est indispensable, mais les équipes de sécurité et d’ingénierie doivent également travailler main dans la main pour repenser certains aspects fondamentaux du développement logiciel — comme l’optimisation des bases de code existantes et la création de solutions évolutives, centrées sur l’ingénierie, qui puissent être adoptées sans friction par les équipes techniques à l’échelle de l’organisation. Ce n’est qu’à cette condition que la sécurité pourra suivre le rythme effréné du développement logiciel moderne.