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.  

Le monde évolue rapidement, quelle que soit l'entreprise ou le produit, les choses sont de plus en plus numériques et dépendantes des logiciels. Les développeurs fournissent du code plus rapidement que jamais, mais 75 % du code est encore vérifié et signalé par les équipes AppSec pour des vulnérabilités courantes et facilement évitables. 

Il y a d'énormes risques à ne pas donner la priorité à un code sécurisé et à la sécurité en tant qu'élément essentiel du processus de développement de logiciels. En fait, le coût moyen mondial d'une violation de données a augmenté l'année dernière pour atteindre 4,35 millions de dollars(IBM Cost of a Data Breach Report 2022). Les développeurs ont besoin d'une formation attrayante et innovante pour se tenir au courant des nouvelles menaces et d'un changement de culture pour faire évoluer l'état d'esprit axé sur la sécurité, en partenariat avec l'équipe de sécurité.

Chez Secure Code Warrior, nous innovons constamment pour aider les développeurs et les organisations à acquérir les compétences nécessaires pour relever les défis actuels en matière de sécurité, qui sont en constante évolution. Nous y parvenons grâce à des programmes de formation très attrayants, flexibles et faciles à gérer. 

Au cours du dernier trimestre, nous nous sommes concentrés sur la création de nouvelles méthodes d'apprentissage avec Coding Labs (nouvellement disponible en avant-première), nous avons activé une intégration LMS SCORM, et nous avons créé des expériences utilisateur plus accessibles et inclusives - tout en simplifiant l'expérience de l'administrateur pour aider à gagner du temps. 

Plongeons dans l'histoire pour en savoir plus !

Annonce de Coding Labs - Apprentissage de haut niveau

Dans une récente enquête sectorielle(The State of Developer-Driven Security Report 2022), 40 % des développeurs ont déclaré que leur formation n'était pas assez pratique. Coding Labs aide les développeurs à améliorer leurs compétences en matière de codage sécurisé grâce à une formation pratique avec un codage réel et un retour d'information intuitif, le tout dans le cadre d'un IDE familier et puissant intégré au navigateur, ce qui facilite plus que jamais le passage de l'apprentissage à la pratique.

Au lieu d'être confrontés à des conseils peu clairs et frustrants du type "bon ou mauvais", les développeurs peuvent également être sûrs d'apprendre de la bonne manière et d'améliorer leur compréhension grâce à un retour d'information en temps réel et en contexte. Coding Labs soutient les objectifs des développeurs en matière de prévention des failles de sécurité et d'amélioration de la posture de sécurité de leur organisation.

Faisant partie de la plateforme SCW, cette nouvelle expérience apporte une nouvelle perspective à la formation des développeurs. Les responsables peuvent élaborer un programme de formation qui prépare les développeurs à la réussite, grâce à un apprentissage accessible et de petite taille qui répond aux besoins du développeur là où il se trouve. Accompagnez les développeurs à travers une nouvelle vulnérabilité grâce à une formation guidée abordable qui vous permettra de progresser vers des expériences plus difficiles et plus pratiques telles que les Coding Labs. Les dirigeants peuvent être sûrs que les développeurs trouveront la formation plus attrayante, plus facile à retenir et qu'ils l'appliqueront finalement à la base de code afin de réduire les vulnérabilités et le travail de révision. 

Coding Labs est désormais disponible en avant-première. Si vous êtes client de SCW, contactez votre gestionnaire de compte pour en savoir plus sur l'accès.

Vous n'êtes pas client de SCW mais vous souhaitez rester informé des disponibilités de Coding Labs ? Remplissez le formulaire ici.

Rejoignez SCW pour découvrir les innovations de nos produits et assister à une démonstration de Coding Labs. Inscrivez-vous au webinaire ici.

Intégrez la formation au code sécurisé à votre LMS SCORM préféré 

Prochainement, les administrateurs du SCW pourront gérer plus facilement leur programme de formation au code sécurisé en même temps que leurs autres plateformes de formation, sans effort de développement manuel. Cela permettra de gagner du temps et aidera les administrateurs à se concentrer sur des moyens plus efficaces d'améliorer leurs programmes de formation. 

Si vous ne connaissez pas, SCORM signifie Sharable Content Object Reference Model et est une norme internationale pour l'e-courses. Si votre cours est publié au format SCORM, vous pouvez être sûr que presque tous les systèmes de gestion de l'apprentissage (LMS) le reconnaîtront.

