Atténuer la dette technique grâce à une sécurité axée sur les développeurs

Parlons de la dette 

Presque tout le monde sait désormais que la cybercriminalité est devenue un problème majeur pour notre économie mondiale. En 2022, le coût moyen d'une violation de données aux États-Unis s'élevait à 9,44 millions de dollars, contre 9,05 millions l'année précédente. Il est important de ne pas ignorer le coût d'un code non sécurisé et de la dette technique accumulée. Selon le rapport 2022 du Consortium for Information and Software Quality : The Cost of Poor Software Quality, le coût d'une mauvaise qualité logicielle aux États-Unis est estimé à 2 410 milliards de dollars, et la dette technique logicielle accumulée à 1 520 milliards de dollars. 

Les coûts croissants liés à la correction d'un code non sécurisé et à sa dette technique sont devenus le principal obstacle à toute modification des bases de code existantes, les laissant ainsi vulnérables à l'exploitation et aux menaces externes. L'état de la sécurité logicielle fait face à une crise existentielle : nous savons que nous devons améliorer notre posture de sécurité ainsi que traiter la dette technique accumulée, mais les obstacles sont immenses : 

• On estime à 300 000 le nombre d'emplois non pourvus dans le développement logiciel et l'informatique aux États-Unis, avec un taux de croissance projeté de 15 % 
• Il est prévu qu'en 2025, 40 % des budgets informatiques seront consacrés uniquement à la maintenance de la dette technique
• En moyenne, un tiers du temps de travail hebdomadaire des développeurs est consacré à la gestion de la dette technique

Les solutions rapides sont risquées, et coûtent plus cher à long terme 

Qu'est-ce que la dette technique et pourquoi est-ce si important ? La dette technique s'accumule lorsque les décideurs optent pour une solution à court terme à un problème de développement logiciel, plutôt que pour une solution plus exhaustive et durable. Cela s'accompagne d'un coût caché substantiel que les organisations doivent payer plus tard. Tout comme une carte de crédit au plafond, la dette technique comporte deux composantes principales :

• Le principal - fait référence au coût total de la refactorisation ou de la correction du logiciel pour qu'il atteigne le niveau souhaité de maintenabilité et de sécurité.
• Les intérêts - l'effort supplémentaire que les développeurs consacrent à ces changements pour traiter la dette technique, au détriment des nouvelles fonctionnalités. Chaque minute passée sur un code imparfait ajoute des intérêts à la dette.

On peut finir par atteindre un état de « faillite technique » lorsque le coût des nouvelles fonctionnalités, des corrections de bugs et de la maintenance dépasse le budget du projet, ce qui réduit considérablement la valeur de l'application logicielle. 

Cependant, une certaine accumulation de dette, tout comme dans la vie, est normale et, dans la plupart des cas, quelque peu attendue. 

Idéalement, tous les développeurs de logiciels devraient réduire les bugs autant que possible avant de livrer le code. Cependant, ils sont confrontés à un compromis difficile : pour être compétitive, une organisation peut vouloir livrer des fonctionnalités ou des produits aux clients rapidement et à un coût minimal. En conséquence, la qualité de l'application en pâtit car les indicateurs de performance (KPI) des développeurs sont basés sur la rapidité de livraison et le coût initial de construction. Ce qui manque à l'image, ce sont les lacunes accumulées et les vulnérabilités potentielles intégrées dans le code. Cela le rend vulnérable aux bugs ou aux failles de sécurité à l'avenir, ou pire, à une exploitation par des acteurs malveillants. 

Mais là réside le dilemme : existe-t-il un autre moyen de livrer des produits rapidement sans accumuler une dette technique massive ? 

Le coût de la détection et de la correction des lacunes et des vulnérabilités représente la dépense la plus importante du cycle de vie du développement logiciel. Plus les problèmes sont détectés tôt dans le cycle de développement, plus la livraison globale sera rentable. 

La dette technique peut évoluer en dette de sécurité

De nombreux développeurs tentent de contourner ce compromis en utilisant du code open source pour avancer rapidement et, idéalement, utiliser une solution déjà éprouvée. Cependant, s'appuyer fortement sur des logiciels open source présente souvent ses propres risques : 

