Le coût d'un mauvais code 

Grâce aux progrès technologiques, les développeurs peuvent désormais livrer leur code plus rapidement que jamais. Cela peut être stimulant pour l'innovation, mais décourageant lorsqu'il s'agit d'augmenter la qualité et la sécurité des logiciels. Justifier les coûts des outils supplémentaires, des programmes de formation et de l'investissement dans la mise à niveau des développeurs peut sembler être un bienfait plutôt qu'une fonction essentielle de l'entreprise si la vitesse du code livré est maintenue.  

L'envoi de code plus rapide est peut-être devenu plus facile, mais malheureusement l'envoi de code sécurisé ne l'est pas, ce qui laisse les organisations vulnérables à plus de menaces que jamais. Le coût de la cybercriminalité est stupéfiant dans le monde entier, et il augmente rapidement. En fait, en 2020, le coût de la cybercriminalité s'élevait à environ 1 000 milliards de dollars. En moyenne, le coût d'une violation de données s'élève à 4,35 millions de dollars, répartis entre la perte de clientèle actuelle et potentielle, ainsi que les ressources consacrées à la détection, à l'escalade et à la reprise du travail. 

Malgré ces coûts astronomiques, plus de la moitié des entreprises n'exigent pas des développeurs qu'ils suivent chaque année une formation formelle sur le code sécurisé.

Les professionnels de la sécurité savent tous que la recherche et la correction des vulnérabilités peuvent s'apparenter à un jeu de bonneteau. Même si vous disposez déjà d'un programme de sécurité assorti d'une stratégie de remédiation, il y a toujours une possibilité d'amélioration. La plupart des organisations constatent que lorsque leur capacité de sauvegarde ou de reprise après sinistre est mise à l'épreuve, leur approche de la sécurité n'est pas aussi solide qu'elles le pensaient. Si le renforcement de la résilience de votre organisation face aux cyberattaques est l'une de vos principales priorités, le changement de perspective laissé à vos développeurs devrait faire partie de vos plans pour continuer à améliorer votre posture de sécurité. Une équipe de développeurs compétents et responsabilisés, qui conçoivent des codes sécurisés dès le départ et qui sont suffisamment informés pour localiser et corriger rapidement les vulnérabilités, est votre moyen le plus rentable d'atténuer les risques.   

Une idée fausse en matière de formation des développeurs est qu'il s'agit simplement d'un coût pour l'entreprise ou même d'une police d'assurance. Selon Klaus Klinger, DevSec Awareness Evangelist chez Allianz, "Tout doit commencer dans la tête de la direction. Investir dans la formation des développeurs n'est pas un investissement perdu, mais un investissement dans la qualité, la productivité et la réputation de l'entreprise".

Le retour sur investissement est souvent difficile à quantifier dans ce domaine, mais en fin de compte, les entreprises devraient se demander comment leur dispositif de sécurité les aide à réduire les risques, à rationaliser leur approche et à faire gagner du temps et de la productivité à leurs équipes de développeurs. 

Comment quantifier le retour sur investissement des coûts de cybersécurité ?

Lorsqu'il s'agit de retour sur investissement, il est important de l'envisager sous deux angles différents : les économies réalisées grâce à la réduction des risques et l'impact de votre formation en matière de sécurité.

Prenons cet exemple trop courant : une vulnérabilité ou une brèche entraîne la mise hors ligne d'un site de commerce électronique pendant plusieurs jours, le temps que ses équipes recherchent le problème et la manière de le résoudre. Le coût de l'absence de remédiation peut être quantifié en termes de perte de revenus pendant la panne, d'impact du vol d'informations d'identification, de perte de confiance des clients (entraînant une réduction des ventes à long terme) et de perte de productivité globale pendant la résolution du problème. 

Il s'agit en fait d'une analyse coûts/bénéfices. Les domaines clés que vous voudrez évaluer sont le niveau de maturité de votre entreprise en matière de sécurité, les niveaux d'acceptation des risques de votre entreprise et les domaines de votre code qui doivent être maintenus ou améliorés.

Les gens se concentrent souvent sur les mauvaises mesures pour déterminer le succès et la valeur. Peut-être devrions-nous moins nous préoccuper du retour sur l'investissement initial du programme et plutôt mesurer l'impact du programme lui-même. 

Mesurer pour prouver l'impact

Afin d'établir le retour sur investissement, vous devez créer des objectifs mesurables. Cela commence par l'évaluation des connaissances de vos développeurs en matière de codage sécurisé et par la compréhension des domaines dans lesquels ils ont besoin d'améliorer leurs compétences. 

Un point de départ serait de mesurer l'engagement pour vous aider à prendre des décisions stratégiques sur la manière d'élaborer des programmes de formation plus riches. Plus important encore, mesurez l'impact. Commencez par examiner le nombre de faiblesses détectées dans le cycle de vie du développement logiciel par le biais de l'analyse du code, de la chasse aux bogues ou de tests de vulnérabilité classiques avant de lancer le programme dans chaque équipe. L'un des moyens les plus simples de savoir si votre programme de formation produit les résultats escomptés est de mesurer la diminution des vulnérabilités introduites dans votre base de code en général.

‍

Principales questions pour évaluer le retour sur investissement :‍

1. Rationalisons-nous notre approche ?

‍Est-ceque vous ajoutez des outils au problème ou est-ce que vous le résolvez à la racine ? L'ajout d'outils à votre pile technologique crée une approche de type "swiss cheese" pour trouver et corriger les vulnérabilités. Ils augmentent également les coûts opérationnels sans avoir d'impact sur la source de nombreuses vulnérabilités, à savoir le code. Bien que les outils d'analyse et de pentesting doivent absolument faire partie de votre arsenal, ils ne doivent pas être votre dernière ligne de défense. ‍

2. Améliorons-nous l'efficacité et la productivité ?

Le temps consacré à des revues de code exhaustives et à des remaniements du code renvoyé par l'AppSec peut entraîner une perte de productivité importante. Réduire les exercices d'évacuation en donnant aux équipes de développeurs les moyens de mettre la main à la pâte dans le cadre de leur formation au code sécurisé devrait constituer un bon point de référence pour évaluer l'impact positif de votre programme de sécurité. ‍

3. réduisons-nous les risques ?

Trouver et corriger une vulnérabilité peut s'apparenter à la résolution d'un grand puzzle, qui peut parfois prendre des jours, des semaines, voire des mois avant d'être complété par une solution solide. En donnant aux développeurs les moyens de prendre en charge la remédiation à la source, l'AppSec peut se concentrer sur la surveillance des risques et le renforcement de la posture de sécurité de l'organisation.

4. Augmentons-nous la vitesse (tout en maintenant la qualité) ?

Livrer du code rapidement n'est pas toujours une bonne chose. Couper les coins ronds et introduire des vulnérabilités dans le code peut créer de nombreux maux de tête à l'avenir et accumuler de la dette technique. La réflexion à court terme n'est pas la solution. Il est possible d'atténuer les risques en sécurisant le code dès le départ, afin d'éviter que le problème ne s'aggrave à l'avenir.
‍

Mesures recommandées pour le suivi :  

• Engagement - combien de temps consacrez-vous à la formation et comment les développeurs s'engagent-ils ? Remplissent-ils courses, font-ils des évaluations et participent-ils à tournaments? 
• Compétences - quels sont vos points forts ? Quels sont les domaines que vous avez identifiés comme devant être améliorés ? 
• Réduction des vulnérabilités - avez-vous remarqué une diminution mesurable des vulnérabilités lors de l'examen du code ? Voyez-vous moins de travaux de reprise de la part de l'AppSec ? 
• Productivité - combien de temps faut-il pour remédier à un problème ? Avez-vous remarqué une augmentation de la productivité ou de la vélocité grâce à la réduction de la vulnérabilité ? 

Créer de la valeur en passant à gauche

