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

Une version de cet article a été publiée dans TechRepublic. Elle a été mise à jour et publiée ici.

‍

La création d'un environnement dans lequel les objectifs de l'équipe de sécurité et de leurs homologues développeurs sont alignés a été une bataille difficile, mais essentielle. Nous avons encore un long chemin à parcourir, mais les obstacles qui se dressent sur la voie de la synergie nécessaire pour ouvrir la porte à une responsabilité partagée en matière de sécurité des logiciels sont de plus en plus évidents. Les entreprises intelligentes veulent faire évoluer leur stratégie pour éviter ces écueils, trouver une voie productive et utiliser DevSecOps à son plein potentiel.

Ce que je n'avais pas prévu, c'est que la perception de ce qui constitue l'acte de codage sécurisé est sujette à débat. Selon une toute nouvelle étude réalisée en collaboration avec Evans Data, ce sentiment a été révélé noir sur blanc. L'enquête State of Developer-Driven Security 2022 (État de la sécurité pilotée par les développeurs 2022 ) se penche sur les principaux points de vue et expériences de 1200 développeurs actifs, mettant en lumière leurs attitudes et défis dans le domaine de la sécurité.

L'une des principales conclusions est que seuls 14 % des développeurs considèrent la sécurité comme une priorité lorsqu'ils codent. Bien que cela montre qu'il y a une énorme marge d'amélioration, 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 faire de la sécurité une partie de leur ADN. Toutefois, si l'on ajoute à cela les données relatives à la définition par les développeurs de ce que signifie pour eux le codage sécurisé, il y a de quoi s'inquiéter.

Ces perceptions sont le fruit de l'expérience des développeurs au cours de leur journée de travail et reflètent l'environnement de nombreuses organisations, à savoir que les développeurs ne sont tout simplement pas au centre de la lutte contre les vulnérabilités courantes. Il est essentiel de leur donner les moyens d'agir, mais en attendant, nous devons rapidement nous mettre d'accord sur la portée du "codage sécurisé" et sur ce que nous devrions attendre d'un développeur compétent en matière de sécurité. 

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

La cybersécurité est une bête aux multiples facettes, difficile à manier dans le meilleur des cas, et si le codage sécurisé ne représente qu'une partie du paysage global, c'est un rouage complexe du système qui nécessite l'attention d'un spécialiste.

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, son champ d'action se limitant souvent à une seule catégorie par opposition à une vision holistique des principes fondamentaux et au-delà. Les développeurs ont indiqué qu'ils se fiaient à l'utilisation de code existant (ou pré-approuvé), plutôt qu'à la pratique consistant à écrire un nouveau code exempt de vulnérabilités. Alors que la sensibilisation à la sécurité concernant les composants tiers (en particulier les correctifs, et la débâcle de Log4Shell en est un excellent exemple : 30 % des instances n'ont pas été corrigées depuis décembre) est très importante, tout comme le test du code existant, mais ces éléments ne suffisent pas à atteindre un niveau fonctionnel de capacité de codage sécurisé. 

Les vulnérabilités au niveau du code sont introduites par des développeurs qui ont appris de mauvais schémas de codage, et le fait de ne pas mettre l'accent sur l'écriture de code sécurisé dans leurs indicateurs clés de performance (associé à une culture de la sécurité peu convaincante) ne fait que renforcer cette situation comme une norme acceptable. 

Les responsables de la sécurité peuvent contribuer grandement à améliorer la sensibilisation initiale et à identifier les domaines où les lacunes en matière de connaissances sont les plus pressantes, en veillant tout d'abord à ce que la cohorte de développement ait une vue d'ensemble de ce qu'implique le codage sécurisé. Tester et analyser le code approuvé au préalable est une fonction, mais la réduction des vulnérabilités nécessite une formation pratique à de bons modèles de codage, sûrs, dans les langages et les cadres activement utilisés.

Le contexte est essentiel pour la montée en compétence des développeurs, qui doivent être associés aux objectifs de sécurité de l'entreprise.

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

Avec l'explosion des technologies basées sur les logiciels et la 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 acteurs de la menace qui travaillent 24 heures sur 24 pour découvrir des exploits dans des systèmes précieux. 

La méthodologie DevSecOps repose sur l'idée que tout le monde partage la responsabilité de la sécurité - y compris les développeurs - et qu'il faut en tenir compte dès le début du cycle de développement durable. Le problème, c'est que les grandes entreprises, en particulier, peuvent être très loin de mettre en œuvre DevSecOps en tant que norme. En 2017, une étude du Project Management Institute a montré que 51 % des organisations utilisaient encore la méthode Waterfall pour le développement de leurs logiciels. Cette étude date maintenant de cinq ans, mais sachant à quel point les changements peuvent être progressifs 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 créer une bataille difficile pour les professionnels de la sécurité qui tentent de couvrir toutes les bases d'une stratégie globale de protection contre les cybermenaces, et l'adaptation des développeurs et de leurs besoins à ce paysage est un défi. 

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

Codage sécurisé = le panier "trop dur" ?

L'étude d'Evans Data a mis en lumière le fait que 86% des développeurs estiment qu'il est difficile de pratiquer un codage sécurisé, et que 92% des responsables de développement admettent que leurs équipes ont besoin d'une formation plus poussée en matière de cadres de sécurité. Fait inquiétant, 48 % des personnes interrogées ont admis qu'elles laissaient sciemment des vulnérabilités dans leur code. 

Le tableau est très inquiétant. Il semble que, de manière générale, les développeurs ne bénéficient pas d'une formation fréquente et adéquate et qu'ils ne soient pas suffisamment exposés aux bonnes pratiques et à l'hygiène en matière de sécurité. En lisant entre les lignes, cela renforce le nœud du problème : les développeurs ne considèrent tout simplement pas la sécurité comme une priorité dans leur travail. De plus, la formation qu'ils reçoivent ne leur donne pas confiance en eux, ne leur permet pas d'acquérir des compétences pratiques et ne les aide pas à comprendre l'impact de leur décision de livrer un code vulnérable. 

L'attaque du ransomware de Colonial Pipeline a été l'un des incidents de sécurité de la chaîne d'approvisionnement les plus perturbants de l'année dernière, suscitant la crainte que la moitié de l'approvisionnement en gaz de la côte est des États-Unis ne soit coupée pour une période indéterminée. Heureusement, la situation s'est rétablie rapidement, mais non sans une certaine appréhension au sein de la communauté. Ce fut l'un de ces moments cruciaux où le grand public a été confronté à la perspective d'un cyberincident affectant gravement un élément du monde physique qui n'est pas nécessairement considéré comme piloté par un logiciel, ou comme un risque de cyberattaque. Tout ce chaos a été rendu possible par deux anciennes vulnérabilités non corrigées, dont l'une était l'injection SQL, insidieuse mais largement connue. Si les développeurs savaient ce qui est réellement en jeu lorsqu'ils choisissent de livrer un code vulnérable, ils verraient rapidement qu'il n'y a pas de scénario dans lequel cela constitue un risque commercial acceptable.

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

Le fameux "triangle d'or" des personnes, des processus et des outils n'est pas réalisable sans une stratégie soigneusement étudiée, et les développeurs ne sont pas en mesure de s'assimiler à un processus de sécurité opérationnel sans tenir compte de leurs besoins et de leurs défis.

Il faudra un changement culturel important pour améliorer la sécurité axée sur les développeurs, et cela commence par des parcours éducatifs qui amènent les ingénieurs et l'équipe de sécurité à une plus grande clarté.