Le DevSecOps, et l’AppSec globalement, peut coûter très cher aux entreprises. C’est l’élément central du rapport IDC / JFrog “Les coûts cachés du DevSecOps”. Les équipes, et les développeurs, passent beaucoup de temps sur la sécurité, ce qui se traduit par des plannings rallongés et un coût financier non négligeable. Le rapport estime ce coût à 28 000 $ en moyenne par an et par développeur : 50 % des développeurs seniors, chefs d’équipe, propriétaires de produits et responsables du développement ont connu une augmentation significative du nombre d’heures consacrées chaque semaine aux tâches liées à la sécurité logicielle, les détournant de leur capacité à innover, développer et livrer de nouvelles applications métier. Environ 50 % des répondants à l’enquête consacrent environ 19 % de leur temps hebdomadaire à des tâches liées à la sécurité, parfois en plus du temps de travail. Et malheureusement, ces actions sont encore et toujours en réaction à des problèmes et non en amont. Rappelons que plus tôt une vulnérabilité, un bug, un problème d’architecture est découvert dans le projet, moins la correction coûte en temps et en budget.
“Sécuriser la chaîne d’approvisionnement logicielle pose déjà des défis importants pour les organisations, mais cela devient encore plus complexe lorsque plusieurs outils sont utilisés, forçant les développeurs à basculer entre plusieurs environnements, conduisant à des inefficacités, du temps perdu et un risque accru,” a déclaré Asaf Karas, CTO de JFrog Security. “L’enquête d’IDC crée un argument convaincant pour que les entreprises investissent dans des processus de sécurité rationalisés, des outils et une formation, afin de permettre à leurs développeurs d’être plus efficaces et efficients dans la protection de la chaîne d’approvisionnement logicielle.”
Les principales conclusions du rapport :
-
Chasser les fantômes : Éliminer les faux positifs : Les développeurs passent en moyenne 3,5 heures à examiner manuellement les résultats des analyses de sécurité en raison de faux positifs et de doublons.
-
Le contexte compte : 69 % des développeurs sont d’accord ou tout à fait d’accord que leurs responsabilités liées à la sécurité les obligent à changer fréquemment de contexte entre divers outils, ralentissant l’efficacité. Le changement de contexte entre plusieurs outils peut également augmenter l’utilisation de tokens pour contourner la réauthentification par plateforme. Les tokens peuvent être utiles dans le développement d’applications mais peuvent aussi être rapidement oubliés et laisser des portes dérobées dans les systèmes des entreprises pour des attaques.
-
Les secrets ne sont pas amusants : Les développeurs consacrent 50 % de leur temps à comprendre et interpréter les résultats de l’analyse des secrets, à apporter des modifications au code pour remédier aux résultats et à mettre à jour les mesures de gestion des secrets.
-
Investigation de l’infrastructure : L’Infrastructure-as-Code (IaC) – utilisée pour automatiser la mise en place et la gestion de l’infrastructure IT, telle que les serveurs, le réseau, les systèmes d’exploitation et le stockage – doit être analysée à chaque changement de code, avec plus de 54 % des développeurs déclarant effectuer des analyses IaC hebdomadaires ou mensuelles.
-
Le SAST n’est pas une partie de plaisir : Malgré l’intégration des outils d’analyse statique de la sécurité des applications (SAST) dans les environnements de développement locaux pour fournir des résultats pendant que les développeurs codent, seuls 23 % des développeurs effectuent des analyses SAST avant de déployer le code en production, laissant une énorme faille pour que du code malveillant passe inaperçu.
Bref : le DevSecOps ne s’improvise pas. Il faut des bonnes pratiques, des outils intégrés et une sensibilité des équipes. Une AppSec mal définie dérapera très rapidement et ne sera pas efficace.
