Les développeurs qui créent les logiciels, les applications et les programmes qui animent l’activité numérique sont devenus la pierre angulaire de nombreuses organisations. La plupart des entreprises modernes ne pourraient pas fonctionner (de manière rentable) sans applications et programmes compétitifs, ou sans accès 24 heures sur 24 à leurs sites Web et autres infrastructures.
Et pourtant, ces mêmes points de contact sont aussi souvent la passerelle que les pirates et autres utilisateurs malveillants utilisent pour voler des informations, lancer des attaques et servir de tremplin à d’autres activités criminelles telles que la fraude et les rançongiciels.
Les attaques réussies restent fréquentes, même si les dépenses en cybersécurité dans la plupart des organisations sont en hausse, et même si les mouvements comme DevSecOps déplacent la sécurité vers les développeurs qui sont aujourd’hui la pierre angulaire 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 2ème année, Secure Code Warrior a mené Enquête sur l’état de la sécurité pilotée par les développeurs, 2022 en partenariat avec Evans Data Corp en décembre 2021, interrogeant 1 200 développeurs dans le monde pour comprendre les compétences, les perceptions et les 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 identifié 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 y a un grand écart entre ce que les développeurs pense est un code sécurisé, et quel code sécurisé réellement est.
Il n’était pas surprenant que l’écriture de code de qualité soit une priorité absolue pour la communauté du développement. Mais interrogés spécifiquement sur le code sécurisé, seuls 29 % ont déclaré que la pratique active d’écriture de 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, examiner le code existant (37 %) et s’appuyer sur des bibliothèques externes pour un code sûr (37 %) étaient les principales pratiques que les développeurs associaient au codage sécurisé. La réutilisation de code qui avait déjà été 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 % déclarant qu’il s’agit d’une pratique de pointe dans la création de code sécurisé.
Interrogés plus en détail, le manque de temps et le manque d’approche cohérente de la part de la direction ont été cité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. Aborder cette déconnexion de ce qui constitue un code sécurisé est nécessaire pour que les développeurs créent un code de qualité qui soit également 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 remplie de professionnels qui se soucient de ce qu’ils font. Écrire un code de qualité supérieure était extrêmement important 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 du code sécurisé, et n’ont pas consacré suffisamment de ressources à la formation ou permis à leurs développeurs d’atteindre ces objectifs.
En fait, la plupart des développeurs ont déclaré que leurs organisations n’avaient 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 le code comme 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 probablement sans dire, mais dans le paysage complexe des menaces d’aujourd’hui, espérer simplement de bons résultats sans 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 à travailler vers l’objectif du 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 est en dehors de cette définition doit être considéré comme non sécurisé.
Le codage sécurisé doit être défini comme la pratique de développeurs qualifiés écrivant 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 peut travailler vers 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 leurs développeurs qui réaliseront l’objectif de mise en œuvre de pratiques de code totalement sécurisé. Ce soutien est essentiel. Sans cela, 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 peut nécessiter de nouveaux objectifs de benchmarking pour les développeurs, qui ont traditionnellement été mesurés sur la vitesse de leur codage. En fait, 37 % des développeurs de l’enquête ont déclaré avoir laissé des vulnérabilités connues dans leur code parce que des délais serrés ne leur permettaient pas le temps nécessaire pour les corriger ou pour coder correctement dès le départ.
Au début, cela peut signifier augmenter les délais pour donner aux développeurs plus de temps pour coder correctement, bien que cette dépense de temps au début du processus de codage sera probablement compensée plus tard en raison d’un besoin moindre de révisions de programme, de correctifs et de post-déploiement. travail. Et éliminer la possibilité d’une violation déployée peut finir par économiser des centaines d’heures et peut-être des millions en perte de revenus, en amendes et en frais de nettoyage.
Les développeurs auront également besoin d’une formation pratique pertinente, en particulier 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 à la lumière de 36 % des répondants à l’enquête qui ont déclaré vouloir supprimer les vulnérabilités de leur code, mais n’avaient pas les compétences ou les connaissances nécessaires pour le faire.
Vous voulez lire plus d’informations tirées de l’enquête de Secure Code Warriors auprès de 1200 développeurs du monde entier ? Vous pouvez y accéder ici: État de la sécurité pilotée par les développeurs 2022