Comment les développeurs définissent-ils le « codage sécurisé » ?

Une version de cet article a été publiée dans TechRepublic. Il a été mis à jour et syndiqué ici.

‍

Créer un environnement où les objectifs de l'équipe de sécurité et ceux des développeurs sont alignés a été un combat difficile, mais essentiel. Nous avons encore un long chemin à parcourir, mais les obstacles qui entravent la synergie nécessaire pour instaurer une responsabilité partagée en matière de sécurité logicielle deviennent évidents. Les entreprises intelligentes souhaitent faire évoluer leur stratégie pour éviter ces pièges, trouver une voie productive et exploiter tout le potentiel humain du DevSecOps.

Ce à quoi je ne m'attendais pas, c'est que la perception de ce qui constitue le codage sécurisé fasse l'objet de débats. Selon une toute nouvelle étude menée en collaboration avec Evans Data, ce sentiment a été clairement mis en évidence. L'enquête State of Developer-Driven Security 2022 analyse les idées clés et les expériences de 1 200 développeurs actifs, mettant en lumière leurs attitudes et les défis auxquels ils sont confrontés dans le domaine de la sécurité.

L'une des conclusions principales est que seuls 14 % des développeurs considèrent la sécurité comme une priorité lors du codage. Bien que cela montre une marge de progression énorme, cela confirme ce que nous savions déjà : la création de fonctionnalités est reine dans le monde des développeurs, et ils restent mal équipés pour intégrer la sécurité dans leur ADN. Cependant, lorsqu'on associe cela aux données sur la façon dont les développeurs définissent le codage sécurisé, il y a de quoi s'inquiéter.

Ces perceptions sont dictées par l'expérience quotidienne des développeurs et témoignent de l'environnement de nombreuses organisations, où les développeurs ne sont tout simplement pas au centre de la lutte contre les vulnérabilités courantes. Leur autonomisation est cruciale, mais en attendant, nous devons rapidement nous accorder sur la portée du « codage sécurisé » et sur ce que nous devrions attendre d'un développeur compétent en sécurité.

Nous devons démystifier la sécurité dans le monde des développeurs.

La cybersécurité est une bête complexe et difficile à maîtriser, et bien que le codage sécurisé ne représente qu'une partie du paysage global, c'est un rouage complexe du système qui nécessite une attention spécialisée.

L'enquête a révélé que le concept de travail avec du code sécurisé était assez cloisonné pour le développeur moyen, sa portée étant souvent limitée à une seule catégorie plutôt qu'à une vision holistique des fondamentaux et au-delà. Les développeurs ont indiqué qu'ils s'appuyaient sur l'utilisation de code existant (ou pré-approuvé), plutôt que sur la pratique consistant à écrire du nouveau code exempt de vulnérabilités. Bien que la sensibilisation à la sécurité concernant les composants tiers (en particulier le patching, dont la débâcle Log4Shell est un excellent exemple : 30 % des instances restent non corrigées depuis décembre) soit très importante, tout comme le test du code existant, ces éléments ne suffisent pas à atteindre un niveau fonctionnel de compétence en codage sécurisé.

Les vulnérabilités au niveau du code sont introduites par des développeurs qui ont appris de mauvaises pratiques de codage, et le manque d'accent mis sur l'écriture de code sécurisé dans leurs indicateurs de performance (KPI), couplé à une culture de sécurité médiocre, ne fait que renforcer cette situation comme une norme acceptable.

Les responsables de la sécurité peuvent grandement améliorer la sensibilisation initiale et identifier les lacunes les plus urgentes en veillant d'abord à ce que les développeurs aient une vision complète de ce qu'implique le codage sécurisé. Tester et scanner du code pré-approuvé est une fonction, mais la réduction des vulnérabilités nécessite une formation pratique aux bonnes pratiques de codage sécurisé, dans les langages et frameworks activement utilisés.

Le contexte est essentiel pour la montée en compétences des développeurs, et ils doivent être associés à la démarche concernant les objectifs de sécurité de l'entreprise.

De nombreuses organisations doivent mettre à niveau leurs programmes de sécurité.