Les failles et les vulnérabilités augmentent rapidement chaque année. Il est important de commencer à élaborer de manière proactive une approche holistique de la sécurité, en commençant d'abord par votre code. Cela vous aidera à 

• Réduire la complexité en investissant dans vos ressources les plus précieuses - vos collaborateurs - au lieu de dépenser de l'argent dans des outils qui ne résolvent qu'une partie du problème. 
• Améliorer l'efficience et l'efficacité globale en limitant les reprises ou les corrections qui seraient normalement identifiées par l'AppSec après le déploiement du code. 
• Atténuez les risques et respectez la conformité, en évitant les amendes coûteuses, la perte de confiance des clients ou, pire encore, le coût d'une violation de données. 

Évitez les réflexions à court terme et les solutions rapides. Elles ne peuvent qu'entraîner une dette technique et des coûts supplémentaires à terme. Planifiez à long terme en exploitant la puissance de la formation continue et en permettant à vos développeurs d'être votre meilleure ligne de défense contre les vulnérabilités et la cybercriminalité, et constatez par vous-même l'impact et les économies réalisées.

‍

En réponse à des failles de sécurité majeures telles que la campagne SolarWinds, qui a utilisé un processus de mise à jour logicielle pour infecter plus de 18 000 utilisateurs du célèbre logiciel de gestion Orion, dont de nombreuses grandes entreprises et agences gouvernementales, les efforts de sécurité menés par les développeurs se font de plus en plus pressants. Les organisations de toutes tailles commencent à remettre en question leur "chaîne d'approvisionnement en logiciels" et à exiger que les développeurs de leurs logiciels aient des compétences et des connaissances vérifiées en matière de sécurité.

Même le gouvernement des États-Unis appelle à de meilleures pratiques de sécurité dirigées par les développeurs et à un renforcement de la chaîne d'approvisionnement en logiciels. Ces concepts sont un élément clé du décret sur l'amélioration de la cybersécurité de la nation publié par le président Biden.

Dans l'ensemble, la communauté des développeurs s'est montrée réceptive à l'idée d'intégrer la sécurité plus tôt dans le cycle de vie du développement logiciel (SDLC) grâce à des programmes et des mouvements tels que DevSecOps.

Les vulnérabilités des logiciels continuent d'être exploitées, et même les développeurs admettent qu'ils laissent parfois des failles dans leur code.

Pourquoi ?

L'enquête a confirmé que l'écriture d'un code de qualité était une priorité absolue pour la communauté des développeurs. Cependant, l'enquête a également identifié plusieurs raisons pour lesquelles la formation dispensée aux développeurs, bien qu'elle soit considérée comme utile, ne permet pas d'atteindre l'objectif de sécurisation de la chaîne d'approvisionnement en logiciels. 33 % ont déclaré qu'ils laissaient encore des vulnérabilités dans leur code parce que, même après la formation dispensée, ils ne savaient toujours pas comment identifier ou corriger les vulnérabilités connues. Par ailleurs, 92 % des personnes interrogées ont déclaré qu'elles avaient besoin d'au moins un certain niveau de formation supplémentaire en matière de sécurité, tandis que 50 % d'entre elles ont déclaré qu'elles avaient besoin de beaucoup plus de formation.

Il est clair que la communauté des développeurs apprécie la formation qui leur est dispensée. Toutefois, lorsqu'on les interroge sur les obstacles à l'adoption de pratiques de codage sécurisées, le manque de temps est cité comme la première raison, suivi par un cinquième des répondants qui citent l'absence d'une approche cohérente comme coupable. La formation est davantage considérée comme un événement ponctuel que comme un élément d'un effort stratégique continu visant à intégrer la sécurité dans les flux de travail des développeurs et à l'utiliser au quotidien.

Ainsi, les développeurs ne sont pas en mesure d'acquérir et de conserver des compétences en matière de codage sécurisé dans le cadre d'un programme cohérent et continu au sein de leur organisation. Nous pouvons également conclure que la formation actuellement reçue n'est pas particulièrement efficace ou complète, étant donné que de nombreux développeurs affirment qu'ils ne peuvent toujours pas identifier et corriger les vulnérabilités courantes.

92 % des développeurs ont déclaré avoir besoin d'au moins un certain niveau de formation supplémentaire en matière de sécurité, tandis que 92 % ont déclaré qu'une formation beaucoup plus poussée était nécessaire.

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

Il est intéressant de noter que les développeurs ont massivement déclaré qu'ils avaient besoin d'une formation plus poussée en matière de sécurité. Bien qu'ils apprécient la formation qu'ils ont reçue, il s'agit peut-être d'une situation où ils se contentent de ce qu'ils peuvent obtenir.

Lorsqu'on leur a demandé de commenter les moyens d'améliorer leur formation, leurs véritables idées sur la question ont commencé à faire surface. En général, la plupart des formations reçues par les développeurs étaient limitées, non interactives, ne ciblaient que partiellement leurs responsabilités professionnelles et ne faisaient pas partie d'un plan global ou continu visant à améliorer les compétences et la sensibilisation de leur organisation en matière de sécurité.Selon les développeurs interrogés, si les organisations souhaitent améliorer l'efficacité des formations proposées, celles-ci devraient être présentées comme faisant partie d'une approche globale visant à promouvoir une plus grande importance de la sécurité tout au long du cycle de vie du logiciel. En outre, les développeurs ont formulé des demandes spécifiques pour rendre leur formation plus utile. L'une des suggestions les plus populaires était d'inclure davantage de cas d'utilisation et d'exemples pratiques de situations qu'ils sont susceptibles de rencontrer du point de vue de la sécurité. Une autre réponse populaire pour améliorer l'efficacité était que la formation couvre éventuellement des scénarios de plus en plus complexes ou difficiles - ce qui nécessiterait probablement une approche plus cohérente et un plan à long terme pour l'apprentissage continu et le développement des compétences.Les développeurs ont également souligné le besoin de plus d'interactivité et peut-être même d'ajouter un élément de compétition. En général, les formations où les utilisateurs se contentent de regarder une vidéo ou d'écouter un cours magistral sans possibilité d'apprentissage pratique et contextuel ne sont pas considérées comme efficaces ou particulièrement utiles lorsqu'il s'agit d'enseigner une compétence complexe et (perçue comme) difficile telle que le codage sécurisé.

Les développeurs ont également souligné la nécessité d'une plus grande interactivité et peut-être même de l'ajout d'un élément compétitif.

Quels sont les autres éléments importants dans l'adoption d'une approche cohésive de la sécurité ?

La formation est évidemment essentielle lorsqu'il s'agit d'améliorer la sensibilisation à la sécurité et les compétences de la communauté des développeurs d'une organisation. Il est indispensable de veiller à ce que l'apprentissage soit continu, interactif, pertinent et contextuel. Mais une approche véritablement cohérente de la sensibilisation à la sécurité va encore plus loin.

Une approche véritablement cohérente doit prendre en compte ce qui est nécessaire pour favoriser une véritable culture de la sécurité dirigée par les développeurs. Cela peut nécessiter un changement d'orientation par rapport aux méthodes habituelles de gestion et de constitution d'équipes de développeurs. Par exemple, les développeurs ont toujours été évalués en fonction de leur rapidité à coder. Mais une approche cohésive de la sécurité pourrait impliquer de modifier ces mesures et valeurs de longue date. Au lieu de récompenser la vitesse brute, les évaluations pourraient mettre l'accent sur les développeurs capables de créer un code de qualité qui soit également sûr, c'est-à-dire dépourvu de vulnérabilités.

La communauté des développeurs pourrait également participer à cet effort. Au lieu de simplement imposer la sécurité aux développeurs, envisagez de créer ou de nommer des champions de la sécurité au sein de la communauté. Il s'agirait de développeurs talentueux et sensibilisés à la sécurité qui se distinguent soit dans le cadre de la formation, soit dans le cadre des évaluations de mesures nouvellement ciblées. Ils devraient également être disposés à aider d'autres développeurs à améliorer leurs compétences, améliorant ainsi la communauté de développement de l'intérieur.

