La plupart des organisations ont encore du mal à faire de la sécurité un élément essentiel du cycle de vie du développement logiciel (SDLC), et peu d'entre elles sont capables de conquérir l'approche robuste DevSecOps. Pour beaucoup, la priorité donnée aux fonctionnalités et aux délais de publication passe encore avant la sécurité. Cette situation a des répercussions, notamment le risque accru d'une violation coûteuse des données et une baisse de la productivité lorsque les équipes passent au crible les tickets de sécurité et les travaux de reprise. 

Les développeurs étant la première ligne de défense lorsqu'il s'agit d'éliminer les risques liés aux vulnérabilités des logiciels, il est important que les organisations envisagent d'accroître la maturité de leurs équipes de développement. Mais cela soulève un certain nombre de questions.

Comment une organisation évalue-t-elle la maturité de ses équipes de développement en matière de sécurité ? Comment la mise en place d'une feuille de route pour la maturité en matière de sécurité peut-elle ne pas sembler une tâche impossible ? Comment maintenir l'engagement et la motivation de vos développeurs pour améliorer leur maturité en matière de sécurité ? 

Nous avons utilisé les résultats de l'enquête Secure Code Warrior State of Developer-Driven Security Survey pour comprendre les réponses à ces questions et nous avons fait appel à nos équipes de service à la clientèle de classe mondiale pour découvrir ce que d'autres organisations font pour trouver les réponses. ‍

Comment accroître la maturité des équipes de développement en matière de sécurité ?

Il n'y a pas deux organisations identiques lorsqu'il s'agit d'améliorer la maturité de la sécurité, avec de nombreuses variables à prendre en compte qui peuvent avoir un impact sur le succès d'une entreprise dans ses efforts pour passer à gauche. Les avantages sont nombreux pour ceux qui y parviennent, notamment la création et la publication plus rapides de codes présentant moins de vulnérabilités, voire aucune, ce qui permet de réduire les travaux de reprise coûteux et, en fin de compte, de réduire les risques. 

Les organisations qui progressent disposent d'un plan défini, soutenu par la direction, et d'une approche cohérente pour améliorer continuellement la maturité de la sécurité au fil du temps : 

• Définir un niveau de maturité de la sécurité
• Évaluer la maturité des équipes en matière de sécurité
• Identifier les principales faiblesses en matière de sécurité
• Construire une culture positive de la sécurité

Consultez notre nouveau livre blanc L'importance de la maturité de la sécurité dans les équipes de développement pour en savoir plus :

• Qu'est-ce que la maturité en matière de sécurité dans les équipes de développement et pourquoi est-elle importante ?
• Quelles sont les différentes étapes et caractéristiques de la maturité en matière de sécurité pour les équipes de développement ?
• Que faut-il pour que les équipes de développement acquièrent une certaine maturité en matière de sécurité ?

L'importance des compétences des développeurs en matière de sécurité est soulignée dans le rapport 2022 Gartner Cool Vendors in Software Engineering. Lisez le rapport complet ici.

Secure Code Warrior a été reconnu comme l'un des quatre "Cool Vendors in Software Engineering : Enhancing Developer Productivity", par Gartner. Selon Gartner, la définition d'un "Cool Vendor" est celle d'une petite entreprise offrant une technologie ou un service innovant, impactant ou intriguant. Les trois éléments d'un "Cool Vendor" sont les suivants :

Innovant - Permet aux utilisateurs de faire des choses qu'ils ne pouvaient pas faire auparavant.

Impact - A ou aura un impact sur l'entreprise, et ne se contente pas d'être une technologie pour elle-même.

Intrigant - A suscité l'intérêt de Gartner au cours des six derniers mois.

Comme le souligne le rapport, "les ingénieurs en informatique ont du mal à naviguer dans des environnements de code complexes et à améliorer la sécurité des systèmes qu'ils construisent tout en restant productifs. Ces "Cool Vendors" proposent des solutions innovantes qui aident les responsables de l'ingénierie logicielle à stimuler la productivité des développeurs et à atténuer les risques de sécurité.

En tant que seule entreprise répertoriée qui se concentre sur la sécurité axée sur les développeurs, cette reconnaissance témoigne de notre stratégie visant à doter les développeurs des bonnes compétences en matière de sécurité et d'outils contextuels afin qu'ils puissent rapidement apprendre, construire et appliquer leurs compétences pour fournir un code sécurisé à la vitesse, pour une sécurité logicielle améliorée.

Alors que les vertus du passage à gauche sont vantées depuis un certain temps déjà, de nombreuses organisations peinent encore à s'assurer que la sécurité est prise en compte dès le début du cycle de développement des logiciels. Notre récente 'Enquête sur l'état de la sécurité pilotée par les développeurs a mis en évidence le fait que le manque de temps est le principal obstacle à surmonter lors de l'adoption de pratiques de codage sécurisées, ce qui est également reflété dans ce récent rapport de Gartner. Avec une pénurie significative d'ingénieurs qualifiés, combinée à des référentiels de code vastes et complexes et plus de la moitié de la pile d'exécution constituée de logiciels libres, les développeurs ont à peine le temps de maintenir le code existant - sans parler d'en assurer la sécurité.

Sur Secure Code Warrior, nos solutions sont motivées par la nécessité d'améliorer la productivité tout en garantissant la sécurité des logiciels. Bien que l'enquête mentionne un manque de temps pour adopter des pratiques de codage sécurisées, 76% des personnes interrogées reconnaissent qu'une bonne formation en codage sécurisé améliorerait en fait la productivité en réduisant le nombre de tickets de sécurité et de travaux de reprise à gérer. Lorsqu'elles disposent des compétences et des outils de sécurité adéquats, les équipes de développeurs peuvent facilement atténuer les risques et fournir rapidement un code sécurisé et de qualité, avec des caractéristiques et des fonctionnalités innovantes. 

Merci donc à Gartner pour cette reconnaissance, non seulement pour Secure Code Warrior , mais aussi pour avoir souligné le rôle important que les développeurs compétents en matière de sécurité peuvent jouer dans le domaine de la cybersécurité.
‍

Accédez à la Gartner Cool Vendors in Software Engineering : Améliorer la productivité des développeurs dès maintenant. 

‍

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

‍

Pour les professionnels de la sécurité, le 13 décembre a quelque chose de particulier. Est-ce le jour où nous avons enfin éradiqué l'injection SQL pour toujours ? Bien sûr que non. Peut-être s'agit-il de la "Journée internationale d'appréciation des travailleurs de la sécurité" ? Non, pas du tout. C'est le jour où FireEye et Mandiant ont publié leur rapport choquant sur une campagne d'intrusion mondiale inconnue jusqu'alors, qui allait être connue sous le nom de SolarWinds. Le rapport décrit une attaque permanente et presque incroyable dans laquelle un code malveillant est dissimulé au cœur des mises à jour du célèbre logiciel de gestion Orion de SolarWind.

Plus de 18 000 clients de SolarWinds avaient déjà téléchargé la mise à jour corrompue. Beaucoup d'entre eux l'ont fait automatiquement, comme ils l'ont fait pour des centaines d'autres mises à jour de logiciels au sein de leurs organisations et de leurs réseaux. Les attaquants ont été très sélectifs dans le choix de leurs attaques une fois qu'ils ont eu accès à la brèche de SolarWinds. De nombreuses grandes entreprises, ainsi que des agences gouvernementales, ont vu leurs données volées et leurs réseaux compromis. Il s'agit de l'une des failles les plus importantes et probablement la plus coûteuse de tous les temps, d'autant plus que dans le cas des agences gouvernementales, l'étendue des dégâts n'a jamais été rendue publique.