Avec l'explosion des technologies logicielles entraînant une croissance rapide des incidents de cybersécurité au cours de la dernière décennie, nous nous efforçons tous de suivre le rythme des cybercriminels qui travaillent sans relâche pour découvrir des failles dans des systèmes précieux.

La méthodologie DevSecOps repose sur l'idée que chacun partage la responsabilité de la sécurité - développeurs inclus - et c'est une considération majeure dès le début du cycle de vie du développement logiciel (SDLC). Le problème est que, surtout dans les grandes entreprises, elles peuvent être très loin de mettre en œuvre le DevSecOps comme norme. En 2017, une étude du Project Management Institute montrait que 51 % des organisations utilisaient encore le modèle en cascade (Waterfall) pour leur développement logiciel. Cette étude a maintenant cinq ans, mais connaissant la lenteur des changements dans les grandes entreprises, il est peu probable qu'il y ait eu une transition brutale vers les dernières méthodologies axées sur la sécurité. Ces processus hérités peuvent rendre la tâche ardue pour les professionnels de la sécurité qui tentent de couvrir tous les fronts avec une stratégie globale de protection contre les cybermenaces, et intégrer les développeurs et leurs besoins dans ce paysage est un défi.

Cependant, nous ne pouvons pas utiliser cela comme excuse. Les professionnels de la sécurité peuvent s'appuyer sur les développeurs dans une stratégie améliorée ; ils doivent simplement se familiariser avec leurs besoins et les considérer comme faisant partie de leur dispositif de défense. Ils ont besoin d'une formation complète, et toute responsabilité en matière de sécurité doit être mise en œuvre en respectant leur pile technologique et leur flux de travail.

Codage sécurisé = le dossier « trop difficile » ?

Les recherches d'Evans Data révèlent qu'une proportion stupéfiante de 86 % des développeurs éprouvent des difficultés à coder de manière sécurisée, et 92 % des responsables d'équipes techniques admettent que leurs collaborateurs ont besoin de davantage de formation sur les cadres de sécurité. Plus inquiétant encore, 48 % des sondés reconnaissent laisser délibérément des vulnérabilités dans leur code.

Le constat est alarmant. Il semble que les développeurs ne bénéficient généralement ni d'une formation fréquente et adaptée, ni d'une sensibilisation suffisante aux bonnes pratiques d'hygiène informatique. En filigrane, le problème central apparaît clairement : la sécurité n'est tout simplement pas une priorité dans leur travail quotidien. De plus, les formations reçues ne renforcent ni leur confiance ni leurs compétences pratiques, et ne leur permettent pas de mesurer les conséquences réelles de la mise en production d'un code vulnérable.

L'attaque par ransomware contre Colonial Pipeline a été l'un des incidents de sécurité de la chaîne d'approvisionnement les plus perturbateurs de l'année écoulée, faisant craindre une interruption prolongée de la moitié de l'approvisionnement en essence sur la côte est des États-Unis. Heureusement, le service a été rétabli rapidement, mais non sans susciter une vive inquiétude. Ce fut un moment charnière où le grand public a pris conscience qu'un incident cyber pouvait gravement affecter des infrastructures physiques, pourtant rarement perçues comme dépendantes du logiciel ou vulnérables aux cyberattaques. Tout ce chaos a été rendu possible par deux anciennes vulnérabilités non corrigées, dont l'insidieuse et pourtant bien connue injection SQL. Si les développeurs mesuraient les enjeux réels de la publication d'un code vulnérable, ils comprendraient vite qu'il n'existe aucun scénario où cela constitue un risque commercial acceptable.

Le « P-P-T » fonctionnel ne dépend pas du développeur.

Le célèbre « triangle d'or » composé des Personnes, des Processus et des Outils ne peut être atteint sans une stratégie mûrement réfléchie. Les développeurs ne sont pas en mesure d'intégrer un processus de sécurité opérationnel si leurs besoins et leurs contraintes ne sont pas pris en compte.

Un changement culturel majeur est nécessaire pour promouvoir une sécurité portée par les développeurs, et cela commence par des parcours pédagogiques qui apportent une plus grande clarté tant aux ingénieurs qu'aux équipes de sécurité.