Définir le code sécurisé

Les développeurs qui créent les logiciels, les applications et les programmes au cœur de l'activité numérique sont devenus l'élément vital de nombreuses organisations. La plupart des entreprises modernes ne pourraient pas fonctionner (de manière rentable) sans applications et programmes compétitifs, ni sans un accès permanent à leurs sites web et autres infrastructures.

Pourtant, ces mêmes points de contact constituent souvent la porte d'entrée utilisée par les pirates informatiques et autres individus malveillants pour voler des informations, lancer des attaques et servir de tremplin à d'autres activités criminelles telles que la fraude et les rançongiciels. Le dernier rapport Verizon Data Breach Investigations souligne que les menaces pesant sur les entreprises et les organisations sont aujourd'hui plus dangereuses et coûteuses que jamais.

Les attaques réussies restent monnaie courante, bien que les dépenses en cybersécurité aient considérablement augmenté dans la plupart des organisations et que des mouvements comme le DevSecOps déplacent la sécurité vers ces développeurs qui sont aujourd'hui le moteur de l'entreprise.

Les développeurs comprennent l'importance de la sécurité et souhaitent massivement déployer un code sécurisé et de qualité, mais les vulnérabilités logicielles continuent d'être exploitées.

Pourquoi ?

Pour la deuxième année, Secure Code Warrior a mené l'enquête « The state of developer-driven security », en 2022, en partenariat avec Evans Data Corp en décembre 2021. Nous avons interrogé 1 200 développeurs dans le monde pour comprendre leurs compétences, leurs perceptions et leurs comportements en matière de pratiques de codage sécurisé, ainsi que leur impact et leur pertinence perçue dans le cycle de vie du développement logiciel (SDLC).

L'enquête a révélé l'absence de définition claire ou de compréhension de ce qui constitue un code sécurisé. Il s'avère qu'il existe un écart important entre ce que les développeurs considèrent comme du code sécurisé et ce qu'il est réellement.

Il n'est pas surprenant que l'écriture d'un code de qualité soit une priorité absolue pour la communauté des développeurs. Mais lorsqu'on les interroge spécifiquement sur le code sécurisé, seuls 29 % ont déclaré que la pratique active consistant à écrire du code exempt de vulnérabilités était une priorité. Au lieu de cela, les développeurs ont associé des pratiques moins sûres et beaucoup moins fiables à la création de code sécurisé. Par exemple, l'examen du code existant (37 %) et le recours à des bibliothèques externes pour obtenir du code sûr (37 %) sont les principales pratiques que les développeurs associent au codage sécurisé. La réutilisation de code déjà jugé sécurisé (32 %) était un autre choix populaire. La pratique active consistant à écrire du code exempt de vulnérabilités arrive en 6e position, avec 29 % des répondants affirmant qu'il s'agit d'une pratique clé dans la création de code sécurisé. Interrogés plus avant, le manque de temps et l'absence d'approche cohérente de la part de la direction ont été cités comme les principaux obstacles à la création de code sécurisé.

Le recours au code existant est l'un des facteurs qui augmente le risque de livraison de logiciels présentant des vulnérabilités exploitables. Combler ce fossé sur ce qui constitue un code sécurisé est nécessaire pour que les développeurs puissent créer un code de qualité qui soit également sécurisé.

Il s'avère qu'il existe un écart important entre ce que les développeurs considèrent comme du code sécurisé et ce qu'il est réellement.

Que peuvent faire les entreprises pour remédier à cette situation ?

L'un des messages essentiels de cette enquête est que la communauté des développeurs est composée de professionnels soucieux de leur travail. L'écriture d'un code de haute qualité est une priorité absolue pour eux en tant que groupe. Le problème est que, dans de nombreux cas, les organisations pour lesquelles ils travaillent n'ont pas identifié les meilleures pratiques nécessaires pour produire un code sécurisé et n'ont pas investi suffisamment de ressources dans la formation ou n'ont pas donné à leurs développeurs les moyens d'atteindre ces objectifs.

En fait, la plupart des développeurs ont déclaré que leur organisation n'avait même pas de définition claire de ce qui constitue un code sécurisé. L'un des exemples les plus préoccupants est que 28 % des personnes interrogées ont déclaré que leur organisation considérait le code comme sécurisé si aucune faille n'était signalée une fois qu'une application ou un programme était déployé dans un environnement de production ou mis à la disposition du public.

Il va sans dire que, dans le paysage actuel des menaces complexes, se contenter d'espérer de bons résultats sans réellement œuvrer pour les obtenir produira probablement des résultats prévisibles : encore plus de failles de sécurité.

Heureusement, il est relativement facile de commencer à résoudre le problème, puis d'œuvrer vers l'objectif d'un code sécurisé. La première étape, et sans doute la plus importante, consiste pour les organisations à définir ce qu'elles considèrent comme un code sécurisé. Et tout ce qui sort de cette définition doit être considéré comme non sécurisé.

Le codage sécurisé doit être défini comme la pratique par laquelle des développeurs qualifiés écrivent du code exempt de vulnérabilités, dès le début du cycle de vie du développement logiciel (SDLC). Ce n'est qu'une fois cette pratique définie que la communauté des développeurs peut travailler à cet objectif.

Faire du code sécurisé une réalité

Une fois la définition du code sécurisé établie, les organisations doivent être prêtes à soutenir ces efforts et leurs développeurs qui seront chargés de mettre en œuvre des pratiques de codage totalement sécurisées. Ce soutien est essentiel. Sans lui, la définition du code sécurisé au sein de votre organisation, bien qu'importante, ne sera guère plus qu'un tigre de papier. Les pratiques de codage sécurisé doivent être approuvées par la direction et bénéficier de la considération, de l'autorité et du budget appropriés pour réussir.

Cela pourrait nécessiter de nouveaux objectifs de référence pour les développeurs, traditionnellement évalués sur leur vitesse de codage. En fait, 37 % des développeurs interrogés ont déclaré laisser des vulnérabilités connues dans leur code, car des délais serrés ne leur permettaient pas de prendre le temps nécessaire pour les corriger ou pour coder correctement dès le départ. Au début, cela peut signifier rallonger les délais pour donner aux développeurs plus de temps pour coder correctement, bien que cet investissement en temps au début du processus de développement soit probablement compensé plus tard par une réduction du besoin de révisions de programmes, de correctifs et de travail post-déploiement. Et éliminer la possibilité d'une faille une fois le déploiement effectué peut permettre d'économiser des centaines d'heures et potentiellement des millions en pertes de revenus, en amendes et en coûts de nettoyage.

Les développeurs auront également besoin d'une formation pratique et pertinente, notamment en ce qui concerne les vulnérabilités spécifiques auxquelles ils sont susceptibles d'être confrontés, ainsi que d'une aide pour apprendre à identifier et à corriger les vulnérabilités du code. C'est d'autant plus vrai que 36 % des personnes interrogées ont déclaré vouloir supprimer les vulnérabilités de leur code, mais ne pas disposer des compétences ou des connaissances nécessaires pour le faire.

37 % des développeurs interrogés ont déclaré laisser des vulnérabilités connues dans leur code, car des délais serrés ne leur permettaient pas de prendre le temps nécessaire pour les corriger ou pour coder correctement dès le départ.

Vous souhaitez en savoir plus sur ce sujet ?

Livre blanc : Les défis (et opportunités) pour améliorer la sécurité logicielle.
Rapport : Enquête sur l'état de la sécurité pilotée par les développeurs, 2022.