Tout cela s'est produit parce que les gens ont fait confiance aux fournisseurs de leur chaîne d'approvisionnement en logiciels sans vérifier ou contrôler correctement leurs activités.

Le passage massif à la sécurité de la chaîne d'approvisionnement

Une fois la sonnette d'alarme tirée, les entreprises, les organisations et les agences gouvernementales n'ont pas tardé à réagir. La faille de SolarWinds a bien sûr été stoppée, mais l'attaque a également mis en lumière les dangers d'une chaîne d'approvisionnement en logiciels non réglementée et non surveillée. Si l'incident de SolarWinds a été rapidement résolu une fois découvert, les implications concernant la manière dont la chaîne d'approvisionnement a été utilisée comme vecteur d'attaque sont toujours en cours. Si l'attaque n'a rien apporté de bon, elle a au moins permis de mettre en lumière un aspect essentiel, mais négligé, de la cybersécurité.

L'une des réponses les plus médiatisées à l'attaque de SolarWinds a été le décret du président Biden sur l'amélioration de la cybersécurité de la nation. Ce décret est l'une des directives les plus complètes jamais publiées aux États-Unis en matière de cybersécurité. Il exige une meilleure cybersécurité dans les agences et pour ceux qui travaillent avec le gouvernement, préconise des protections avancées telles que le réseau de confiance zéro et souligne la nécessité de sécuriser la chaîne d'approvisionnement des logiciels.

Bien que le décret soit spécifique au gouvernement, d'autres groupes ont également commencé à souligner l'importance de la sécurité de la chaîne d'approvisionnement pour prévenir une autre attaque du type de celle de SolarWinds. Par exemple, Palo Alto a récemment publié son Unit 42 Cloud Threat Report intitulé "Secure the Software Supply Chain to Secure the Cloud" (Sécuriser la chaîne d'approvisionnement des logiciels pour sécuriser le nuage). Ce rapport indique qu'aucun déploiement en nuage n'est totalement sûr sans la sécurité de la chaîne d'approvisionnement des logiciels. La Cloud Native Computing Foundation partage cet avis et a publié un livre blanc détaillant les meilleures pratiques de la chaîne d'approvisionnement des logiciels qui doivent être suivies à la suite de l'affaire SolarWinds.

On peut dire sans risque de se tromper que les normes de cybersécurité ont été transformées au cours des deux dernières années et, bien que cela ne soit pas obligatoire, toutes les organisations devraient avoir pour objectif de suivre le mouvement et d'examiner minutieusement les pratiques de sécurité des fournisseurs comme si elles faisaient partie de leur propre programme de sécurité interne. Des initiatives telles que le nouveau plan stratégique de la CISA prouvent une fois de plus que l'approche de la sécurité en tant que responsabilité partagée fait partie d'une nouvelle norme pour tous les créateurs de logiciels, en particulier ceux qui sont impliqués dans les infrastructures critiques ou la chaîne d'approvisionnement en logiciels.

Que peuvent faire les organisations pour améliorer leurs chaînes d'approvisionnement en logiciels ?

De nombreux fournisseurs se demandent, à juste titre, ce qu'ils peuvent faire pour protéger leur propre chaîne d'approvisionnement. Que peut faire une organisation pour s'assurer que ses fournisseurs se soucient autant qu'elle de la cybersécurité ? 

Le décret souligne spécifiquement l'impact des développeurs de logiciels et la nécessité pour eux de disposer de compétences et d'une sensibilisation vérifiées en matière de sécurité, un domaine qui tend à être oublié dans un secteur obsédé par les outils, plutôt que de mettre l'accent sur une défense dirigée par les personnes grâce à des compétences clés en matière de sécurité.

assessment Il est devenu évident que, de nos jours, toute approche globale de la cybersécurité doit absolument inclure une analyse détaillée des risques pour les tiers assessment, couvrant les contrôles de sécurité techniques en place et une analyse de la façon dont les partenaires envisagent la gouvernance, les risques et la conformité au sein de leur propre organisation. 

Toutes les évaluations de tiers doivent inclure des garanties et des plans détaillés sur la manière dont les acteurs de votre chaîne d'approvisionnement en logiciels prévoient de publier des mises à jour de programmes sécurisées avec des signatures de certificats vérifiées, et sur la manière dont ils aideront à gérer les identités de tous leurs logiciels et appareils. Ils doivent également démontrer qu'ils disposent d'un chemin clair pour les mises à niveau cryptographiques et les mises à jour de leurs produits.

Et maintenant que les développeurs sont enfin considérés comme un élément essentiel de la sécurité de la chaîne d'approvisionnement des logiciels, tout site assessment devrait également inclure un rapport détaillant la manière dont ils encouragent le codage sécurisé et l'amélioration continue au sein de leur communauté de développeurs, et idéalement, l'évaluation comparative de leurs compétences et de leur formation actuelle. Nous savons que l'accent mis sur le perfectionnement des développeurs s'améliore, mais 48 % des développeurs ont admis avoir sciemment envoyé du code vulnérable.

Des facteurs tels que les contraintes de temps et le fait que la sécurité n'est tout simplement pas une priorité absolue (ni une mesure du succès) dans leur monde, contribuent à un environnement où les vulnérabilités au niveau du code ne sont pas traitées aussi tôt qu'elles devraient l'être. Si nous voulons les empêcher d'infecter la chaîne d'approvisionnement en logiciels, chaque organisation doit s'engager à mettre en place un programme de sécurité plus convivial pour les développeurs. 

Prochaines étapes ?

L'évaluation des risques est essentielle car, si vous utilisez le logiciel d'un fournisseur qui a des problèmes de sécurité, vous en hériterez dans votre écosystème et en subirez les conséquences. Toutefois, les organisations doivent également se rendre compte qu'il est possible que leurs fournisseurs soient en fait plus sûrs et qu'ils soient même plus à même de soutenir leurs communautés de développeurs. 

Vous pouvez utiliser le site assessment comme deuxième moyen d'évaluer votre propre sécurité. Si un fournisseur gère un aspect de la sécurité mieux que vous ne le faites en interne, vous pouvez adopter ses méthodes pour améliorer votre propre organisation.

Enfin, la prochaine grande étape pour améliorer réellement la chaîne d'approvisionnement en logiciels consiste à mettre en place des certifications de codage sécurisé pour les développeurs. La mise en place d'un bon plan est la première étape, mais il est également nécessaire de vérifier qu'il est réellement suivi et qu'il contribue à produire un code sécurisé. 

Tant que nous n'aurons pas atteint un point où l'habilitation des développeurs à coder de manière sécurisée sera la norme, nous serons toujours en retard pour fermer les fenêtres d'opportunité avant que les acteurs de la menace ne puissent s'infiltrer. Cependant, il n'est jamais trop tard pour avoir un impact positif avec le soutien adéquat. Découvrez dès maintenant comment vos développeurs peuvent perfectionner des compétences pertinentes et à fort impact en matière de sécurité grâce à la puissance de l'apprentissage agile.

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