• 82 % des composants open source se sont révélés obsolètes (c'est-à-dire non corrigés ou mal pris en charge) 
• 75 % des bases de code contenaient des vulnérabilités (contre 60 % en 2018), et 49 % contenaient des vulnérabilités à haut risque 
• Une moyenne de 82 vulnérabilités a été identifiée par base de code 

Cela favorise l'émergence d'une forme particulière de dette technique : la dette de sécurité. Celle-ci correspond à l'accumulation de vulnérabilités dans une application logicielle, rendant la protection des données et des systèmes contre les attaques plus complexe, voire impossible.

L'un des exemples les plus tristement célèbres est celui d'Equifax, le géant de l'évaluation du crédit, victime d'une violation de données en 2017 pour avoir omis de corriger une vulnérabilité connue dans Apache Struts, un framework d'application web open source très répandu. Bien que le correctif fût disponible depuis des mois, cette faille a compromis les données personnelles cruciales de plus de 147 millions de personnes.

Il est donc impératif d'accorder une attention accrue aux pratiques de développement sécurisé, car de nombreuses applications ont atteint un seuil critique, non seulement en termes de dette technique, mais aussi de densité de faiblesses et de vulnérabilités au sein même de leur code.

Cela peut entraîner des pertes considérables, qu'elles soient tangibles ou intangibles :

Atteinte à la réputation : La perte de confiance des clients peut avoir des conséquences extrêmement négatives à long terme. Cela inclut une dégradation de l'image de marque, une baisse des ventes et des frais juridiques coûteux consécutifs à une violation.

Impact réglementaire et conformité : Une faille de sécurité peut empêcher une entreprise de respecter ses délais ou ses obligations contractuelles. Le non-respect d'un SLA peut exposer l'entreprise à des sanctions des autorités de régulation, se traduisant par des amendes importantes.

Coûts de remédiation : Des efforts supplémentaires sont souvent nécessaires après une défaillance ou une interruption de service pour compenser la perte de productivité.

Prévenir la dette technique et de sécurité dans le cycle de vie du développement logiciel (SDLC)

De nombreuses organisations réorientent déjà leur budget pour renforcer leur posture de sécurité. L'an dernier, Google a engagé 10 milliards de dollars sur 5 ans pour financer un programme de renforcement de la cybersécurité. L'administration Biden a également sollicité 2,1 milliards de dollars dans le budget discrétionnaire 2022 pour la Cybersecurity and Infrastructure Security Agency (CISA).

Allouer davantage de ressources et de formations pour favoriser le développement professionnel et les compétences de vos développeurs constitue une première étape essentielle pour établir des normes de qualité pour tout code mis en production.

Le coût de détection et de correction d'une vulnérabilité ou d'un défaut augmente de façon exponentielle plus il est identifié tardivement dans le cycle de développement. Comme nous l'avons vu, le temps consacré à la gestion de la dette technique et de sécurité détourne les organisations de l'innovation et du développement de nouvelles fonctionnalités.

En 2022, la majorité des équipes de développement ont privilégié le DevOps ou le DevSecOps, et ce n'est pas un hasard. Le DevSecOps intègre la sécurité à chaque étape du cycle de vie logiciel pour livrer des applications plus performantes et sécurisées. Bien que les équipes de sécurité et de développement travaillent encore souvent en silos, il est clair que cette dynamique doit évoluer pour assurer la réussite des entreprises. Le DevOps participe à cette volonté de briser les barrières et de transformer la culture d'entreprise. L'objectif fondamental du DevSecOps est d'accroître la collaboration entre les équipes de sécurité et les développeurs dès le début du cycle de vie.

Adopter une nouvelle approche de la dette technique et de la sécurité n'a rien d'insurmontable. Développer un état d'esprit proactif par la formation est crucial pour améliorer la sensibilisation et les compétences de la communauté des développeurs. Une formation solide au codage sécurisé, garantissant un apprentissage continu, interactif et contextuel, est indispensable. Une approche holistique doit viser à instaurer une véritable culture de sécurité portée par les développeurs, ce qui peut nécessiter de repenser les méthodes traditionnelles de gestion et de structuration des équipes.

Transformer la culture d'une entreprise est un défi, mais Secure Code Warrior vous aide à identifier vos champions de la sécurité et à doter vos développeurs et vos équipes des compétences nécessaires pour relever les défis de sécurité actuels.

Lancer un programme de code sécurisé engageant et évolutif est un investissement judicieux, car il privilégie une approche préventive à long terme plutôt que la réaction traditionnelle. Cela permet d'atténuer les risques coûteux liés aux failles, d'aider les développeurs à corriger rapidement les vulnérabilités et de favoriser une agilité accrue dans le développement de produits et la mise sur le marché.