Une approche véritablement cohérente doit prendre en compte ce qui est nécessaire pour favoriser une véritable culture de la sécurité dirigée par les développeurs. Cela peut nécessiter un changement d'orientation par rapport aux méthodes habituelles de gestion et de constitution d'équipes de développeurs.

Pour en savoir plus

Livre blanc : Les défis (et les opportunités) pour améliorer la sécurité des logiciels

Livre blanc : L'approche préventive de la sécurité des logiciels axée sur les développeurs

Livre blanc : Le DevSecOps Superbowl : Comment les champions de la sécurité peuvent aider votre équipe à remporter la victoire contre les vulnérabilités tardives.

Rapport : L'état de la sécurité pilotée par les développeurs 2022

Rencontrer les développeurs là où ils se trouvent 

Les organisations qui se tournent vers DevSecOps pour obtenir des versions plus rapides et plus sûres savent qu'il est important d'optimiser la productivité des développeurs à l'aide d'une pile technologique intégrée. Secure Code Warrior Les intégrations logicielles d'EMC permettent à vos développeurs de disposer de ressources de développement sécurisées intégrées aux outils qu'ils utilisent quotidiennement, tels que GitHub, Jira et bien d'autres. 

Secure Code Warrior garantit que votre programme de code sécurisé est intégré directement dans vos produits préférés et dans les flux de travail des développeurs pour permettre une remédiation juste à temps, ainsi que des résultats d'apprentissage plus solides.

Réduire les vulnérabilités grâce à une remédiation plus rapide

Trouver et corriger une vulnérabilité peut s'apparenter à la résolution d'un grand puzzle sans certaines pièces et sans la couverture utile, ce qui peut parfois prendre des jours, des semaines, voire des mois pour aboutir à une solution solide. Cela peut être particulièrement difficile pour les développeurs lorsqu'ils ne savent pas comment résoudre le problème, soit parce qu'ils n'ont jamais rencontré le problème auparavant, soit parce qu'ils hésitent à déployer une solution non testée ou non vérifiée.

Selon le rapport statistique EdgeScan 2022 sur les vulnérabilités, le temps moyen de remédiation (MTTR) pour une vulnérabilité localisée dans une pile complète est de 57,5 jours (rapport statistique EdgeScan 2022 sur les vulnérabilités).

Il s'agit d'une période critique au cours de laquelle des données précieuses peuvent être compromises, la confiance est perdue et la productivité des développeurs est gaspillée, ce qui réduit la vitesse de publication du code et, en fin de compte, augmente la dette technique avec des solutions rapides ou des correctifs bâclés en raison d'un manque de connaissances ou de confiance dans les solutions déployées.

Secure Code WarriorLes intégrations d'AppSec offrent des conseils de remédiation fiables, permettant aux développeurs de résoudre les bogues de sécurité en toute confiance tout en restant dans le flux. En permettant aux développeurs de s'approprier la remédiation à la source, l'AppSec peut se concentrer sur la surveillance des risques et le renforcement de la posture de sécurité de l'organisation. 

Grâce aux conseils contextuels de codage sécurisé intégrés aux éléments de travail, les développeurs bénéficient d'une aide immédiate pour en savoir plus sur les vulnérabilités détectées et sur la manière de les corriger, ce qui permet de réduire le temps de réponse moyen, tout en offrant des résultats d'apprentissage précieux et collants qui réduisent de manière proactive les vulnérabilités à la source, c'est-à-dire dans le code.

Développez l'apprentissage au sein de vos équipes 

Intégration SCORM LMS

SCORM signifie Sharable Content Object Reference Model et est une norme internationale pour l'e-courses. Si votre cours est publié dans le format SCORM, vous pouvez être sûr que presque tous les systèmes de gestion de l'apprentissage (LMS) le reconnaîtront. Avec SCORM, vous pouvez facilement gérer un programme de formation au code sécurisé en même temps que vos autres plates-formes de formation en un seul endroit.

Vérifier l'efficacité avant d'expédier le code 

Secure Code Warrior Connector for Okta Workflows permet d'empêcher l'introduction de code non sécurisé dans votre base de code grâce à la puissance d'un contrôle des compétences en matière de sécurité qui peut être intégré à votre flux. Lorsque vous travaillez sur des bases de code, comme dans un dépôt GitHub, vous pouvez définir des leçons et des évaluations obligatoires comme critères de qualification pour coder dans la base. Cela permet à vos responsables de s'assurer que chaque développeur est prêt à travailler dans la base de code concernée, ce qui contribue à améliorer la posture de sécurité de l'ensemble de l'organisation. 

Introduisez la sécurité dans l'ensemble du cycle de vie du développement logiciel en veillant à ce que chaque développeur ait acquis les compétences nécessaires en matière de codage sécurisé pour obtenir un accès au répertoire afin de valider le code. Cette intégration garantira que les développeurs apprennent les dernières pratiques en matière de sécurité grâce à la plateforme très attrayante de SCW et que certains des fardeaux des révisions de code manuelles sont réduits, libérant ainsi des heures d'ingénierie pour livrer plus de fonctionnalités sans sacrifier la qualité.

Pour en savoir plus sur Okta + SCW ou pour voir la démo, cliquez ici. 

Soutien juste à temps lors de la validation du code

SCW pour GitHub permet une formation contextuelle à l'intérieur des flux de travail GitHub, soit dans les fichiers SARIF, soit directement dans les problèmes et les demandes d'extraction sur lesquels ils travaillent. Les développeurs ont ainsi accès aux connaissances au moment où ils en ont le plus besoin, ce qui leur permet de livrer plus rapidement un code de qualité. Cette intégration ne se contente pas de permettre l'application d'un correctif qui est souvent appliqué sans compréhension. Elle renforce continuellement les bons modèles de codage sécurisés afin de permettre une reconnaissance rapide du code vulnérable. 

En savoir plus sur SCW+GitHub ou voir la démo

Les conseils pratiques en matière de codage sécurisé intégrés dans GitLab int ègrent des liens de formation Secure Code Warrior très pertinents dans la section "Vulnerability Details" des rapports sur les vulnérabilités. Cela permet en fin de compte de réduire le délai entre l'apprentissage et l'application des connaissances afin de garantir une utilisation future en activant cette intégration. Par exemple, si les scanners de vulnérabilité détectent un Cross-Site Request Forgery (CSRF) dans le code de l'application, le détail de la vulnérabilité sera mis à jour avec le lien de formation correspondant.

"En offrant l'apprentissage contextuel étendu de Secure Code Warriorsur le codage sécurisé dans notre plateforme, nous allons permettre aux développeurs d'adopter la sécurité dès le départ et non seulement leur faire gagner du temps, mais aussi les aider à développer de nouvelles compétences". - Nima Badiey, vice-président de GitLab

En savoir plus sur SCW + GitLab

L'intégration de Synopsys Seeker permet d'incorporer dans Seeker des ressources, des vidéos et des liens de formation Secure Code Warrior pour les découvertes de vulnérabilités. Cela garantit la conformité avec les normes et réglementations industrielles grâce à un micro-apprentissage qui identifie et résout les vulnérabilités à l'aide de conseils de formation facilement accessibles dans Seeker. 

En savoir plus sur Synopsys + SCW

Aide à l'intérieur d'un billet quand vous en avez besoin maintenant 

Ne vous contentez pas de trouver des failles de sécurité, obtenez de l'aide pour les corriger avec Secure Code Warrior pour Jira . Les développeurs reçoivent une formation contextuelle directement dans leur Jira Issue Tracker, ce qui leur permet d'accéder à des connaissances au moment où ils en ont le plus besoin afin de les aider à produire plus rapidement un code de qualité. Secure Code Warrior for Jira détecte les détails de ces problèmes et donne aux développeurs la possibilité d'apprendre à les résoudre en accédant à des vidéos de formation spécifiques dans l'environnement qui leur est familier. Grâce au micro-apprentissage contextuel, les équipes de développement peuvent réduire les vulnérabilités dans l'ensemble de la base de code et en garder la maîtrise grâce au suivi et à la création de rapports via Jira.

