Définition du code sécurisé

Les développeurs qui créent les logiciels, les applications et les programmes qui stimulent les activités numériques sont devenus la pierre angulaire de nombreuses organisations. La plupart des entreprises modernes ne seraient pas en mesure de fonctionner (de manière rentable) sans applications et programmes compétitifs, ou sans un accès 24 heures sur 24 à leurs sites Web et à d'autres infrastructures.

Pourtant, ces mêmes points de contact constituent souvent la passerelle que les pirates informatiques et autres utilisateurs malveillants utilisent pour voler des informations, lancer des attaques et se lancer dans d'autres activités criminelles telles que la fraude et les rançongiciels. Le dernier rapport d'enquêtes sur les violations de données de Verizon souligne que les menaces visant les entreprises et les organisations sont plus dangereuses et plus coûteuses aujourd'hui qu'à tout autre moment de l'histoire.

Les attaques réussies restent monnaie courante, même si les dépenses consacrées à la cybersécurité dans la plupart des entreprises sont en hausse et même si des mouvements tels que DevSecOps orientent la sécurité vers les développeurs qui sont la pierre angulaire des entreprises aujourd'hui.

Les développeurs comprennent l'importance de la sécurité et souhaitent majoritairement 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 consécutive, Secure Code Warrior a mené une enquête sur l'état de la sécurité menée par les développeurs en 2022 en partenariat avec Evans Data Corp en décembre 2021. Nous avons interrogé 1 200 développeurs dans le monde entier afin de comprendre les compétences, les perceptions et les comportements en matière de pratiques de codage sécurisées, ainsi que leur impact et leur pertinence perçue sur le cycle de vie du développement logiciel (SDLC).

L'enquête a révélé l'absence d'une définition claire ou d'une 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 pensent être un code sécurisé et ce qu'est réellement un code sécurisé.

Il n'est pas surprenant que l'écriture de code de qualité soit une priorité absolue pour la communauté des développeurs. Mais lorsqu'on les a interrogés spécifiquement sur le code sécurisé, seuls 29 % ont répondu que la pratique active consistant à écrire du code exempt de vulnérabilités était prioritaire. Les développeurs ont plutôt associé des pratiques moins sûres et beaucoup moins fiables à la création de code sécurisé. Par exemple, l'examen minutieux du code existant (37 %) et le recours à des bibliothèques externes pour un code sécurisé (37 %) étaient les meilleures pratiques associées au codage sécurisé par les développeurs. La réutilisation d'un code déjà considéré comme sûr (32 %) était un autre choix populaire. La pratique active consistant à écrire du code exempt de vulnérabilités s'est classée en sixième position, 29 % déclarant qu'il s'agissait d'une pratique exemplaire en matière de 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é considérés comme les principaux obstacles à la création d'un code sécurisé.

Le recours au code existant est l'un des facteurs qui augmente le risque que des logiciels soient livrés avec des vulnérabilités exploitables. Il est nécessaire de remédier à cette déconnexion de ce qui constitue un code sécurisé 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 pensent être un code sécurisé et ce qu'est réellement un code sécurisé.

Que peuvent faire les organisations pour remédier à la situation ?

L'un des principaux messages de l'enquête était que la communauté des développeurs dans son ensemble est composée de professionnels qui se soucient de leur métier. L'écriture d'un code de qualité supérieure était extrêmement importante 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 requises pour produire du code sécurisé, et n'ont pas investi suffisamment de ressources dans la formation ou n'ont pas permis à leurs développeurs 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 inquiétants est que 28 % des personnes interrogées ont déclaré que leur organisation considérait que le code était sécurisé si aucune violation 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.

Cela va sans dire, mais dans le paysage complexe des menaces d'aujourd'hui, le simple fait d'espérer de bons résultats sans réellement y travailler produira probablement des résultats prévisibles : encore plus de failles de sécurité.

Heureusement, il s'agit d'une situation où il est relativement facile de commencer au moins à résoudre le problème, puis de commencer à atteindre 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 n'entre pas dans 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 expérimentés écrivent du code exempt de vulnérabilités, dès le début du SDLC. Ce n'est qu'une fois cette pratique définie que la communauté des développeurs pourra travailler à la réalisation de cet objectif.

Faire de l'objectif 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 à soutenir leurs développeurs qui atteindront l'objectif de mettre en œuvre des pratiques de code totalement sécurisées. Ce soutien est essentiel. Sans cela, la définition d'un code sécurisé au sein de votre organisation, bien qu'importante, ne sera guère plus qu'une question de papier. Les pratiques de codage sécurisé doivent être approuvées par la direction et bénéficier de l'attention, de l'autorité et du budget appropriés pour réussir.

Cela peut nécessiter de nouveaux objectifs d'analyse comparative pour les développeurs, qui étaient traditionnellement mesurés en fonction de la vitesse de leur codage. En fait, 37 % des développeurs interrogés ont déclaré avoir laissé des vulnérabilités connues dans leur code parce que les délais serrés ne leur permettaient pas de les corriger ou de coder correctement dès le départ. Dans un premier temps, cela peut impliquer d'allonger les délais pour donner aux développeurs plus de temps pour coder correctement, même si ce temps perdu au début du processus de codage sera probablement compensé plus tard en raison de la diminution des révisions du programme, des correctifs et des travaux post-déploiement. Et éliminer la possibilité d'une faille déployée peut permettre d'économiser des centaines d'heures et peut-être des millions de dollars 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 qu'ils sont susceptibles de rencontrer, et d'une aide pour apprendre à identifier et à corriger les vulnérabilités du code. Cela est particulièrement vrai si l'on considère que 36 % des personnes interrogées ont déclaré vouloir supprimer les vulnérabilités de leur code, mais ne disposaient pas des compétences ou des connaissances nécessaires pour le faire.

37 % des développeurs interrogés ont déclaré avoir laissé des vulnérabilités connues dans leur code parce que les délais serrés ne leur permettaient pas de corriger 37 d'entre elles ou de coder correctement dès le départ.

Vous souhaitez en savoir plus sur ce sujet ?

Livre blanc : Les défis (et opportunités) liés à l'amélioration de la sécurité logicielle.
Rapport : L'état de l'enquête de sécurité menée par les développeurs, 2022.