‍

La création d'un environnement dans lequel les objectifs de l'équipe de sécurité et de leurs homologues développeurs sont alignés a été une bataille difficile, mais essentielle. Nous avons encore un long chemin à parcourir, mais les obstacles qui se dressent sur la voie de la synergie nécessaire pour ouvrir la porte à une responsabilité partagée en matière de sécurité des logiciels sont de plus en plus évidents. Les entreprises intelligentes veulent faire évoluer leur stratégie pour éviter ces écueils, trouver une voie productive et utiliser DevSecOps à son plein potentiel.

Ce que je n'avais pas prévu, c'est que la perception de ce qui constitue l'acte de codage sécurisé est sujette à débat. Selon une toute nouvelle étude réalisée en collaboration avec Evans Data, ce sentiment a été révélé noir sur blanc. L'enquête State of Developer-Driven Security 2022 (État de la sécurité pilotée par les développeurs 2022 ) se penche sur les principaux points de vue et expériences de 1200 développeurs actifs, mettant en lumière leurs attitudes et défis dans le domaine de la sécurité.

L'une des principales conclusions est que seuls 14 % des développeurs considèrent la sécurité comme une priorité lorsqu'ils codent. Bien que cela montre qu'il y a une énorme marge d'amélioration, cela confirme ce que nous savions déjà : la création de fonctionnalités est reine dans le monde des développeurs, et ils restent mal équipés pour faire de la sécurité une partie de leur ADN. Toutefois, si l'on ajoute à cela les données relatives à la définition par les développeurs de ce que signifie pour eux le codage sécurisé, il y a de quoi s'inquiéter.

Ces perceptions sont le fruit de l'expérience des développeurs au cours de leur journée de travail et reflètent l'environnement de nombreuses organisations, à savoir que les développeurs ne sont tout simplement pas au centre de la lutte contre les vulnérabilités courantes. Il est essentiel de leur donner les moyens d'agir, mais en attendant, nous devons rapidement nous mettre d'accord sur la portée du "codage sécurisé" et sur ce que nous devrions attendre d'un développeur compétent en matière de sécurité. 

Nous devons démystifier la sécurité dans le monde des développeurs.

La cybersécurité est une bête aux multiples facettes, difficile à manier dans le meilleur des cas, et si le codage sécurisé ne représente qu'une partie du paysage global, c'est un rouage complexe du système qui nécessite l'attention d'un spécialiste.

L'enquête a révélé que le concept de travail avec du code sécurisé était assez cloisonné pour le développeur moyen, son champ d'action se limitant souvent à une seule catégorie par opposition à une vision holistique des principes fondamentaux et au-delà. Les développeurs ont indiqué qu'ils se fiaient à l'utilisation de code existant (ou pré-approuvé), plutôt qu'à la pratique consistant à écrire un nouveau code exempt de vulnérabilités. Alors que la sensibilisation à la sécurité concernant les composants tiers (en particulier les correctifs, et la débâcle de Log4Shell en est un excellent exemple : 30 % des instances n'ont pas été corrigées depuis décembre) est très importante, tout comme le test du code existant, mais ces éléments ne suffisent pas à atteindre un niveau fonctionnel de capacité de codage sécurisé. 

Les vulnérabilités au niveau du code sont introduites par des développeurs qui ont appris de mauvais schémas de codage, et le fait de ne pas mettre l'accent sur l'écriture de code sécurisé dans leurs indicateurs clés de performance (associé à une culture de la sécurité peu convaincante) ne fait que renforcer cette situation comme une norme acceptable. 

Les responsables de la sécurité peuvent contribuer grandement à améliorer la sensibilisation initiale et à identifier les domaines où les lacunes en matière de connaissances sont les plus pressantes, en veillant tout d'abord à ce que la cohorte de développement ait une vue d'ensemble de ce qu'implique le codage sécurisé. Tester et analyser le code approuvé au préalable est une fonction, mais la réduction des vulnérabilités nécessite une formation pratique à de bons modèles de codage, sûrs, dans les langages et les cadres activement utilisés.

Le contexte est essentiel pour la montée en compétence des développeurs, qui doivent être associés aux objectifs de sécurité de l'entreprise.

De nombreuses organisations doivent mettre à jour leurs programmes de sécurité.

Avec l'explosion des technologies basées sur les logiciels et la croissance rapide des incidents de cybersécurité au cours de la dernière décennie, nous nous efforçons tous de suivre le rythme des acteurs de la menace qui travaillent 24 heures sur 24 pour découvrir des exploits dans des systèmes précieux. 

La méthodologie DevSecOps repose sur l'idée que tout le monde partage la responsabilité de la sécurité - y compris les développeurs - et qu'il faut en tenir compte dès le début du cycle de développement durable. Le problème, c'est que les grandes entreprises, en particulier, peuvent être très loin de mettre en œuvre DevSecOps en tant que norme. En 2017, une étude du Project Management Institute a montré que 51 % des organisations utilisaient encore la méthode Waterfall pour le développement de leurs logiciels. Cette étude date maintenant de cinq ans, mais sachant à quel point les changements peuvent être progressifs dans les grandes entreprises, il est peu probable qu'il y ait eu une transition brutale vers les dernières méthodologies axées sur la sécurité. Ces processus hérités peuvent créer une bataille difficile pour les professionnels de la sécurité qui tentent de couvrir toutes les bases d'une stratégie globale de protection contre les cybermenaces, et l'adaptation des développeurs et de leurs besoins à ce paysage est un défi. 

Cependant, nous ne pouvons pas nous en servir comme d'une excuse. Les professionnels de la sécurité peuvent utiliser les développeurs dans le cadre d'une stratégie améliorée ; ils doivent simplement se familiariser avec leurs besoins et les considérer comme faisant partie de leur jeu défensif. Ils ont besoin d'une formation complète et toute responsabilité en matière de sécurité doit être mise en œuvre dans le respect de leur pile technologique et de leur flux de travail. 

Codage sécurisé = le panier "trop dur" ?

L'étude d'Evans Data a mis en lumière le fait que 86% des développeurs estiment qu'il est difficile de pratiquer un codage sécurisé, et que 92% des responsables de développement admettent que leurs équipes ont besoin d'une formation plus poussée en matière de cadres de sécurité. Fait inquiétant, 48 % des personnes interrogées ont admis qu'elles laissaient sciemment des vulnérabilités dans leur code. 

Le tableau est très inquiétant. Il semble que, de manière générale, les développeurs ne bénéficient pas d'une formation fréquente et adéquate et qu'ils ne soient pas suffisamment exposés aux bonnes pratiques et à l'hygiène en matière de sécurité. En lisant entre les lignes, cela renforce le nœud du problème : les développeurs ne considèrent tout simplement pas la sécurité comme une priorité dans leur travail. De plus, la formation qu'ils reçoivent ne leur donne pas confiance en eux, ne leur permet pas d'acquérir des compétences pratiques et ne les aide pas à comprendre l'impact de leur décision de livrer un code vulnérable. 