Avec la nouvelle intégration SCORM LMS, vous pouvez :

• Incorporez la formation par code sécurisé directement dans votre LMS préféré pour gérer les participants et les affectations en un seul endroit.
• Suivre les progrès et les réalisations de votre organisation

‍

Veillez à ce que votre programme SCW soit intégré directement dans le flux de travail de vos développeurs préférés afin d'améliorer l'expérience des utilisateurs. Des paquets SCORM peuvent être téléchargés pour Courses et les évaluations, fournissant une intégration LMS transparente avec des plateformes populaires telles que SAP SuccessFactors, Workday, Cornerstone, et plus encore.

L'intégration LMS SCORM sera disponible pour les clients en avant-première en octobre, contactez votre gestionnaire de compte pour en savoir plus. 

Élargir la portée et la profondeur de la plateforme SCW 

Secure Code WarriorL'expansion continue de notre contenu nous aide à maintenir nos modules pertinents, opportuns et adaptés à ce que vous devez savoir dans le paysage de la cybersécurité d'aujourd'hui. Grâce à l'étendue et à la profondeur de plus de 55 langages, il est facile de construire et d'étendre un programme pour former les développeurs dans un grand nombre de langages et de frameworks. 

Sécurisez vos applications ABAP grâce à un nouveau contenu de formation

Dans le prolongement de notre version du printemps, nous sommes ravis de lancer de nouvelles méthodes de formation pour les développeurs qui codent en ABAP, avec 6 nouveaux guides et 14 sites missions.

Accéder à une éducation flexible et diversifiée avec de nouveaux défis et de nouveaux contenus 

Secure Code Warrior s'efforce de publier en permanence des contenus qui répondent aux différents niveaux de compétences tout en maintenant nos modules de formation pertinents et stimulants. Ce trimestre, SCW a publié plus de contenu sur les langages de codage populaires tels que :

• 33 défis RPG supplémentaires, une des principales demandes des clients
• La possibilité de créer un site tournaments dans le RPG  
• 10 défis Python Django supplémentaires

Tout le nouveau contenu est maintenant disponible dans les pools de défis à jouer sur la plateforme.

Simplifier l'expérience de l'administrateur et de l'utilisateur

La configuration d'un programme de formation au code sécurisé évolutif et engageant est désormais plus facile que jamais grâce à des améliorations clés de la convivialité de la plateforme.

Modifier facilement un cours publié 

Suivez l'évolution constante des besoins de votre organisation et de votre programme de formation grâce à de nouvelles méthodes de modification des programmes existants. La gestion des versions de cours permet aux administrateurs de modifier leurs courses existants sans avoir à créer un nouveau cours. Il s'agit de l'une des fonctionnalités les plus demandées par les clients.

Les mises à jour comprennent

• Ajouter de nouvelles langues à un cours publié
• Ajouter/mettre à jour/supprimer des modules et du contenu d'activité dans le cours 
• Ajouter/mettre à jour/supprimer des activités de fin de cours 
• La plateforme enregistrera une version majeure d'un cours pour créer un versionnage de base. 

Accédez à Courses depuis l'écran d'accueil

L'ajout d'un bouton "Continuer" sur la nouvelle page d'accueil permet d'afficher une liste de fiches d'activité pour aider les utilisateurs à reprendre rapidement les modules qu'ils ont déjà commencés. Les utilisateurs peuvent également voir une fenêtre sur l'écran d'accueil pour visualiser les modules non terminés.

Cela permet aux utilisateurs de reprendre là où ils se sont arrêtés s'ils doivent interrompre un cours ou se rendre sur le site assessment, sans perdre leurs progrès.

‍

Ces deux fonctionnalités sont disponibles pour les comptes qui ont activé l'accès anticipé sur la plateforme. Contactez votre gestionnaire de compte pour toute question concernant l'accès.

Conception inclusive et accessible 

Sur Secure Code Warrior, nous pensons que le langage et la conception ont le pouvoir de jeter des ponts et d'améliorer la compréhension, en réunissant divers groupes d'utilisateurs dans le cadre de notre mission de défense de la sécurité du codage. Notre objectif est de créer et de fournir une expérience inclusive et accessible, et nous sommes enthousiastes à l'idée de faire des progrès continus en matière de conception accessible.

