Quel rôle joue l'élément humain dans l'avenir du codage sécurisé ?

Alors que le nombre de cybermenaces ne cesse de croître, les entreprises font des compromis quotidiens entre sécurité, praticité et rapidité, s'exposant ainsi à des risques. De nouvelles approches de codage sécurisé sont nécessaires, donc Secure Code Warrior a collaboré avec Evans Data Corp. pour mener des recherches primaires sur les attitudes des développeurs à l'égard du codage sécurisé, des pratiques de code sécurisées et des opérations de sécurité (télécharger le livre blanc) ici).

Ce rapport a révélé que si la pensée réactive « à l'ancienne » domine toujours, il existe une prise de conscience croissante de la nécessité de solutions plus proactives, qui font des développeurs eux-mêmes la première ligne de défense.

Toute exploration de l'adoption de pratiques de codage sécurisées doit commencer par une compréhension des humains impliqués dans leur mise en œuvre, de leur perception de celle-ci et de leur capacité à les mettre en œuvre. Cela nous amène à la pièce la plus importante du puzzle : comment leur donner les moyens de coder de manière plus sécurisée dès le départ et d'envoyer du code de qualité plus rapidement et en toute confiance ?

Codage sécurisé : où en sommes-nous aujourd'hui et qu'est-ce qui doit changer ? Télécharger l'infographie « L'élément humain » maintenant.

Perspectives actuelles : réactives ou proactives

Lorsque les développeurs et les responsables du développement ont été interrogés sur les activités qu'ils associent au codage sécurisé, les trois réponses les plus fréquentes ont été les suivantes :

• Utilisation d'outils d'analyse sur les applications déployées.
• Vérification manuelle du code pour détecter les vulnérabilités.
• Pratique active et continue de l'écriture de logiciels protégés contre les vulnérabilités.

Comme nous pouvons le constater, deux des trois réponses les plus fréquentes se concentraient toujours sur les approches réactives : la première dépendait de l'outillage (scanners) et la seconde du développeur (c'est-à-dire humain) effectuant des vérifications manuelles.

Dans le même temps, deux des trois activités nominées font appel à l'élément humain. Cela montre que la sécurité est de plus en plus perçue comme une question humaine. Mais de toutes les activités nominées, la plus révélatrice est la troisième, qui identifie le facteur humain un logiciel écrit qui est protégé contre les vulnérabilités en premier lieu. Cela met en évidence un changement vers la gauche : une approche proactive et préventive qui intègre la sécurité dans les logiciels dès le début du SDLC.

Quelle est la place de la sécurité dans le SDLC ?

Lorsqu'on demande aux développeurs et aux responsables du développement comment ils envisagent l'intégration de pratiques de code sécurisées dans le SDLC, les avis divergent. 55 % des responsables pensent que le codage sécurisé est intégré à l'ensemble du processus de développement, contre seulement 43 % des développeurs. La différence pourrait refléter les rôles différents de ces deux groupes au sein du SDLC. La direction est généralement moins impliquée dans le travail de programmation proprement dit et a tendance à avoir une vision plus globale, tandis que les développeurs peuvent être plus préoccupés par les détails.

Mais du point de vue de la sécurité globale et de la qualité du code, ce qui est alarmant, c'est que seuls 13 % des développeurs et 10 % des responsables déclarent que les pratiques de code sécurisées devraient être intégrées dès les étapes de conception, dès le début du SDLC. Il s'agit d'une opportunité énorme et non exploitée. Selon une étude d'IBM, il est trente fois plus coûteux de corriger les vulnérabilités présentes dans le code après la publication que si elles étaient détectées et corrigées au début.1 Cela constitue une puissante incitation à une nouvelle défense proactive et dirigée par l'homme en matière de sécurité logicielle, qui donne aux développeurs les moyens de coder de manière plus sécurisée, dès le départ. La sécurité des logiciels ne peut pas être résolue en se fiant uniquement à l'outillage : elle doit tenir compte de l'élément humain.

L'élément humain est-il préparé ?

97 % des développeurs interrogés estiment avoir reçu une formation suffisante en matière de codage sécurisé, et 95 % ont reconnu que la formation au codage sécurisé avait été précieuse pour leur carrière. Mais avant d'accepter ces affirmations pour argent comptant, nous devons nous demander : pourquoi les vulnérabilités du code sont-elles toujours aussi répandues ? Les affirmations des développeurs concernant leur expertise en matière de code sécurisé ne sont-elles qu'un cas d'ego humain ? Les preuves vont certainement dans ce sens. Plus modestement, plus de 88 % des développeurs interrogés admettent que le codage sécurisé est difficile à apprendre, et 91 % des responsables du développement reconnaissent que les pratiques de codage sécurisé sont difficiles à mettre en œuvre. Lorsqu'on leur demande d'identifier leurs principales préoccupations personnelles concernant la mise en œuvre de code sécurisé, 28 % des développeurs trouvent le processus d'apprentissage difficile, tandis que 24 % le trouvent ennuyeux. Cela montre que la formation des développeurs doit être améliorée.

De quoi a besoin l'élément humain ?

Pour surmonter le facteur « difficile », une formation sécurisée intéressante nécessite un processus « d'échafaudage » qui aide le développeur à acquérir des compétences de codage sécurisé étape par étape. Pour une pertinence maximale et une applicabilité immédiate, cette formation doit être dispensée dans le langage spécifique : cadre qu'ils utilisent au quotidien.

Pour surmonter le facteur « ennui », la formation au code sécurisé doit être dispensée de manière pratique, ce qui s'est avéré bien plus intéressant pour les développeurs que les modèles obsolètes en classe ou « regardez cette vidéo ». Celles-ci devraient inclure des simulations en direct qui permettent aux développeurs de relever des défis de sécurité parfois risqués dans un environnement sûr. L'objectif devrait être d'apprendre aux développeurs à détecter et à corriger les vulnérabilités dans le code pendant qu'il travaille et à intégrer le codage sécurisé à leur flux quotidien. Un autre facteur clé est le linting et le coaching à l'intérieur de l'IDE, qui aident les développeurs à constamment apprendre et à améliorer leurs compétences au fur et à mesure qu'ils codent, tout en prévenant et en éliminant les vulnérabilités au fur et à mesure.

Si vous souhaitez savoir comment fournir à vos développeurs ce nouveau niveau d'outils et de formations centrés sur les développeurs, réservez une démo maintenant.

Vous pouvez également téléchargez votre copie du livre blanc Passer de la réaction à la prévention : le nouveau visage de la sécurité des applications

‍