L'attaque du ransomware de Colonial Pipeline a été l'un des incidents de sécurité de la chaîne d'approvisionnement les plus perturbants de l'année dernière, suscitant la crainte que la moitié de l'approvisionnement en gaz de la côte est des États-Unis ne soit coupée pour une période indéterminée. Heureusement, la situation s'est rétablie rapidement, mais non sans une certaine appréhension au sein de la communauté. Ce fut l'un de ces moments cruciaux où le grand public a été confronté à la perspective d'un cyberincident affectant gravement un élément du monde physique qui n'est pas nécessairement considéré comme piloté par un logiciel, ou comme un risque de cyberattaque. Tout ce chaos a été rendu possible par deux anciennes vulnérabilités non corrigées, dont l'une était l'injection SQL, insidieuse mais largement connue. Si les développeurs savaient ce qui est réellement en jeu lorsqu'ils choisissent de livrer un code vulnérable, ils verraient rapidement qu'il n'y a pas de scénario dans lequel cela constitue un risque commercial acceptable.

Le "P-P-T" fonctionnel ne dépend pas du développeur.

Le fameux "triangle d'or" des personnes, des processus et des outils n'est pas réalisable sans une stratégie soigneusement étudiée, et les développeurs ne sont pas en mesure de s'assimiler à un processus de sécurité opérationnel sans tenir compte de leurs besoins et de leurs défis.

Il faudra un changement culturel important pour améliorer la sécurité axée sur les développeurs, et cela commence par des parcours éducatifs qui amènent les ingénieurs et l'équipe de sécurité à une plus grande clarté.

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

‍

Pendant ce qui semble être une éternité, nous avons discuté du "déplacement vers la gauche" dans le SDLC, en prenant en compte les meilleures pratiques de sécurité dès le début du développement du logiciel. DevSecOps a été un grand pas en avant, en grande partie parce qu'il met l'accent sur le partage des responsabilités en matière de sécurité et sur la capacité d'un développeur sensibilisé à la sécurité à déjouer les vulnérabilités courantes au fur et à mesure qu'il écrit le code. 

Nous savons également - là encore, depuis des lustres - que le type de formation au code sécurisé choisi pour impliquer et perfectionner les développeurs fait toute la différence. Les solutions à faible effort motivées uniquement par la conformité réglementaire ne permettent pas de former les brillants esprits de sécurité de demain, et la plupart des professionnels de la sensibilisation à la sécurité l'ont compris. Un apprentissage dynamique et adapté au contexte est préférable, mais il est essentiel de comprendre les nuances qu'il comporte. 

Si nous voulons avoir une chance de nous battre contre les acteurs de la menace - et ils ont toujours une longueur d'avance sur une organisation - les développeurs ont besoin d'un environnement de formation holistique, avec un apprentissage en couches qui renforce continuellement les compétences ancrées dans les meilleures pratiques.

Les mesures de sécurité défensives prises par les développeurs ne sont pas automatiquement gagnantes.

Notre philosophie repose sur le fait que le développeur est au cœur d'une stratégie de sécurité préventive, dès le niveau du code. C'est une évidence, et les développeurs compétents en matière de sécurité constituent la voie la plus facile pour contrecarrer les types de bogues de sécurité courants qui sont apparents dans les modèles de codage médiocres (comme Log4Shell, qui est un exemple récent et dévastateur).

Cependant, les techniques défensives que nous pouvons utiliser pour améliorer les compétences des développeurs varient, même si elles peuvent à juste titre exister dans le même panier de formation. 

Imaginez, par exemple, que l'on vous dise comment faire un gâteau, en utilisant uniquement des instructions basées sur ce qu'il ne faut pas faire. "Ne pas trop le cuire" et "ne pas oublier les œufs" laissent place à l'interprétation et à un énorme potentiel d'erreurs qui donneront un résultat final digne d'un gâteau. C'est raté !. Il en va de même pour l'éducation à la sécurité défensive ; ce qu'il ne faut pas faire est une partie très limitée de la conversation, et n'offre aucun conseil pratique pour agir véritablement avec un état d'esprit défensif. Vous pouvez dire aux développeurs "ne configurez pas mal cette API", mais si vous ne comprenez pas ce qu'est une configuration correcte et sûre, il y a beaucoup de place pour l'erreur.

Les développeurs n'auront pas d'impact positif sur la réduction des vulnérabilités sans une compréhension fondamentale du fonctionnement des vulnérabilités, de la raison pour laquelle elles sont dangereuses, des modèles qui les causent et des modèles de conception ou de codage qui les corrigent dans un contexte qui a du sens dans leur monde. Une approche par échafaudage permet aux couches de connaissances de donner une image complète de ce que signifie coder en toute sécurité, défendre une base de code et se tenir debout en tant que développeur conscient de la sécurité. Et oui, une partie de cet apprentissage en couches doit être consacrée à l'offensive et à la compréhension de l'état d'esprit d'un attaquant ; c'est essentiel pour affiner les compétences de pensée latérale, qui sont inestimables dans la modélisation des menaces et la stratégie défensive. 

Renforcer les mauvaises habitudes de codage est un piège que nous ne pouvons pas ignorer.

Malheureusement, certaines méthodes de formation des développeurs ont pour effet que la partie "défensive" - même lorsque la formation est structurée avec des techniques offensives - peut renforcer les mauvaises habitudes, même si elles valident techniquement la sécurité du code. 

La production d'un code de haute qualité devrait être la base de tout développement de logiciel, mais la définition de la "qualité" semble toujours faire l'objet d'un débat. En réalité, un code non sécurisé ne peut pas être considéré comme un code de qualité, même s'il est par ailleurs fonctionnel et beau. Le comble, c'est que le codesécurisé n'est pas non plus intrinsèquement de haute qualité. En d'autres termes, de mauvais schémas de codage peuvent résoudre un problème de sécurité, mais, ce faisant, en introduire un autre, voire casser entièrement le logiciel. 

Examinons un exemple de code de mauvaise qualité sous la forme d'un correctif pour une authentification défectueuse, ainsi que la version la plus sûre pour les meilleures pratiques :

‍

en utilisant System ;

using System.Collections.Generic ;

using System.Linq ;

using System.Threading.Tasks ;

using Microsoft.AspNetCore.Authorization ;

using Microsoft.AspNetCore.Http ;

utilisant Microsoft.AspNetCore.Mvc ;

‍

namespace BadFixesAPI.Controllers

{

    [Route("api/[controller]")]

    [ApiController]

    public class AlertsController : ControllerBase

    {

        private DatabaseContext context = new DatabaseContext() ;

‍

        [HttpGet(Name = "GetAlerts")]

        // Does not ensure that the user is authenticated 

        public IEnumerable<Alert> Get()

        {

            return context.GetAlerts() ;

        }

‍

        [HttpGet(Name = "GetAlerts")]

        // Ensures that the user is authenticated, but does not check any roles

        [Authorize()]

        public IEnumerable<Alert> GetBadFix()

        {

            return context.GetAlerts() ;

        }

‍

        [HttpGet(Name = "GetAlerts")]

        // Ensures that the user is authenticated, AND that they have the "Administrator" role

        [Authorize(Roles = "Administrator")]

        public IEnumerable<Alert> GetGoodFix()

        {

            return context.GetAlerts() ;

        }

    }

}

‍