Le chinois traditionnel est désormais disponible 

Avec l'ajout du chinois traditionnel aux langues de la plateforme, nous continuons à construire une communauté véritablement mondiale de développeurs qui peuvent accéder aux outils dont ils ont besoin pour devenir des champions de la sécurité. 

Vous pouvez accéder aux langues à partir du menu déroulant dans les paramètres. Le chinois traditionnel est également disponible avec des sous-titres vidéo dans notre section ressources.

Participez au webinaire ProductTalk le 5 octobre 2022. 

Vous souhaitez en savoir plus ? Rejoignez notre webinaire ProductTalk le 5 octobre 2022 pour entendre les membres de nos équipes produits parler de mises à jour passionnantes et de nouvelles fonctionnalités, et découvrir l'évolution du paysage de la sécurité axée sur les développeurs. 

Inscrivez-vous au webinaire ici.

Vous souhaitez essayer Secure Code Warrior mais vous n'avez pas encore de compte ? Inscrivez-vous pour un compte d'essai gratuit dès aujourd'hui pour commencer.

Voilà pour les nouvelles fonctionnalités de ce trimestre ! Suivez Secure Code Warrior sur Twitter pour être tenu au courant des dernières versions et améliorations.

Dans le climat économique et le paysage des menaces actuels, je n'envie certainement pas le RSSI moyen. Il est chargé d'assurer la sécurité, la conformité, l'innovation et la valeur de l'entreprise, tout en étant confronté à des budgets réduits et à une surveillance accrue. Ce qui est peut-être encore plus urgent, c'est que chaque organisation (et son équipe de développement) se trouve à des stades différents de maturité en matière de sécurité, et que toutes ne sont pas équipées pour donner le meilleur d'elles-mêmes en termes de cyberdéfense. 

Ces dernières années, les incidents de cybersécurité se sont multipliés et il est devenu difficile pour les responsables de la sécurité de garder une longueur d'avance. Il suffit de jeter un coup d'œil sur les données qui nous renseignent sur notre situation de plus en plus difficile pour se rendre compte qu'il s'agit d'une véritable poudrière : plus de 33 milliards d'enregistrements seront volés par des cybercriminels rien qu'en 2023, ce qui représente une augmentation de 175 % par rapport à 2018. Le coût de la cybercriminalité devrait atteindre 10 500 milliards de dollars d'ici 2025, et le coût moyen d'une violation de données est monté en flèche pour atteindre 4,24 millions de dollars (bien qu'il suffise d'examiner des incidents tels qu'Equifax ou Solar Winds pour constater que la situation peut être bien pire). 

En tant qu'industrie, nous avons longtemps attendu qu'un héros vienne nous sauver des méchants de la cybersécurité qui semblent détenir plus de pouvoir que nous ne l'aurions cru possible, même il y a dix ans. Nous attendons qu'un plus grand nombre de professionnels de la cybersécurité se joignent à nous et nous hissent à un niveau plus élevé de programme de sécurité, mais c'est un fossé que nous n'arrivons pas à combler. Nous attendons la solution miracle qui promet de nous éloigner automatiquement des risques croissants, mais elle n'existe pas et il est très peu probable qu'elle existe. Nous attendons que notre Luke Skywalker nous aide à combattre le côté obscur.