En savoir plus sur SCW + Jira

Écrire du code sécurisé à toute vitesse

Secure Code WarriorLes intégrations de la pile de technologies de l'entreprise permettent un micro-apprentissage et une remédiation plus rapide grâce à des conseils et des solutions fiables pour les vulnérabilités les plus courantes. 

• Les liens vers les formations sont joints en tant que commentaires dans les problèmes et les demandes d'extension afin que les conseils soient facilement accessibles en cas de besoin.

• Le contenu est très pertinent et recherché sur la base des références du Common Weakness Enumeration (CWE) ou de l'Open Web Application Security Project (OWASP). 

• La couverture étendue signifie que les ressources d'apprentissage proviennent de la plus grande collection de formations en codage sécurisé au monde. 

Les vulnérabilités courantes, dont beaucoup sont connues depuis des décennies, continuent de persister dans le cadre du cycle de développement durable en raison de mesures réactives. Les outils d'analyse et le pentesting ne font que détecter le problème, et souvent après que l'application a déjà été mise en production. Ils sont notoirement lents - ils font apparaître de nombreux faux positifs et négatifs nécessitant un examen manuel - et s'attaquent rarement à la cause du problème ou à sa source.

L'autonomisation et l'habilitation de vos développeurs grâce au micro-apprentissage et aux conseils de remédiation au sein de leurs flux de travail les aident à détecter les faiblesses de sécurité plus tôt dans le processus de développement avant qu'elles ne deviennent coûteuses ou, pire encore, qu'elles ne laissent des vulnérabilités qui peuvent être exploitées plus tard. Les intégrations Secure Code Warrior rencontrent vos développeurs là où ils travaillent et les aident non seulement à trouver et à corriger les vulnérabilités plus rapidement, mais aussi à apprendre par la pratique à partir de ressources fiables et de conseils en petits morceaux afin d'améliorer leurs compétences et de renforcer la sécurité en tant que composante essentielle du cycle de vie du développement de logiciels. 

Vous souhaitez en savoir plus ? 

• Regardez nos webinaires "Product Talk" pour découvrir toutes nos intégrations passionnantes au SCW.
• Découvrez la démo d'Okta 
• Regardez la démo pour GitHub
• Essayez Secure Code Warrior gratuitement 

De nos jours, presque toutes les équipes de développeurs ont recours à une forme ou une autre de formation à la conformité, que ce soit dans le cadre d'un processus de certification initiale visant à garantir qu'une entreprise reste dans les limites des cadres sectoriels ou des réglementations gouvernementales, ou dans le cadre d'une exigence ou d'un examen annuel. Il s'agit d'une étape importante, car si une organisation n'est pas en mesure de respecter les exigences de base en matière de conformité, ses employés ne peuvent pas accomplir leurs tâches de manière réaliste.

Les règles de conformité existent pour une raison, car toute personne travaillant dans le domaine couvert par ces règles doit avoir au moins une compréhension fondamentale de tous les processus et procédures pertinents, ainsi que de toutes les lois applicables.

Bien que la formation à la conformité soit importante, le fait de remplir les exigences minimales prescrites ne garantit pas une véritable sécurité des applications. C'est particulièrement vrai pour les développeurs qui tentent d'intégrer des compétences de codage sécurisé dans leur flux de travail quotidien. Presque tous les développeurs suivent une formation à la conformité sous une forme ou une autre et pourtant, lorsqu'ils ont été interrogés, 67 % d'entre eux ont admis qu'ils laissaient souvent des vulnérabilités dans leur code.

Pourquoi ?

Pour la deuxième année, Secure Code Warrior a mené l'enquête "The state of developer-driven security survey, 2022" en partenariat avec Evans Data Corp en décembre 2021. Nous avons interrogé 1 200 développeurs dans le monde entier pour 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 dans le cycle de vie du développement logiciel (SDLC).

Quant à savoir pourquoi la formation à la conformité ne permet pas d'améliorer la sécurité des logiciels, c'est une question dont nous parlons depuis longtemps. L'enquête récente ne fait que mettre en lumière ce problème.

D'une part, on demande aux développeurs d'assumer de nouveaux rôles en intégrant la cybersécurité tout au long du processus de développement des logiciels, y compris lors de la rédaction initiale du code des applications et des programmes. Mais il n'est pas facile d'écrire un code sécurisé, ni même de s'informer sur les problèmes de cybersécurité et les vulnérabilités qui pourraient l'affecter. 63 % des développeurs interrogés dans le cadre de l'enquête ont déclaré que l'écriture d'un code sécurisé était une tâche difficile.

La difficulté d'écrire un code sécurisé n'est pas une surprise. Ce n'est pas pour rien que tant d'emplois bien rémunérés dans le domaine de la cybersécurité ne sont pas pourvus, avec plus de 3,5 millions de postes à pourvoir dans le monde au dernier recensement. Si le travail était facile, tout le monde se lancerait dans ce domaine. Il est difficile d'apprendre à combattre les menaces et à éliminer les vulnérabilités dans le code, et le paysage des menaces est en constante évolution. Les formations statiques sur la conformité ou les cours ponctuels ne peuvent pas suivre ou fournir le type d'éducation dont les développeurs ont besoin. Elles peuvent certes cocher une case en termes de conformité, mais ne peuvent pas fournir de véritables garanties de sécurité des applications pour votre organisation, ni permettre aux développeurs d'écrire un code sécurisé ou d'acquérir les compétences nécessaires pour trouver et corriger les vulnérabilités du code.

Les formations à la conformité et à la sécurité sont importantes, mais différentes

Les organisations doivent commencer à réaliser et à reconnaître ce que la formation en matière de conformité peut faire, et ce qu'elle ne peut pas faire. N'abandonnez pas la formation à la conformité, surtout si elle est imposée par la loi. Et surtout parce que (même avec les méthodes de formation actuelles) 92 % des personnes interrogées ont déclaré qu'elles avaient besoin d'au moins une formation sur les questions de conformité ou les cadres de sécurité, 50 % d'entre elles soulignant la nécessité d'une formation importante en matière de conformité.

Les cadres de conformité avec lesquels ils souhaitent le plus se former sont ceux qui sont spécifiques à divers secteurs, bien que plusieurs cadres généraux de cybersécurité figurent également sur la liste. Il s'agit notamment du cadre de sécurité CIS, de PCI DSS, du Top 10 de l'OWASP, de MISRA C, d'ISO/IEC, de la loi sur la portabilité et la responsabilité en matière d'assurance maladie (HIPAA) et d'autres encore.

Alors oui, formez-vous à ces cadres, mais comprenez que le fait de cocher une case sur la formation à la conformité n'équivaut pas à fournir une base pour la création continue d'un code sécurisé.

Au lieu de cela, considérez la formation à la conformité comme une opportunité permanente de développer les compétences de codage sécurisé de vos développeurs, qui peuvent être répétées en dehors du cycle de conformité, afin qu'ils puissent créer et publier des logiciels sécurisés tous les jours. La priorité n'est plus d'assurer la conformité, mais de permettre aux équipes de développement de coder en toute sécurité grâce à l'apprentissage continu. En investissant du temps et des ressources dans l'habilitation des développeurs, les exercices ou examens annuels de conformité deviendront un jeu d'enfant pour votre personnel, qui bénéficiera d'une productivité globale accrue.

Comment pouvez-vous passer à une sécurité axée sur les développeurs ?

