Cette année, l'enquête annuelle menée par GitLab auprès des professionnels DevSecOps révèle plusieurs obstacles liés à la culture d'entreprise qui pourraient entraver l'alignement entre les équipes d'ingénierie et de sécurité. Une majorité (58 %) des professionnels de la sécurité interrogés déclarent qu'il leur est difficile de faire en sorte que le développement priorise la correction des vulnérabilités. Par ailleurs, 52 % estiment que leurs efforts pour résoudre rapidement ces failles de sécurité sont souvent ralentis par la bureaucratie interne. Parmi les frustrations liées à leur travail, ils citent notamment la difficulté à interpréter les résultats des analyses de sécurité, le nombre trop élevé de faux positifs et le fait que les tests sont effectués trop tardivement dans le cycle de développement logiciel.
Bien que l'approche DevSecOps promette une meilleure intégration entre l'ingénierie et la sécurité, ces frustrations et déséquilibres montrent que des défis subsistent. Ce constat reflète un problème plus large lié à la manière dont les entreprises perçoivent la sécurité, organisent la collaboration entre les équipes, et allouent du temps à cette priorité.
Améliorer la gestion du nombre toujours plus grand de vulnérabilités
L'analyse des vulnérabilités met en évidence toutes les vulnérabilités potentielles. Cependant, la présence d'une vulnérabilité ou d'une exposition commune (CVE) dans un logiciel ne signifie pas nécessairement que celle-ci est accessible ou exploitable. Les équipes de sécurité et les développeurs doivent donc hiérarchiser et filtrer les résultats des rapports d'analyse, dont le nombre a augmenté de manière exponentielle au fil des ans avec l'adoption de l'analyse de vulnérabilité avec authentification.
Si ce processus a renforcé l'efficacité des programmes de sécurité à bien des égards, il conduit toutefois les développeur à corriger sans arrêt des failles sans importance réelle. Lorsque les équipes perdent du temps à appliquer des correctifs qui ne résolvent pas une vulnérabilité exploitable, elles ne consacrent pas suffisamment de temps aux tâches plus critiques, telles que l'application de correctifs à des failles véritablement vulnérables et exploitables. Cette situation contribue largement à la divergence actuelle entre les priorités des équipes de sécurité et celles de l'ingénierie.
La question est donc de savoir comment les entreprises peuvent s'attaquer aux cause profondes de ces problèmes pour favoriser une meilleure intégration entre les équipes d'ingénierie et de sécurité. Voici trois approches pour éviter les frustrations les plus courantes en matière de sécurité, en ciblant directement la source du problème.
1. Réduire les faux positifs et se concentrer sur des signaux pertinents, fiables et exploitables
Le nombre excessif de faux positifs constitue la deuxième source de frustration majeure pour les professionnels de sécurité, selon notre enquête. Bien qu’ils représentent un problème réel, ils révèlent souvent une gestion inefficace des vulnérabilités.
Si une entreprise détecte de nombreux faux positifs, cela peut indiquer qu'elle n'a pas mis en place les mesures adéquates pour assurer la pertinence et la fiabilité de ses découvertes en matière de failles de sécurité. Pour améliorer l’efficacité, les entreprises doivent cibler leurs efforts de sécurité sur les vulnérabilités les plus critiques. Les solutions classiques de test statique de sécurité des applications (SAST) sont insuffisantes. Elles restent essentielles, mais elles perdent de leur utilité si leurs résultats sont mal contextualisés ou difficiles à gérer. Pour optimiser l'impact des tests SAST, il est crucial de les intégrer de manière fluide avec les autres outils de sécurité et de développement, et de les rendre accessibles aux développeurs.
La plupart des outils d'analyse offrent une visibilité limitée, rendant plus difficile la compréhension des résultats. C'est dans ce domaine que les fonctionnalités alimentées par l'IA peuvent s'avérer utiles pour expliquer les failles de sécurité.
2. Réduire la complexité de la pile technologique et la surface d'attaque
Se concentrer sur l'essentiel ne s'applique pas seulement aux tests de sécurité, mais en premier lieu à la façon dont les entreprises développent leurs logiciels.
Bien que l'IA promette de simplifier les processus de développement logiciel, notre enquête montre que de nombreuses entreprises ont encore un long chemin à parcourir. Les répondants utilisant l’IA étaient d’ailleurs plus enclins à vouloir consolider leurs outils que ceux qui ne l’utilisent pas, ce qui suggère que l’ajout de solutions ponctuelles intégrant divers modèles d’IA pourrait accroître la complexité au lieu de la réduire.
Cette complexité technologique contribue largement aux frustrations liées à la sécurité. Développer des systèmes logiciels complexes et multifonctionnels entraîne nécessairement un certain niveau de complexité. Cependant, les entreprises doivent prendre des mesures pour éviter la complexité qui résulte de décisions de conception loin d'être optimales, comme des dépendances redondantes ou un code difficile à maintenir. Une telle complexité accroît la surface d'attaque, augmente le nombre de résultats d'analyse de vulnérabilités à gérer, et alourdit les priorités des équipes de sécurité.
Pour limiter cette surcharge, il est essentiel de réduire le nombre d’outils et de logiciels utilisés, en intégrant uniquement ceux qui sont réellement nécessaires dans les codes bases. Cela permet de diminuer les dépendances inutiles, de renforcer la sécurité de la chaîne d’approvisionnement logicielle, de réduire les faux positifs générés par les scanners de vulnérabilités et d’alléger la charge de travail des développeurs en leur épargnant les résolutions de problèmes non critiques.
3. Normaliser les procédures
La réalisation de tests de sécurité trop tard dans le cycle de vie du développement logiciel était également l'une des principales sources de frustration identifiées par les répondants à notre enquête. Les équipes peuvent se sentir frustrées lorsque la livraison de code est retardée à cause d'une vulnérabilité détectée tardivement. Mais très souvent, il n'était pas possible de détecter cette vulnérabilité plus tôt. Il est toutefois possible de mettre en place des composants de sécurité facilement déployables et réutilisables. Cela permet de limiter les variables et les vulnérabilités potentielles.
En adoptant une approche « guidée » fondée sur des design patterns testés et approuvés basés sur des cas d'utilisation reproductibles, les équipes peuvent anticiper les risques. Cette méthode balisée est recommandée. Elle repose sur un ensemble d'outils, de processus et de composants bien structurés qui aide les équipes à créer des applications sécurisées plus efficacement. L'utilisation de GitOps pour la gestion des versions et le déploiement d’une infrastructure en tant que code, avec une architecture bien pensée et testée, capable de se déployer à grande échelle pour tous les types de charges de travail en est un exemple parfait.
Bien que l'adoption d'une procédure balisée risque de supprimer une certaine flexibilité, elle réduit finalement la charge opérationnelle et le nombre de retouches des équipes d'ingénierie, tout en renforçant la sécurité. La collaboration entre les équipes de sécurité et de développement est essentielle pour atteindre cet objectif. Les équipes de sécurité peuvent participer à la création de procédures structurées, tandis que les équipes d’ingénierie doivent contribuer à leur intégration et à leur mise à jour au sein du code base.
La sécurité, une pratique multidisciplinaire
La sécurité évolue vers une pratique multidisciplinaire qui rapproche de plus en plus les équipes d'ingénierie et celles chargées de la sécurité. Avec l'adoption rapide de l'IA pour accélérer le développement logiciel (66 % des répondants à notre enquête publient désormais des logiciels deux fois plus rapidement que l'année précédente), les entreprises doivent impérativement mettre en place des systèmes et des frameworks qui optimisent la sécurité. Cela démontre la forte interconnexion entre développement et sécurité. Pour cela, il est essentiel de promouvoir une culture de collaboration. Les équipes de sécurité et d'ingénierie doivent travailler main dans la main pour repenser les bases du développement logiciel. Cela inclut l'optimisation des codes bases existants et la création de solutions évolutives orientées ingénierie, que les équipes techniques de l’entreprise peuvent adopter facilement.
La sécurité des applications à l'ère du numérique
Lisez les conclusions de notre enquête menée auprès de plus de 5 000 professionnels DevSecOps dans le monde entier afin de comprendre pourquoi les entreprises sont confrontées à l'augmentation des surfaces d'attaque et à l'évolution des comportements à l'égard de la sécurité et de l'IA.