Il s'avère que l'aide (et l'espoir) est en route, sous la forme d'un plan de mobilisation pour la sécurité des logiciels libres. Cependant, nous devons tous faire le point et évaluer honnêtement si notre organisation est suffisamment mûre - et si nos équipes de développement ont le bon niveau de sensibilisation et de compétences en matière de sécurité - pour mettre en œuvre les stratégies défensives les plus récentes et les plus performantes, en particulier lorsqu'elles nécessitent le soutien et l'exécution de l'équipe de développement.

Qu'est-ce que le plan de mobilisation pour la sécurité des logiciels libres ?

Ce plan en dix points a été lancé par l'Open Source Software Foundation (OpenSSF) et la Linux Foundation, en collaboration avec des responsables de la Maison Blanche, des RSSI de haut niveau et d'autres dirigeants de 37 entreprises technologiques privées. Grâce à ce soutien combiné en termes d'action et de financement, la norme de sécurité des logiciels libres est appelée à devenir beaucoup plus solide. 

Ce qui est particulièrement intéressant, c'est l'accent mis sur la formation de base et la certification au niveau des développeurs, ainsi que sur les mesures visant à rationaliser les activités internes de nomenclature des logiciels (SBOM). Ces deux éléments sont notoirement difficiles à mettre en œuvre de manière à avoir un impact durable, ce qui peut être attribué en partie à des problèmes de croissance au sein des programmes de sécurité des organisations et à un manque général de maturité en matière de sécurité au sein de la cohorte de développeurs, sans qu'ils en soient responsables. Ils se trouvent dans un environnement sous pression où le volume de code et la vitesse règnent en maîtres, face à des délais de plus en plus déraisonnables. Ajouter encore plus de tâches sous la forme de demandes de sécurité et de maintenance SBOM sans augmenter le temps disponible pour celles-ci est une recette qui a échoué avant même d'avoir commencé, et malheureusement, c'est plus courant que ce que l'on pourrait croire.

Jetons donc un coup d'œil sous le capot.

Certification de sécurité pour les développeurs : En sommes-nous encore là ?

S'il est une chose dont nous sommes sûrs, c'est que les développeurs compétents en matière de sécurité sont encore une denrée rare. C'est la réalité pour un certain nombre de raisons, notamment parce que jusqu'à récemment, les développeurs ne faisaient pas partie de l'équation lorsqu'il s'agissait de stratégies de sécurité logicielle au sein des organisations. Si l'on ajoute à cela le fait que les développeurs n'ont pas beaucoup de raisons de donner la priorité à la sécurité (leur formation est inadéquate ou inexistante, cela prend plus de temps, cela ne fait pas partie de leurs indicateurs clés de performance et leur principale préoccupation est de faire ce qu'ils font le mieux : créer des fonctionnalités), vous obtenez des équipes de développement qui sont mal préparées pour traiter véritablement la sécurité au niveau du code, ni pour jouer leur rôle dans un cycle de développement logiciel (SDLC) modernisé et centré sur DevSecOps. 

Si nous regardons le plan de mobilisation pour la sécurité des logiciels libres, le tout premier volet du plan en dix points porte sur les compétences des développeurs en matière de sécurité, afin de "fournir à tous une formation et une certification de base en matière de développement de logiciels sécurisés", ce qui est essentiel pour développer la maturité en matière de sécurité au sein des équipes de développement. Il met en évidence les problèmes dont nous discutons depuis un certain temps, notamment le fait que le codage sécurisé est absent de la plupart des cours de génie logiciel dispensés sur le site courses au niveau tertiaire. Il est incroyablement encourageant de voir que cette initiative est soutenue par des personnes et des départements qui peuvent changer le statu quo de l'industrie, et comme 99 % des logiciels dans le monde contiennent au moins une partie de code source ouvert, ce domaine de développement est un excellent endroit pour commencer à se concentrer sur la formation des développeurs en matière de sécurité.

Le plan cite des ressources vénérées telles que l'OpenSSF Secure Software Fundamentals courses, et les ressources étendues et de longue date de la Fondation OWASP. Ces centres d'information sont inestimables. Le déploiement proposé pour diffuser ces documents en vue d'améliorer les compétences des développeurs implique de réunir un vaste réseau de partenaires, tant dans le secteur public que privé, et de s'associer à des établissements d'enseignement pour faire du développement de logiciels libres sécurisés un élément clé du programme d'études. 

Pour ce qui est de la manière de gagner le cœur et l'esprit des ingénieurs en logiciel du monde entier, dont beaucoup ont vu la sécurité renforcée comme quelque chose qui n'est pas leur travail ou leur priorité, le plan détaille une stratégie de récompense et de reconnaissance pour cibler à la fois les développeurs qui maintiennent des bibliothèques open-source et les ingénieurs en activité qui ont besoin de voir la valeur des certifications en matière de sécurité. 

Nous savons par expérience que les développeurs réagissent bien aux incitations et que les systèmes de badges à plusieurs niveaux indiquant les progrès et les compétences fonctionnent aussi bien dans un environnement d'apprentissage que sur Steam ou Xbox.

Cependant, ce qui est préoccupant, c'est que nous n'abordons pas l'un des problèmes fondamentaux, à savoir la fourniture de modules d'apprentissage dans le cadre du programme de sécurité d'une organisation. Ayant travaillé en étroite collaboration avec des développeurs pendant une grande partie de ma carrière, je sais à quel point ils sont sceptiques lorsqu'il s'agit d'outils et de formations, sans parler de tout ce qui semble pouvoir perturber le travail qui est la priorité numéro un. L'habilitation des développeurs exige d'eux qu'ils s'engagent continuellement dans le matériel de cours, et pour que cela réussisse, il faut que cela ait un sens dans le contexte de leur travail quotidien.