Les développeurs ont massivement déclaré que la formation était utile, mais se sont opposés au type de formation qu'ils ont reçu en matière de codage sécurisé au fil des ans. Les développeurs ont déclaré qu'ils souhaitaient que l'on mette davantage l'accent sur une formation pratique utilisant des exemples du monde réel en rapport avec leur travail (30 %). Une plus grande interactivité a également été jugée essentielle par 26 % des personnes interrogées, en particulier si elles pouvaient s'entraîner à écrire du code sécurisé dans le cadre de ces exercices.

Pour 23 % des développeurs interrogés, il est important de recevoir une formation plus guidée, axée sur les vulnérabilités spécifiques qu'ils sont le plus susceptibles de rencontrer dans leur industrie ou leur secteur, tandis que 22 % d'entre eux souhaitent voir davantage d'exemples de vulnérabilités réelles dans leur formation ( courses).

Il est clair qu'une formation statique et non interactive (comme c'est généralement le cas pour la formation à la conformité) n'a que peu de valeur en termes de compétences reproductibles en matière de sécurité pour les développeurs. Les organisations devraient plutôt se concentrer sur des éléments tels que la formation juste à temps, où les développeurs sont formés à la sécurité au fur et à mesure qu'ils travaillent. Vous pouvez même envisager de mettre en œuvre un programme d'apprentissage à plusieurs niveaux.

Dans le cadre d'une approche par niveaux, les sujets plus vastes sont généralement décomposés en expériences ou concepts d'apprentissage distincts. Au fur et à mesure que les développeurs progressent, des concepts plus avancés sont superposés à ceux déjà maîtrisés, tout comme un échafaudage physique est construit au fur et à mesure qu'un bâtiment s'élève. Il s'agit d'une méthode éprouvée pour enseigner un sujet difficile et en constante évolution comme la cybersécurité, en le décomposant d'abord en morceaux plus petits et moins complexes, puis en construisant des éléments plus complexes sur cette base.

Quelle que soit la manière dont vous décidez d'aborder votre programme de compétences en matière de sécurité des développeurs, il est essentiel de le séparer des exercices de conformité. Les formations à la conformité et à la sécurité sont toutes deux importantes et nécessitent des approches différentes pour être couronnées de succès.

Pour en savoir plus

Livre blanc : Les défis (et les opportunités) pour améliorer la sécurité des logiciels.

Livre blanc : L'approche préventive de la sécurité des logiciels par les développeurs.

Rapport : L'état de la sécurité pilotée par les développeurs.

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

‍

Il y a quelques années, nous avons beaucoup parlé du fait que la cybersécurité était le Far West, et qu'il était désespérément nécessaire que davantage de personnes s'intéressent à ce sujet en général, sans parler du risque très réel que de nombreuses cyberattaques pouvaient représenter pour la vie. 

En 2023, il est agréable de constater que des progrès ont été réalisés, en particulier au niveau des gouvernements de nombreuses nations influentes. Pour nous, cependant, le voyage vers un code véritablement sécurisé et des logiciels plus sûrs est sans fin. L'avènement de la coqueluche numérique du moment - le métavers - ajoute une vaste surface d'attaque tant pour les vulnérabilités au niveau du code que pour l'ingénierie sociale.

Et nous ne sommes tout simplement pas prêts à nous battre sur ce nouveau terrain de jeu qui se nourrit de poudre aux yeux.

La réalité mixte s'accompagne d'un risque accru

Malgré son statut actuel de saveur du mois, le concept de métavers existe depuis longtemps. La plateforme en ligne Second Life existe depuis 2003 et sert une niche fidèle avec un univers en ligne entièrement personnalisable où les avatars des utilisateurs interagissent par chat vocal et textuel, où l'on peut jouer à des jeux et où des entreprises comme Adidas proposent des magasins virtuels officiels. Du côté du jeu pur, les jeux massivement multijoueurs en ligne (MMO) comme Fortnite et World of Warcraft offrent des mondes expansifs à leurs joueurs et dépendent de plus en plus des microtransactions, c'est-à-dire de l'argent réel à débourser pour obtenir des objets virtuels. À lui seul, Fortnite a réalisé 4,3 milliards de dollars de recettes de microtransactions au cours de ses deux premières années sur le marché. 

Il est très clair que non seulement le concept de métavers est là pour durer, mais qu'il est également sur le point d'avoir une poussée de la taille de Mark Zuckerberg dans le courant dominant. Il s'agit d'une évolution passionnante de l'internet - ou du moins des médias sociaux et d'une partie du commerce électronique - tel que nous le connaissons, mais les possibilités de cyberattaques et d'exploits préjudiciables sont époustouflantes. 

La surface d'attaque du métavers est d'une grande portée, s'étendant bien au-delà des logiciels basés sur le web, des API et des passerelles de paiement. Les éléments périphériques des casques et accessoires de RV constituent également une menace pour les données de base, les logiciels embarqués dans ces appareils constituant un tapis rouge très pratique pour se faire repérer s'ils sont vulnérables. 

Des chercheurs en sécurité de l'université Rutgers ont dévoilé "Face-Mic" au début de l'année. Il s'agit de la première étude de ce type qui examine comment les fonctions de commande vocale des casques de réalité virtuelle pourraient entraîner de graves atteintes à la vie privée, connues sous le nom d'"attaques par écoute". Les travaux sont fascinants, car ils montrent que des acteurs menaçants pourraient potentiellement utiliser certains casques de réalité virtuelle (AR/VR) dotés de capteurs de mouvement intégrés pour enregistrer des gestes faciaux associés à la parole, ce qui pourrait entraîner le vol d'informations sensibles communiquées par le biais de commandes vocales, notamment des informations sur les cartes de crédit et des mots de passe. La cause première du problème semble être un manque d'authentification de l'utilisateur. L'accéléromètre et le gyroscope ne nécessitant aucune autorisation d'accès, les mouvements faciaux complexes, les vibrations osseuses et aériennes pourraient être enregistrés et utilisés pour déduire toutes sortes d'informations, des codes PIN bancaires aux dossiers médicaux hautement confidentiels, en fonction des habitudes de l'utilisateur. 

Dans le métavers, chacun de vos mouvements est un point de données, et si l'accès à ces données est possible grâce à une sécurité logicielle laxiste, les attaquants ont tout intérêt à tenter leur chance. 

Les contrats intelligents face à des adversaires intelligents

La méta-économie exige la décentralisation, la dématérialisation, la flexibilité et, bien sûr, une sécurité sans compromis. À l'heure actuelle, des microéconomies métaverses se développent dans diverses communautés de crypto-monnaies, comme Shiba Inu. Pour acheter des biens immobiliers virtuels et d'autres produits intangibles, on utilise des contrats intelligents stockés sur la blockchain.

Si vous mentionnez "blockchain", la plupart des gens ordinaires (avec un peu de connaissances techniques) y voient un système sécurisé et anonyme pour ce qui est considéré comme l'avenir de la monnaie numérique. Il y a cependant un petit problème : aucune forteresse en ligne n'est impénétrable, et ces contrats intelligents ne font pas exception. Il s'agit essentiellement de petits programmes qui peuvent être piratés.

Les contrats intelligents sont susceptibles d'être exploités grâce à quelques vulnérabilités assez courantes, à savoir le débordement et le débordement d'entier, les attaques par rejeu et le bogue (très préjudiciable) centré sur la blockchain conduisant à des attaques par réentrance, cette dernière pouvant conduire à l'épuisement du solde de crypto-monnaie stocké par l'utilisateur. Toutes ces attaques sont rendues possibles par de mauvais schémas de codage conduisant à des vulnérabilités exploitables, et par des principes de conception peu sûrs.

L'utilisation de cette technologie ne fera que se généraliser, mais dans l'état actuel des choses, nous aurons du mal à trouver suffisamment de développeurs sensibilisés à la sécurité pour garantir un métavers sûr et sans faille. Les organisations doivent comprendre l'ampleur de leur participation au métavers, en particulier si des données et des devises sont en jeu... et il est difficile d'imaginer un scénario où ce ne serait pas le cas.