Dans le premier extrait, aucun contrôle n'est effectué pour vérifier que l'utilisateur est authentifié, ce qui est à peu près aussi peu sûr que possible. Le deuxième extrait, bien que meilleur en termes de vérification de l'authentification, n'examine pas les rôles attribués et ne vérifie pas si les autorisations sont suffisamment élevées pour permettre l'accès aux informations demandées. La troisième vérifie à la fois l'authentification de l'utilisateur et l' attribution du rôle d'"administrateur". À une époque où le contrôle de l'accès au moindre privilège devrait être la norme dans la plupart des cas, il est essentiel que les rôles soient définis et vérifiés pour s'assurer que les informations ne sont accessibles que sur la base du besoin de savoir. 

La priorité absolue des développeurs est de créer des fonctionnalités, et même si la sécurité n'est pas intentionnellement mise de côté, ils n'ont pas nécessairement les compétences nécessaires pour éviter les mauvais schémas de codage qui conduisent à des bogues de sécurité, et la référence d'un bon ingénieur inclut rarement des prouesses en matière de codage sécurisé. Nous encourageons indirectement ces mauvaises habitudes si les fonctionnalités sont suffisamment géniales, et c'est cet état d'esprit qui doit changer. Le problème est que la façon dont certains parcours d'apprentissage encouragent la remédiation pratique du code renforce aussi potentiellement le code qui est sûr, mais de qualité inférieure. En appliquant une approche binaire du type "oui c'est sûr / non ce n'est pas sûr" assessment, au lieu de chercher à savoir si c'est vraiment la meilleure approche pour résoudre le bogue et maintenir l'intégrité du logiciel, il y a des diables dans les détails qui passent inaperçus. 

Si elle n'accompagne pas les développeurs tout au long du processus pour leur donner une vue d'ensemble du codage sécurisé, cette approche perpétue les mêmes problèmes qu'elle tente de résoudre. Imaginez que nous obtenions tous notre permis de conduire sur la seule base de notre capacité à conduire un véhicule jusqu'à une destination ; une note de passage même si nous avons grillé des feux rouges, traversé une haie et manqué de peu un piéton qui traversait la rue pour arriver à destination. Nous avons atteint l'objectif, mais c'est le voyage que nous avons effectué pour y parvenir qui compte le plus. 

Il faut permettre aux développeurs de se préoccuper davantage de la création de logiciels sûrs.

Le développeur moderne doit faire tourner beaucoup de choses, et il n'est pas surprenant qu'il trouve la formation à la sécurité ennuyeuse, surtout lorsqu'elle n'est pas mise en œuvre en tenant compte de sa journée de travail, et qu'elle l'éloigne de ses échéances et de ses priorités. Il est également tout à fait injuste de modifier leurs indicateurs clés de performance pour mettre l'accent sur le codage sécurisé, alors qu'ils ne disposent pas des compétences acquises grâce à des opportunités d'apprentissage régulières et adaptées et à des outils supplémentaires. Cependant, on ne saurait trop insister sur l'importance du développement de logiciels sécurisés, et il est crucial de rallier les développeurs à cette cause. 

En tant qu'ancien développeur, nous voulons généralement faire du bon travail et il est très motivant d'être considéré comme supérieur aux autres en termes de qualité de production. Inciter les développeurs à s'engager dans un renforcement continu des compétences en matière de sécurité est une évidence, et ils devraient être récompensés pour avoir reconnu l'importance de la sécurité au niveau du code. Les programmes de champions de la sécurité, les primes aux bogues et les hackathons peuvent être d'excellentes occasions de créer une culture positive de la sécurité, et ceux qui se retroussent les manches et s'impliquent devraient recevoir le butin.

Une version de cet article a été publiée dans le SD Times. Elle a été mise à jour et publiée ici.

‍