Si l'on considère un modèle de maturité établi comme le modèle de maturité de l'assurance logicielle (SAMM), la "formation et l'orientation" est un élément central de la couche Governace, et l'accent est mis sur la formation des développeurs. Le modèle dans son ensemble est vaste et il existe des étapes progressives pour atteindre des niveaux de maturité plus élevés. Cependant, les étapes initiales recommandent seulement 1 à 2 jours de formation formelle pour les développeurs, ce qui est à peine suffisant pour effleurer la surface de la sensibilisation à la sécurité. Même dans ce cas, un rapport récent de l'Enterprise Strategy Group (ESG) a révélé que moins de la moitié des organisations demandent aux développeurs de suivre une formation formelle à la sécurité plus d'une fois par an. Notre propre étude, menée conjointement avec Evans Data, a révélé que seuls 29 % des développeurs estiment que la pratique active de l'écriture de codes exempts de vulnérabilités devrait être une priorité. Il existe un décalage évident entre la manière dont la formation est dispensée et reçue, et l'utilité réelle de cette formation pour atteindre la maturité en matière de sécurité, en particulier si les développeurs n'en perçoivent pas l'intérêt.

Nomenclature des logiciels : Ce plan permet-il d'éliminer les obstacles à l'adoption ?

Le volet "SBOM Everywhere - Improve SBOM Tooling and Training to Drive Adoption" (SBOM partout - Améliorer les outils et la formation SBOM pour favoriser l'adoption) étudie les moyens de faciliter la création, la mise à jour et l'utilisation des SBOM par les développeurs et leurs organisations afin d'obtenir de meilleurs résultats en matière de sécurité.

À l'heure actuelle, les SBOM ne sont pas largement adoptés dans la plupart des secteurs verticaux, ce qui rend difficile la réalisation de leur potentiel en matière de réduction des risques de sécurité. Le plan prévoit une stratégie brillante pour définir des normes clés pour la formulation des SBOM, ainsi que des outils pour faciliter la création qui s'adaptent à la façon dont les développeurs travaillent. À eux seuls, ces éléments contribueraient grandement à alléger le fardeau d'une énième tâche du SDLC pour les développeurs qui ont déjà fort à faire pour créer des logiciels à la vitesse de la demande. 

Ce que je crains, cependant, c'est que dans l'organisation moyenne, les responsabilités en matière de sécurité peuvent constituer une véritable zone grise pour les développeurs. Qui est responsable de la sécurité ? En fin de compte, c'est l'équipe de sécurité, mais les développeurs doivent être associés à la démarche si nous voulons qu'ils nous aident. Les tâches et les attentes doivent être clairement définies, et ils ont besoin de temps pour prendre en charge ces mesures supplémentaires de leur succès. 

Des logiciels libres au reste du monde du logiciel

Le plan de mobilisation pour la sécurité des logiciels libres est ambitieux, audacieux et correspond exactement à ce qu'il faut pour responsabiliser les développeurs en matière de sécurité. Il a fallu une "alliance rebelle" de quelques acteurs puissants, mais cela prouve que nous allons dans la bonne direction et que nous abandonnons l'idée que le déficit de compétences en matière de cybersécurité se résorbera de lui-même comme par magie. 

C'est notre nouvel espoir, et il faudra que nous soyons tous capables de faire avancer cette structure au-delà de l'OSS. Cependant, les professionnels de la sécurité doivent regarder en eux-mêmes et analyser les équipes de développement qui travaillent sur le code qu'ils sont chargés de protéger. assessment Ils doivent faire une évaluation honnête de leurs capacités actuelles, de leurs lacunes et s'efforcer de créer un état final mature, étanche, proactif et comprenant un programme qui transmet de véritables compétences en matière de sécurité à la cohorte de développeurs. Jusqu'à ce qu'ils soient véritablement activés, nous pourrions encore être un peu immatures dans notre approche des vulnérabilités au niveau du code.

‍

>> Testez la maturité de votre équipe en matière de sécurité avec notre défi XSS pratique et interactif !