Il s'agit d'un environnement non réglementé et vous êtes (encore) le produit.

Comme nous l'avons vu dans les films, la télévision, Second Life et les jeux vidéo, un environnement métavers nous permet d'être qui nous voulons. Dans un monde virtuel, les possibilités ne sont limitées que par votre imagination, et cette flexibilité est un atout majeur pour les utilisateurs. Cependant, l'inconvénient est qu'à l'échelle prévue d'un projet comme Meta, il est tout simplement trop vaste et trop décentralisé pour être contrôlé d'une manière qui le rendrait étanche du point de vue de la sécurité. Les escroqueries seront inévitables, et les criminels compétents auront encore plus de travail à faire du point de vue de l'ingénierie sociale. 

Les données sensibles des utilisateurs sont le nouvel or, et le métavers a le potentiel d'être la source de données la plus riche et la plus complète que nous ayons vue à ce jour, à condition que l 'adoption prévue se déroule comme prévu. Bien que l'on puisse supposer que les logiciels liés au métavers respecteront les normes réglementaires et les mesures de conformité actuelles, il faudra les mettre à jour pour qu'ils soient adaptés à l'univers numérique en expansion rapide et à son économie. Pour ce faire, les organisations devront assumer la responsabilité de la sécurité de leurs contributions au métavers, avec un niveau de maturité interne en matière de sécurité qui garantisse que chaque personne travaillant sur le logiciel réfléchit à la sécurité et la met en œuvre à chaque étape de son processus, en particulier dans la cohorte de développement. 

Pourquoi le codage sécurisé sera essentiel au succès du métavers

Aussi amusant que cela puisse être de galoper dans une dimension numérique sans foi ni loi, représenté par un avatar qui est tout ce que vous aimeriez être dans le monde réel, nous ne devons jamais oublier qu'un être humain se cache derrière chaque "personnage". Et lorsque les données et les finances de personnes réelles sont en jeu, on est très loin d'un jeu. 

En matière de cybersécurité, nous savons bien que les erreurs ont des conséquences qui peuvent être réellement dévastatrices, et l'intégrité de chaque élément du métavers ne peut être négligée si l'on veut que l'adoption à grande échelle et la confiance des consommateurs se concrétisent. 

Les organisations peuvent commencer à planifier dès maintenant en effectuant une évaluation réaliste de leur maturité en matière de sécurité ( assessment ), en mettant l'accent sur l'amélioration des compétences en matière de sécurité des développeurs qui travaillent activement sur les logiciels. Comme le montre l'étude de l'université Rutgers, le contrôle d'accès n'est qu'une vulnérabilité parmi d'autres qui peut conduire à une fuite généralisée de données, et les développeurs sensibilisés à la sécurité seraient bien mieux placés pour résoudre ces problèmes au moment de l'écriture du code, et bien avant qu'ils n'entrent dans le code validé. 

Se reposer sur l'excuse de la pénurie de compétences en cybersécurité ne servira à rien après une violation majeure de données dans le métavers, et nous avons les outils devant nous pour non seulement faire de notre mieux, mais aussi améliorer activement les normes de sécurité des logiciels pour de bon. Il est temps d'investir dans la formation des architectes du métavers et de récolter les bénéfices d'une réimagination virtuelle des produits et services tels que nous les connaissons.

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

‍

À un moment ou à un autre de sa carrière, chacun a probablement vu l'un de ces organigrammes opérationnels ou hiérarchiques qui définissent qui rend compte à qui au sein d'une organisation. Parfois simplement appelé organigramme, il s'agit d'un outil utile pour faire savoir aux gens qui travaillent pour eux et qui sont leurs patrons. Par exemple, dans un organigramme classique, le chef d'un groupe de codage peut rendre compte au directeur du développement des produits, qui lui-même rend compte au vice-président chargé de l'innovation. Les lignes d'autorité se poursuivent en amont et en aval de la structure de l'entreprise. Qui n'a jamais regardé l'un de ces organigrammes pour essayer d'y trouver son petit bloc personnel niché quelque part ?

Il n'est pas étonnant que les humains soient si fascinés par la hiérarchie et la structure. C'est ce qui nous a permis de survivre en tant qu'espèce pendant si longtemps, même dans les temps anciens où nous étions confrontés à un monde très dangereux. Nous n'avons jamais été les créatures les plus fortes ou les plus rapides, mais nous travaillions bien en équipe, chacun connaissant sa place et sa responsabilité dans le maintien de notre famille, de notre tribu ou de notre groupe, en vie et en plein essor. L'organigramme moderne est en fait un prolongement de cette époque et de cette réussite ancienne.

Mais il y a une chose que presque tous les organigrammes ont en commun, quelle que soit la taille de l'entreprise ou d'autres facteurs. La plupart du temps, tous les éléments de ces organigrammes représentent des êtres humains ou des groupes d'êtres humains. Nous n'en sommes pas encore au point où les machines sont capables de superviser les humains, de sorte que pour l'instant, les organigrammes sont une affaire exclusivement humaine. Mais nos logiciels ont-ils également besoin d'une hiérarchie organisationnelle ?

Bien entendu, je ne suggère pas d'ajouter un logiciel aux organigrammes de nos entreprises. Personne n'a envie d'avoir une application pour patron. Comment pourriez-vous lui demander une augmentation ? Mais le paysage des menaces auxquelles nos applications et nos programmes sont confrontés aujourd'hui n'est pas sans rappeler l'environnement dangereux auquel nos anciens parents humains étaient confrontés il y a bien longtemps. En aidant à définir les responsabilités de nos applications et logiciels au sein d'une hiérarchie étroite et en appliquant ces politiques avec le moins de privilèges possible, nous pouvons nous assurer que nos applications et logiciels survivent et prospèrent malgré le paysage de menaces dévastateur qui s'offre à eux.

Les attaques contre les applications et les logiciels atteignent un niveau record

Pour comprendre la nécessité de créer de meilleures hiérarchies organisationnelles pour les logiciels, il est important de comprendre d'abord le paysage des menaces. De nos jours, les attaquants, ainsi que les robots et les logiciels automatisés qui travaillent pour eux, sont constamment à l'affût de la moindre faille dans les défenses à exploiter. Alors que le phishing et d'autres attaques contre les humains sont toujours lancés, les pirates les plus habiles ont déplacé la majorité de leurs efforts vers l'attaque des logiciels.

Si tous les logiciels sont visés, les attaques les plus réussies concernent les interfaces de programmation d'applications (API). Ces API discrètes sont de minuscules éléments de logiciel utilisés par les développeurs pour effectuer toute une série de tâches, petites mais importantes, pour leurs applications et leurs programmes. Elles sont souvent flexibles et uniques, et parfois même créées à la volée selon les besoins du processus de développement.

Les API sont certainement flexibles, mais elles sont aussi souvent sur-autorisées par rapport à leurs fonctions. Les développeurs ont tendance à leur accorder de nombreuses autorisations afin qu'elles puissent, par exemple, continuer à fonctionner même si le programme qu'elles aident à gérer continue à se développer et à changer. Mais cela signifie que si un attaquant les compromet, il obtient bien plus que les droits d'accès, par exemple, à un morceau d'une base de données spécifique. Il peut même obtenir des droits de quasi-administrateur sur l'ensemble d'un réseau.

Il n'est donc pas étonnant que plusieurs sociétés de recherche en sécurité affirment que l'écrasante majorité des attaques par vol d'informations d'identification sont aujourd'hui perpétrées contre des logiciels tels que les API. Akamai estime que ce chiffre représente 75 % du total, tandis que Gartner affirme également que les vulnérabilités impliquant les API sont devenues le vecteur d'attaque le plus fréquent. Le dernier rapport de Salt Labs montre que les attaques contre les API ont augmenté de près de 700 % par rapport à l'année dernière.

Création d'un organigramme pour les logiciels