Lorsque nous parlons de progrès, c'est généralement le progrès numérique qui est au premier plan de la conversation. Nous voulons que tout soit meilleur, plus rapide, plus pratique, plus puissant, et nous voulons le faire en dépensant moins d'argent, en prenant moins de temps et en prenant moins de risques. La plupart du temps, ces objectifs "impossibles" finissent par être atteints ; cela peut prendre plusieurs années et de nombreuses versions (et une équipe de développeurs qui pourraient faire un coup d'État si on leur demandait de changer de vitesse sur la conception des fonctionnalités une fois de plus), mais chaque jour, le code est là, en train de changer le monde. 

Cependant, une grande expansion des logiciels s'accompagne d'une grande responsabilité, et la réalité est que nous ne sommes tout simplement pas prêts à y faire face du point de vue de la sécurité. Le développement de logiciels n'est plus une île, et lorsque nous prenons en compte tous les aspects des risques liés aux logiciels - le nuage, les systèmes embarqués dans les appareils et les véhicules, notre infrastructure critique, sans parler des API qui les relient tous - la surface d'attaque est sans frontières et incontrôlable. 

Nous ne pouvons pas nous attendre à une époque magique où chaque ligne de code est méticuleusement vérifiée par des experts en sécurité chevronnés - ce déficit de compétences n'est pas près de se résorber - mais nous pouvons, en tant qu'industrie, adopter une approche plus holistique de la sécurité au niveau du code.

Voyons comment nous pouvons maîtriser cette surface d'attaque infinie avec les outils dont nous disposons :

Soyez réaliste quant au niveau de risque commercial (et à ce que vous êtes prêt à accepter).

La sécurité parfaite n'est pas viable, mais il ne faut pas non plus se mettre un bandeau sur les yeux et prétendre que tout va pour le mieux. Nous savons déjà que des organisations livrent sciemment du code vulnérable, et il est clair qu'il s'agit d'un risque calculé en fonction du délai de mise sur le marché de nouvelles fonctionnalités et de nouveaux produits. 

La sécurité à grande vitesse est un défi, en particulier dans les endroits où DevSecOps n'est pas la méthodologie de développement standard. Cependant, il suffit de regarder le récent exploit Log4Shell pour découvrir comment des problèmes de sécurité relativement mineurs dans le code ont ouvert des opportunités pour une attaque réussie, et voir que les conséquences de ces risques calculés pour l'envoi de code de moindre qualité pourraient être beaucoup plus importantes que prévu.

Soyez à l'aise avec le fait d'être un maniaque du contrôle (d'accès)

Un nombre alarmant de violations de données coûteuses sont causées par des environnements de stockage en nuage mal configurés, et le risque d'exposition de données sensibles résultant d'erreurs de contrôle d'accès continue de hanter les équipes de sécurité de la plupart des organisations. 

En 2019, la société First American Financial Corp., classée au Fortune 500, l'a appris à ses dépens. Une erreur d'authentification - relativement simple à corriger - a conduit à l'exposition de plus de 800 millions de documents, notamment des relevés bancaires, des contrats hypothécaires et des photos d'identité. Les liens vers ces documents ne nécessitaient aucune identification ou connexion de la part de l'utilisateur, ce qui les rendait accessibles à toute personne disposant d'un navigateur web. Pire encore, ils étaient enregistrés avec des numéros séquentiels, ce qui signifie qu'un simple changement de numéro dans le lien exposait un nouvel enregistrement de données. 

Ce problème de sécurité a été identifié en interne avant d'être révélé par les médias, mais le fait de ne pas l'avoir classé correctement comme un problème de sécurité à haut risque et de ne pas l'avoir signalé à la direction pour qu'elle y remédie d'urgence a entraîné des retombées qui se font encore sentir aujourd'hui.

Ce n'est pas pour rien que le contrôle d'accès défaillant figure désormais en tête du Top 10 de l'OWASP: il est aussi courant que la saleté, et les développeurs ont besoin d'une sensibilisation à la sécurité vérifiée et de compétences pratiques pour appliquer les meilleures pratiques en matière d'authentification et de privilèges dans leurs propres créations, en veillant à ce que des contrôles et des mesures soient en place pour protéger l'exposition aux données sensibles. 

La nature des API les rend particulièrement pertinentes et délicates ; elles sont très bavardes avec d'autres applications de par leur conception, et les équipes de développement doivent avoir une visibilité sur tous les points d'accès potentiels. Après tout, elles ne peuvent pas prendre en considération des variables et des cas d'utilisation inconnus dans leur quête d'un logiciel plus sûr.

Analysez votre programme de sécurité : quelle est l'importance accordée à la prévention ?

Il est logique qu'une grande partie d'un programme de sécurité soit consacrée à la réponse et à la réaction aux incidents, mais de nombreuses organisations ne parviennent pas à minimiser les risques en n'utilisant pas toutes les ressources disponibles pour prévenir un incident de sécurité dès le départ.

Bien sûr, il existe des piles complètes d'outils de sécurité qui aident à découvrir les bogues problématiques, mais près de 50 % des entreprises ont admis avoir expédié du code qu'elles savaient vulnérable. Les contraintes de temps, la complexité des outils et le manque d'experts formés pour répondre aux rapports contribuent tous à ce qui a été essentiellement un risque calculé, mais le fait que le code doive être sécurisé dans le nuage, dans les applications, dans les fonctionnalités API, dans les systèmes intégrés, dans les bibliothèques et dans un paysage technologique de plus en plus large, garantit que nous aurons toujours un pas de retard avec l'approche actuelle.

Les bogues de sécurité sont un problème d'origine humaine, et nous ne pouvons pas attendre des robots qu'ils fassent toutes les corrections à notre place. Si votre cohorte de développeurs ne bénéficie pas d'une formation continue efficace - pas seulement un séminaire annuel, mais des modules de formation adéquats - vous risquez toujours d'accepter un code de mauvaise qualité comme norme, avec les risques de sécurité qui en découlent. 

Avez-vous surestimé le niveau de préparation de vos développeurs ?

Les développeurs sont rarement évalués sur leurs capacités de codage sécurisé, et ce n'est pas leur priorité (ni un indicateur de performance dans de nombreux cas). Ils ne peuvent pas être les boucs émissaires de mauvaises pratiques de sécurité si on ne leur montre pas une meilleure voie ou si on ne leur dit pas que c'est une mesure de leur succès. 

Trop souvent, cependant, les organisations partent du principe que les conseils fournis ont été efficaces pour préparer l'équipe d'ingénieurs à atténuer les risques de sécurité courants. En fonction de la formation et de leur sensibilisation à l'application des meilleures pratiques de sécurité, ils peuvent ne pas être préparés à constituer cette première ligne de défense souhaitable (et à empêcher d'innombrables failles d'injection d'encombrer les rapports de pentest). 

Dans l'idéal, des parcours d'apprentissage de complexité croissante sont réalisés, et les compétences qui en résultent sont vérifiées pour s'assurer qu'elles fonctionnent réellement pour le développeur dans le monde réel. Cependant, cela nécessite une norme culturelle où les développeurs sont pris en compte dès le début et correctement habilités. Si, en tant qu'industrie, nous partons dans la nature pour défendre ce vaste paysage de code que nous avons créé nous-mêmes, nous aurons besoin de toute l'aide possible... et il y en a plus devant nous que nous ne le pensons.

Secure Code Warrior et Okta lancent une nouvelle façon de sécuriser les flux de travail des développeurs

On attend des développeurs qu'ils fournissent un code de qualité plus rapidement que jamais, mais il ne fait aucun doute que des délais irréalistes peuvent conduire à une mauvaise qualité des logiciels et à un code vulnérable. Il n'est guère surprenant que 67 % des développeurs pensent qu'ils livrent du code comportant des vulnérabilités, en partie à cause de délais serrés(State of Developer-Driven Security 2022). Alors que les menaces et les violations continuent d'augmenter, la sécurité ne peut plus être une réflexion après coup, elle doit être intégrée dans l'ensemble du cycle DevSecOps.

Nous sommes ravis d'annoncer le connecteur Secure Code Warrior pour Okta Workflows, qui permet aux organisations et aux développeurs d'écrire du code sécurisé dès le début du cycle de vie du développement logiciel. Cette nouvelle collaboration entre SCW et Okta, le principal fournisseur indépendant d'identité, crée un contrôle de compétence en matière de sécurité qui permettra aux responsables AppSec d'être sûrs que l'équipe écrit du code sécurisé afin de réduire les vulnérabilités, et ce, sans que les développeurs ne sortent de leur flux de travail. De plus, nous avons ajouté l'authentification unique pour Secure Code Warrior et Okta afin de rendre encore plus simple l'utilisation de cette nouvelle solution.

Réduire le risque d'introduire des vulnérabilités

Les équipes de développement s'appuient traditionnellement sur des processus réactifs ou lents qui interviennent plus tard dans le cycle de développement, tels que les plugins, les outils d'analyse ou les révisions de code pour localiser et corriger les problèmes de sécurité - bien que ces approches présentent de nombreux avantages, elles créent tout simplement trop de risques pour le code vulnérable et les futurs remaniements. Au lieu de cela, nous sommes là pour aider les organisations à déplacer la sécurité vers la gauche et à adopter une position proactive, et non réactive, en matière de sécurité. Le nouveau connecteur Secure Code Warrior pour Okta Workflows intègre la réflexion sur la sécurité dans l'ensemble du cycle de développement en s'assurant que chaque développeur a acquis les compétences nécessaires en matière de codage sécurisé pour se voir accorder l'accès au repo afin de valider le code. Cette intégration garantira que les développeurs apprennent les dernières pratiques de sécurité par le biais de la plateforme très attrayante de SCW et que certains des fardeaux des revues de code manuelles sont réduits, libérant ainsi des heures d'ingénierie pour livrer plus de fonctionnalités sans sacrifier la qualité.

Les responsables de l'AppSec et de l'ingénierie s'appuient sur le vaste site Plateforme D'apprentissage de SCW pour créer des évaluations et des parcours personnalisés afin de s'assurer que les développeurs se concentrent sur vos besoins prioritaires en matière de codage sécurisé et qu'ils acquièrent l'expertise nécessaire pour être sûrs qu'ils peuvent enregistrer le code. Grâce à l'étendue et à la profondeur du contenu, aux 6500+ défis de codage interactifs, aux 56+ langages:frameworks, et aux 150+ catégories de vulnérabilités, vous pouvez être sûr que pratiquement tous les besoins peuvent être satisfaits pour votre organisation.

Une fois que vous avez créé la bonne stratégie d'apprentissage pour votre équipe, les scores assessment , ainsi que le statut d'achèvement d'un cours, peuvent être utilisés pour déterminer si les développeurs ont les bonnes compétences pour construire des logiciels avec une approche de sécurité d'abord. Grâce à la nouvelle intégration avec Okta, vous pouvez désormais automatiser les autorisations pour chaque développeur en fonction de leurs scores assessment afin d'échelonner facilement l'approbation de chaque développeur à livrer du code ou d'identifier les opportunités d'amélioration de leurs compétences.

Grâce à l'expérience d'apprentissage flexible et interactive de la plateforme SCW, les développeurs s'amusent constamment pendant l'apprentissage et peuvent constater un changement dans leur approche de l'apprentissage, qui passe d'une case à cocher de conformité à une approche convaincante et utile.

Comment cela fonctionne-t-il ?

Le connecteur Secure Code Warrior pour Okta Workflows est facile à construire avec Okta Workflows sans code d'automatisation d'identité et de configuration d'orchestration, en utilisant la logique if-then. Le connecteur utilise un ensemble d'actions qui vous aident à exécuter des tâches de flux de travail sans vous soucier des complexités sous-jacentes des appels API et de la configuration.

Une conception simple pour sécuriser le flux de travail de votre développeur ressemble à ceci :

Voici un aperçu de la conception complète du flux de travail :

‍

Passons en revue les différentes étapes :

1. Configurez l'identifiant assessment utilisé pour déterminer le niveau de sécurité d'un développeur. Ajoutez également les détails de GitHub, tels que l'organisation et le dépôt, dans le cadre de la configuration.

2. En utilisant l'action appelée Check Assessment Completion For User, le flux de travail vérifie si un développeur a passé avec succès une assessment particulière.

‍

3. Si le cours souhaité/assessment a été complété ou qu'un score particulier a été atteint, utilisez le connecteur GitHub pour accorder l'accès au référentiel. Si la condition n'est pas remplie, une notification peut être générée ou un autre workflow Okta peut être déclenché pour prendre les mesures appropriées.

‍

Ce système peut être conçu pour fonctionner comme un contrôle unique, périodique ou continu, de sorte qu'il continue à n'admettre que les développeurs éligibles dans le flux de travail sécurisé.

Voici quelques-unes des autres actions possibles du connecteur SCW :

• List Assessment Attempts For User - liste toutes les tentatives d'un utilisateur pour une assessment
• Vérifier l'achèvement d'un cours pour un utilisateur - détermine si un utilisateur a terminé un cours spécifié.
• List Course Enrollments For User - liste toutes les inscriptions d'un utilisateur à un cours particulier.
• Action API personnalisée - pour exécuter un appel API autre que ceux qui sont possibles par le biais des actions disponibles.

Publier plus rapidement et en toute confiance un code sécurisé de haute qualité

SCW Connector contribue à réduire le risque d'introduction de vulnérabilités au début du cycle de vie du développement logiciel. Tout comme les révisions de code et les outils d'analyse, il joue le rôle d'une barrière de qualité pour s'assurer que les développeurs écrivent un code sécurisé dès le départ. Par conséquent, moins de temps est consacré à la révision du code et à la correction des problèmes évitables, et l'accent est mis sur la livraison plus rapide d'un code de qualité. En outre, le connecteur contribue également à promouvoir une culture de la sécurité en encourageant les développeurs à s'engager de manière proactive sur le site Plateforme D'apprentissage de SCW afin de maintenir leurs compétences en matière de sécurité. Comme les développeurs continuent d'apprendre et d'améliorer leur maturité en matière de sécurité, les vulnérabilités continuent de diminuer dans le nouveau code. Cela allège le fardeau de l'équipe AppSec en matière de soutien à la remédiation, ce qui lui permet de se concentrer davantage sur le renforcement de la posture de sécurité globale de l'organisation.

Le Secure Code Warrior Connector for Okta Workflows, ainsi que notre Plateforme D'apprentissagepeut aider les organisations à atteindre leur objectif de déplacer la sécurité vers la gauche, plus rapidement, en augmentant les compétences des équipes de développement en matière de sécurité.

Contactez-nous pour planifier une démonstration ou consultez la documentation pour découvrir plus de détails sur l'installation et la configuration.

‍

Sur Secure Code Warrior, nous innovons constamment pour améliorer l'expérience de nos clients et ajouter de la valeur à la plateforme.

Ce mois-ci, nous avons publié de nouvelles mises à jour de l'expérience d'administration de Courses , la possibilité d'obtenir un accès anticipé aux nouvelles fonctionnalités avec moins de temps d'attente, et le contenu SAP:ABAP.

Désormais, les administrateurs peuvent gérer plus facilement Courses avec une meilleure expérience pour l'utilisateur final, grâce à une vue tabulaire puissante avec la possibilité d'effectuer des actions en masse dans les langues et les catégories de vulnérabilités. De plus, vous pouvez désormais bénéficier d'un accès anticipé aux nouvelles fonctionnalités à l'aide d'un simple interrupteur.

Plongeons dans le vif du sujet et découvrons-en plus !

Créez et gérez courses plus facilement grâce à notre nouvelle expérience de création de Courses

Désormais, vous pouvez facilement concevoir et déployer Courses sur plusieurs parcours de formation et dans plusieurs langues par le biais d'actions groupées. Au lieu de prendre le temps de reproduire le processus, vous pouvez vous concentrer sur le contenu et la stratégie pour aider vos développeurs à apprendre plus efficacement.

Actuellement, les mises à jour du flux de création de Courses sont disponibles pour les administrateurs de l'entreprise.

Gagnez du temps dans la conception de Courses grâce à une vue tabulaire et à une expérience de recherche puissantes.

Les informations sur les cours dans toutes les langues et catégories de vulnérabilités sont désormais accessibles dans une vue unique, ce qui vous permet de créer plus facilement et plus rapidement courses pour différentes équipes de développement.

Grâce à la nouvelle vue tabulaire, vous pouvez facilement avoir une vue d'ensemble du contenu en un coup d'œil ou approfondir les détails. Le contenu des cours est également plus facile à parcourir, car il est regroupé par catégories de langues et de vulnérabilités, avec des détails supplémentaires, tels que les types d'activités, la difficulté, et plus encore à chaque niveau de groupe.

Vous pouvez même les restreindre aux détails qui vous intéressent en utilisant la fonction de recherche ou en appliquant des filtres. En outre, les données du tableau peuvent être exportées dans une autre application ou analysées plus en détail en exportant toutes les lignes ou des lignes filtrées dans un fichier CSV.

‍

Faites-en plus avec moins de clics grâce aux actions groupées

Vous pouvez apporter des modifications en masse au cours à partir d'un seul endroit au lieu d'appliquer les changements à toutes les langues. Les actions groupées permettent aux administrateurs de gagner du temps et de se concentrer sur l'essentiel, à savoir la conception d'une expérience de cours adaptée aux développeurs.

Les nouvelles actions en bloc sont les suivantes

• Ajoutez un thème de cours, tel que le Top 10 de l'OWASP ou des catégories de vulnérabilités spécifiques pour toutes les langues.
• Ajoutez des langues à un cours et mettez le contenu à jour rapidement
• Copier, verrouiller ou déverrouiller des modules pour les lignes sélectionnées ou pour toutes les lignes
• Supprimer des langues ou des modules du cours
• Créez un message de bienvenue et de fin de cours en une seule fois pour toutes les langues.

‍

Parcours de fin d'études assessment

Vous pouvez désormais adapter le site assessment à chaque langue et le gérer à partir d'une vue unique.

Vous pouvez facilement créer des parcours assessment personnalisés, basés sur la langue et les types de cours, afin de mesurer et d'évaluer les compétences à l'issue des cours.

Bénéficier d'un accès anticipé aux nouvelles fonctionnalités

‍

Auparavant, si vous souhaitiez connaître les nouvelles fonctionnalités et les essayer avant leur disponibilité générale, vous deviez vous adresser à vos Customer Success Managers et attendre que notre équipe active les fonctionnalités pour vous.

Désormais, vous pouvez contrôler quand et quelle fonction doit être activée pour votre équipe, d'un simple basculement dans l'onglet Administration. Plus besoin de temps d'attente.

Il vous suffit de vous rendre à l'adresse suivante Administration > Plus d'informations > Accès anticipé pour l'essayer.

Cette fonctionnalité sera utilisée pour davantage de fonctions, en particulier celles qui impliquent des changements significatifs dans l'expérience des utilisateurs, vous permettant ainsi de mieux contrôler votre expérience.

Vous êtes curieux de savoir quelles sont les fonctionnalités disponibles en accès anticipé ? Découvrez quelques-unes des options actuelles :

> Une vue améliorée de la page d'accueil pour une expérience plus unifiée

> Courses updates :

1. Mode de prévisualisation de l'état
2. Actions en masse sur le contenu des cours
3. Message de bienvenue global
4. Amélioration des activités en fin de parcours

Actuellement, les options d'accès anticipé sont disponibles pour les administrateurs d'entreprise.

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

Désormais, les développeurs qui codent en ABAP peuvent participer à une formation très intéressante et pertinente sur le codage sécurisé ! Cette nouvelle formation aidera les développeurs à améliorer leurs compétences en matière de codage sécurisé et à réduire les vulnérabilités du code ABAP.

Avec les défis de codage Secure Code Warrior et Missions (laboratoires pratiques), vous pouvez proposer un programme qui couvre les aspects suivants :

1. Une formation à son propre rythme que les développeurs peuvent suivre au moment où ils en ont besoin.
2. Des parcours d'apprentissage ciblés qui s'alignent sur la conformité, les cadres de sécurité ou les niveaux de compétence des développeurs.
3. Compétitions de codage amusantes
4. Évaluations des compétences en matière de codage sécurisé

Pour en savoir plus sur nos formations ABAP, cliquez ici.

------

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

Voilà pour les nouvelles fonctionnalités de ce mois-ci ! Suivez Secure Code Warrior sur Twitter pour obtenir des informations sur les dernières versions et améliorations.

Aujourd'hui, nous sommes heureux d'annoncer que le contenu de la formation SAP:ABAP est disponible sur Secure Code Warrior! Vous pouvez vous assurer que vos équipes de développement ABAP reçoivent le soutien dont elles ont besoin pour livrer un code de qualité plus rapidement, avec moins de retouches et moins de vulnérabilités grâce à SAP:ABAP :

• Formation à son rythme
• Parcours d'apprentissage ciblés
• Compétitions de codage amusantes
• Évaluations des compétences en matière de codage sécurisé
• Rapports personnalisés sur les forces et les faiblesses des compétences en matière de codage sécurisé

ABAP (Advanced Business Application Programmation) est le principal langage utilisé par plus de 19 000 entreprises pour coder leurs applications commerciales sur les plates-formes SAP. Au total, ces entreprises génèrent jusqu'à 87 % du commerce mondial, soit 46 000 milliards de dollars. Il est donc plus important que jamais de sécuriser ABAP.

Sur Secure Code Warrior, nous nous efforçons de permettre aux développeurs de sécuriser toutes les applications critiques, y compris celles qui sont écrites dans des langages de niche comme ABAP et dans des langages plus courants comme Java.

‍

‍

Si vous êtes un client existant, vous pouvez maintenant accéder au contenu sous Training, Courses, et Tournaments. N'hésitez pas à contacter votre Customer Success Manager si vous avez des questions 🙂 .

Comment Secure Code Warrior aide à sécuriser les applications ABAP critiques pour l'entreprise

ABAP étant un langage de niche, il est rarement inclus dans les plates-formes de formation. Par conséquent, lorsque les entreprises essaient de former leurs développeurs, elles le font par le biais de programmes trop coûteux et inefficaces, comme des ateliers ponctuels.

Avec Secure Code Warrior, vous bénéficiez d'une solution de formation continue et efficace.

Notre contenu de formation est fourni dans le format préféré des développeurs - extraits de code et échantillons. Vous pouvez donc être certain qu'ils utiliseront et apprécieront le contenu.

De plus, grâce à la profondeur et à l'étendue de notre contenu et à notre système d'apprentissage par paliers, les développeurs ABAP bénéficient du soutien continu dont ils ont besoin pour améliorer progressivement leurs compétences en matière de codage sécurisé. Cette expérience d'apprentissage progressif permet aux développeurs d'acquérir une mémoire musculaire et de mettre en pratique ce qu'ils apprennent dans leurs projets.

‍

Apprenez à identifier les vulnérabilités et les modèles de codes sécurisés à travers des défis de codage.

‍

Nous savons que les développeurs travaillent mieux dans des environnements qui leur sont familiers. C'est pourquoi nous présentons nos défis de codage dans une interface de type éditeur de code.

Les développeurs peuvent naviguer dans les fichiers et les lignes de code pour localiser, identifier et corriger les vulnérabilités ABAP dans les bases de code fonctionnelles. Au cours de la formation, les développeurs apprennent à reconnaître les modèles de code vulnérables et les correctifs appropriés, ce qui permet de détecter plus rapidement les vulnérabilités et d'y remédier plus vite.

ABAP est le dernier ajout à notre offre de langues, les mêmes avantages sont disponibles pour les 57 autres langues (et plus) que nous couvrons sur la plateforme.

J'ai vu des remédiations de vulnérabilités se produire comme résultat direct du déploiement de la formation Secure Code Warrior® parce que mes développeurs diront des choses comme "Je me souviens que j'ai appris 'ceci' dans la formation Secure Code Warrior®, donc je crée un ticket pour résoudre le problème de sécurité ici".

Nicole Smith, Responsable de la sécurité, Komodo Health

Devenez un développeur averti en matière de sécurité grâce à des simulations immersives dans le monde réel.

‍

Une fois que les développeurs ABAP se sont familiarisés avec les pratiques de base en matière de codage sécurisé. Ils peuvent se mettre au défi de devenir des champions de la sécurité en jouant à Missions.

Missions sont nos terrains de jeu simulés permettant aux développeurs d'exploiter une vulnérabilité spécifique. En observant l'impact d'un exploit sur une application fonctionnelle en temps réel, ils peuvent mettre en pratique des compétences offensives en matière de codage sécurisé et s'en servir pour protéger leurs projets.

Relevez les défis du codage ABAP

Grâce au contenu le plus récent pour ABAP, vous pouvez proposer un programme de formation progressif pour les développeurs de manière simple et efficace.

Les clients existants de Secure Code Warrior peuvent accéder au contenu de la formation par le biais de Formation, Courses, Tournament, , et Assessment les modes de jeu.

Si votre équipe n'a pas encore adopté notre solution, pourquoi ne pas essayer nos défis de codage ABAP dès aujourd'hui ?

ABAP est l'un des nombreux langages disponibles

Nous proposons des formations pour 57 autres langages, y compris les plus populaires(Java et C++) et les étoiles montantes(GO et Typescript). Consultez la liste complète des langages pris en charge et essayez de relever des défis de codage dans le cadre de votre choix dès aujourd'hui.