L'un des moyens utilisés par les organisations pour lutter contre les menaces de vol d'informations d'identification consiste à appliquer le principe du moindre privilège, voire de la confiance zéro, au sein de leurs réseaux. Cela limite les utilisateurs à recevoir juste assez d'autorisations pour accomplir leur travail ou leurs tâches. Cet accès est souvent limité par des facteurs tels que l'heure et le lieu. De cette manière, même si une attaque par vol d'informations d'identification réussit, l'attaquant n'en tirera pas grand-chose puisqu'il n'aura la permission d'exécuter que des fonctions limitées pendant une brève période.

Le principe du moindre privilège est une bonne défense, mais il ne s'applique normalement qu'aux utilisateurs humains. Nous avons tendance à oublier que les API détiennent également des privilèges élevés et qu'elles ne sont souvent pas aussi réglementées. C'est l'une des raisons pour lesquelles un contrôle d'accès défaillant est désormais l'ennemi public numéro un selon l'Open Web Application Security Project (OWASP), qui suit les schémas de cyberattaque. 

Il est facile de dire que la solution à ce problème critique consiste simplement à appliquer le principe du moindre privilège aux logiciels. Mais cette solution est beaucoup plus difficile à mettre en œuvre. Tout d'abord, les développeurs doivent être sensibilisés aux dangers. Ensuite, pour aller de l'avant, les API et autres logiciels doivent être officiellement placés, ou au moins envisagés, comme faisant partie d'un organigramme au sein du réseau informatique où ils résideront. Par exemple, si une API est censée saisir des données de vol en temps réel dans le cadre d'une application de réservation, il n'y a aucune raison pour qu'elle soit également capable de se connecter aux systèmes de paie ou de finance. Sur l'organigramme du logiciel, il n'y aurait pas de lignes directes ou même pointillées reliant ces systèmes.

Il est probablement irréaliste pour les développeurs de créer un organigramme montrant les milliers, voire les millions d'API fonctionnant dans leur entreprise. Mais le fait d'être conscient du danger qu'elles représentent et de limiter leurs autorisations au strict nécessaire pour faire leur travail contribuera grandement à mettre un terme aux attaques généralisées de vol d'informations d'identification auxquelles tout le monde est confronté ces jours-ci. Cela commence par une prise de conscience et se termine par le traitement des API et des logiciels avec la même attention que les utilisateurs humains.
‍

Vous souhaitez renforcer votre équipe de développement ? Résolvez les problèmes de sécurité des API et bien d'autres choses encore grâce à notre approche agiles Plateforme D'apprentissage agiles et axés sur les développeurs.

Les développeurs qui créent les logiciels, les applications et les programmes qui alimentent les activités numériques 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, ou sans accès 24 heures sur 24 à leurs sites web et autres infrastructures.

Pourtant, ces mêmes points de contact sont souvent la porte d'entrée que les pirates et autres utilisateurs malveillants utilisent pour voler des informations, lancer des attaques et passer à d'autres activités criminelles telles que la fraude et les ransomwares. Le dernier rapport Verizon Data Breach Investigations Report souligne que les menaces qui pèsent sur les entreprises et les organisations sont plus dangereuses et plus coûteuses aujourd'hui qu'à n'importe quel autre moment de l'histoire.

Les attaques réussies restent fréquentes, même si les dépenses de cybersécurité dans la plupart des organisations sont en nette augmentation, et même si des mouvements comme DevSecOps déplacent la sécurité vers les développeurs qui sont l'élément vital de l'entreprise aujourd'hui.

Les développeurs comprennent l'importance de la sécurité et souhaitent majoritairement déployer un code sûr et de qualité, mais les vulnérabilités des logiciels 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 survey, 2022 en partenariat avec Evans Data Corp en décembre 2021. Nous avons interrogé 1 200 développeurs dans le monde entier pour 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 dans le cycle de vie du développement logiciel (SDLC).

L'enquête a mis en évidence l'absence d'une définition claire ou d'une compréhension de ce qu'est 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 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 % d'entre eux déclarent que la pratique active de l'écriture d'un code exempt de vulnérabilités est une priorité. Au contraire, les développeurs associent des pratiques moins sûres et beaucoup moins fiables à la création d'un code sécurisé. Par exemple, l'examen minutieux du code existant (37 %) et le recours à des bibliothèques externes pour obtenir un code sûr (37 %) sont les principales pratiques que les développeurs associent au codage sécurisé. La réutilisation d'un code déjà jugé sûr (32 %) est un autre choix populaire. La pratique active consistant à écrire un code exempt de vulnérabilités arrive en 6e position, 29 % des répondants déclarant qu'il s'agit d'une pratique essentielle à la création d'un code sûr. Interrogés plus avant, les participants ont déclaré que le manque de temps et l'absence d'une approche cohérente de la part de la direction constituaient les principaux obstacles à la création d'un code sécurisé.

La dépendance à l'égard du code existant est l'un des facteurs qui augmentent le risque que les logiciels soient livrés avec des vulnérabilités exploitables. Pour que les développeurs puissent créer un code de qualité qui soit également sûr, il est nécessaire de se pencher sur la question de savoir ce qui constitue un code sûr.

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 est que la communauté des développeurs dans son ensemble est composée de professionnels qui se soucient de ce qu'ils font. L'écriture d'un code de qualité supérieure est pour eux, en tant que groupe, d'une importance capitale. 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 consacré suffisamment de ressources à la formation de leurs développeurs ou ne leur ont pas donné les moyens d'atteindre ces objectifs.

En fait, la plupart des développeurs ont déclaré que leur organisation ne disposait même pas d'une définition claire de ce qui constitue un code sécurisé. L'un des exemples les plus inquiétants est que 28 % des répondants à l'enquête ont déclaré que leur organisation considérait que le code était sécurisé si aucune violation n'était signalée une fois que l'application ou le 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, se contenter d'espérer de bons résultats sans y travailler réellement produira probablement des résultats prévisibles : encore plus d'atteintes à la sécurité.

Heureusement, il s'agit d'une situation où il est relativement facile d'au moins commencer à résoudre le problème, puis de commencer à travailler pour atteindre l'objectif d'un code sécurisé. La première étape, sans doute la plus importante, consiste pour les organisations à définir ce qu'elles considèrent comme du code sécurisé. Tout ce qui ne correspond pas à cette définition doit être considéré comme non sécurisé.

Le codage sécurisé devrait être défini comme la pratique de développeurs compétents qui écrivent un code exempt de vulnérabilités, dès le début du cycle de développement durable. Ce n'est qu'une fois cette pratique définie que la communauté des développeurs peut travailler à la réalisation de cet objectif.

Faire de l'objectif d'un 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 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 l'attention, de l'autorité et du budget nécessaires pour réussir.

Cela peut nécessiter de nouveaux objectifs de référence pour les développeurs, qui ont traditionnellement été évalués en fonction de la vitesse de leur codage. En fait, 37 % des développeurs interrogés dans le cadre de l'enquête ont déclaré avoir laissé des vulnérabilités connues dans leur code parce que les délais serrés ne leur laissaient pas le temps de les corriger ou de coder correctement dès le départ. Dans un premier temps, cela peut signifier qu'il faut augmenter les délais pour donner aux développeurs plus de temps pour coder correctement, mais cette perte de temps au début du processus de codage sera probablement compensée plus tard parce qu'il sera moins nécessaire de réviser les programmes, d'appliquer des correctifs et d'effectuer des travaux post-déploiement. En outre, l'élimination de la possibilité d'une violation dès son déploiement peut permettre d'économiser des centaines d'heures et éventuellement des millions en pertes de revenus, en amendes et en coûts 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 d'autant plus vrai que 36 % des personnes interrogées dans le cadre de l'enquête ont déclaré vouloir supprimer les vulnérabilités de leur code, mais ne pas avoir les compétences ou les 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 laissaient pas le temps de les corriger ou de coder correctement dès le départ.

Vous souhaitez en savoir plus sur ce sujet ?

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

Récemment, une équipe de chercheurs en sécurité a annoncé la découverte d'un bogue vieux de quinze ans dans la fonctionnalité d'extraction de fichiers tar de Python. La vulnérabilité a été divulguée pour la première fois en 2007 et répertoriée sous le nom de CVE-2007-4559. Une note a été ajoutée à la documentation officielle de Python, mais le bogue lui-même n'a pas été corrigé.

Cette vulnérabilité pourrait avoir un impact sur des milliers de projets logiciels, mais de nombreuses personnes ne sont pas familières avec la situation ou la façon de la gérer. C'est pourquoi, ici à Secure Code Warriornous vous donnons la possibilité de simuler vous-même l'exploitation de cette vulnérabilité afin d'en voir l'impact et d'acquérir une expérience pratique des mécanismes de ce bogue persistant, de sorte que vous puissiez mieux protéger votre application !

Essayez la mission simulée maintenant.

La vulnérabilité : traversée de chemin lors de l'extraction d'un fichier tar

La traversée d'un chemin ou d'un répertoire se produit lorsque des données utilisateur non analysées sont utilisées pour construire un chemin de fichier, ce qui permet à un pirate d'accéder à des fichiers et de les écraser, voire d'exécuter un code arbitraire. 

La vulnérabilité se trouve dans le module tarfile de Python. Un fichier tar (archive sur bande) est un fichier unique, appelé archive. Il regroupe plusieurs fichiers avec leurs métadonnées et est généralement reconnu par l'extension .tar.gz ou .tgz. Chaque membre de l'archive peut être représenté par un objet TarInfo, qui contient des métadonnées, telles que le nom du fichier, l'heure de modification, la propriété, etc.

Le risque provient de la capacité des archives à être extraites à nouveau.

Lors de l'extraction, chaque membre a besoin d'un chemin d'accès pour être écrit. Cet emplacement est créé en joignant le chemin de base au nom du fichier : 

Une fois ce chemin créé, il est transmis à la commande tarfile.extract ou tarfile.extractall pour effectuer l'extraction : 

Le problème réside dans l'absence de vérification du nom de fichier. Un attaquant pourrait renommer des fichiers pour y inclure des caractères de traversée de chemin, tels que le point, la barre oblique (../), ce qui amènerait le fichier à sortir du répertoire dans lequel il est censé se trouver et à écraser des fichiers arbitraires. Cela pourrait éventuellement conduire à l'exécution de code à distance, ce qui est propice à l'exploitation. 

La vulnérabilité apparaît dans d'autres scénarios, si vous savez comment l'identifier. Outre la gestion des fichiers tar par Python, la vulnérabilité existe dans l'extraction des fichiers zip. Vous la connaissez peut-être sous un autre nom, comme la vulnérabilité zip slip, qui s'est manifestée dans d'autres langages que Python !

LIEN VERS LA MISSION 

Comment pouvez-vous réduire les risques ?

Bien que la vulnérabilité soit connue depuis des années, les responsables de Python considèrent que la fonctionnalité d'extraction fait ce qu'elle est censée faire. Dans ce cas, certains diront qu'il s'agit d'une fonctionnalité et non d'un bogue. Malheureusement, les développeurs ne peuvent pas toujours éviter d'extraire des fichiers tar ou zip d'une source inconnue. C'est à eux qu'il incombe d'assainir les entrées non fiables pour éviter les vulnérabilités de traversée de chemin dans le cadre de pratiques de développement sécurisées.

Vous souhaitez en savoir plus sur la manière d'écrire du code sécurisé et de réduire les risques avec Python ?

Essayez gratuitement notre défi Python.

Si vous souhaitez obtenir d'autres directives de codage gratuites, consultez Secure Code Coach pour vous aider à rester au fait des pratiques de codage sécurisées.

‍

‍

Secure Code Warrior s'engage à contribuer à l'éducation de la communauté des développeurs et de la sécurité sur la façon d'écrire du code en toute sécurité et de réduire le risque de vulnérabilités introduites par du code non sécurisé. Dans le cadre de cet objectif, nous utiliserons l'histoire de l'incident de sécurité récent d'Uber comme une occasion de discuter de l'importance de la sécurité axée sur les développeurs et du changement de cap à gauche.

Incident de sécurité chez Uber

Uber a publié une déclaration sur l'incident de cybersécurité le 16 septembre et continue de l'actualiser. Les lecteurs doivent garder à l'esprit qu'il s'agit d'une affaire en cours. Récapitulons ce que nous avons appris jusqu'à présent grâce à la déclaration d'Uber et à d'autres articles réputés de la communauté de la sécurité. 

Le pirate a commencé par faire de l'ingénierie sociale auprès d'un employé d'Uber, après avoir trouvé son numéro de What'sApp. Le pirate l'a contacté et a commencé à l'hameçonner en lui demandant de se connecter à un faux site Uber, puis de saisir son nom d'utilisateur et son mot de passe. 

Les comptes Uber sont protégés par l'authentification multifactorielle (MFA), ce qui signifie qu'en plus de son mot de passe, l'utilisateur doit présenter un deuxième élément de preuve confirmant son identité. Dans la plupart des cas, il s'agit d'un message envoyé à un appareil mobile. 

Après avoir obtenu les informations d'identification, l'attaquant a lancé une attaque de fatigue MFA en essayant continuellement de se connecter au site authentique d'Uber et en submergeant l'employé avec de nombreuses notifications push sur son appareil. L'attaquant a de nouveau contacté la victime via WhatsApp. Cette fois, il s'est fait passer pour le service d'assistance informatique et a réussi à convaincre la victime d'accepter.

Informations d'identification codées en dur

La faille de sécurité d'Uber est due à une attaque d'hameçonnage réussie. Une fois à l'intérieur, l'intrus a trouvé des partages de réseau contenant des scripts PowerShell. L'un de ces scripts contenait les identifiants codés en dur d'un utilisateur administrateur, ce qui a conduit à la compromission des services internes d'Uber, tels que AWS, G-Suite et les référentiels de code. Le pirate a également eu accès au compte HackerOne d'Uber. Selon Uber, "tous les rapports de bogues auxquels l'attaquant a pu accéder ont été corrigés".

Curieux de voir à quoi ressemblerait cette vulnérabilité dans le code ? Essayez gratuitement notre défi PowerShell.

Quelle est la fréquence de ces types d'attaques ?

Il est difficile de se défendre contre l'ingénierie sociale en tant que vecteur d'attaque, car le facteur humain a toujours été considéré comme la partie la plus faible de la cybersécurité. Le piratage d'Uber a clairement illustré le fait que les implémentations MFA peuvent facilement être contournées. Pour éviter cela, il est essentiel de sensibiliser les employés au fonctionnement des attaques par hameçonnage. 

Ce qui a causé l'exposition des services internes d'Uber, cependant, c'est le nom d'utilisateur et le mot de passe de l'administrateur qui ont été trouvés dans un script PowerShell. Il n'est jamais bon de coder en dur des informations d'identification, car elles deviennent lisibles par n'importe quel développeur et, en fait, par toute personne ayant accès au code. 

Mais là encore, la sensibilisation est essentielle ! Les développeurs qui ont un état d'esprit axé sur la sécurité sont plus susceptibles de repérer les vulnérabilités et moins susceptibles de les écrire.

Une double approche, à savoir une formation générale sur l'ingénierie sociale et, plus spécifiquement, une formation proactive au codage sécurisé, réduira le nombre de vulnérabilités dans une base de code et s'avérera donc essentielle dans la lutte contre les menaces à la sécurité.

Vous voulez en savoir plus sur les meilleures pratiques en matière de codage sécurisé ? Consultez Secure Code Coach. Vous pouvez y apprendre les lignes directrices en matière de codage sécurisé et tester gratuitement des exercices de formation.