Información sobre el código de seguridad

Durante años, los responsables de seguridad han invertido mucho en programas de codificación segura, pero una pregunta fundamental sigue sin respuesta: ¿Sabemos realmente quién está introduciendo código y posee las habilidades necesarias para escribir, revisar y, en última instancia, entregar código seguro?

Los enfoques tradicionales de "cambio a la izquierda" dejan a las empresas luchando con enormes puntos ciegos cuando se trata de descubrir e incorporar desarrolladores para programas de codificación segura. Como los administradores de programas dependen de comprobaciones manuales, hojas de cálculo y estructuras orgánicas de RR.HH. para realizar un seguimiento de las habilidades de codificación segura de los desarrolladores, a menudo surgen "desarrolladores en la sombra" que contribuyen con código a través de bases de código críticas pero carecen de competencia en seguridad. Esta realidad socava gravemente los objetivos de un SDLC seguro y complica la gobernanza, dificultando la demostración de la competencia en materia de seguridad a la hora de enfrentarse a revisiones internas o externas.

Secure Code Warrior's Trust Agent elimina este riesgo, transformando su programa de codificación segura en una defensa verificable y supervisada continuamente que proporciona a los responsables de seguridad de aplicaciones y a los CISO la confianza necesaria para demostrar que sus desarrolladores poseen la competencia necesaria en materia de seguridad en cada commit.

Supervisión y garantía continuas con el agente fiduciario

Sin una supervisión continua, el riesgo para los desarrolladores permanece oculto. Trust Agent ofrece una visibilidad continua al hacer operativa la seguridad en el nivel de confirmación del código.

Descubrimiento continuo del desarrollador: Conocer el alcance

Antes de asegurar su código base, debe saber quién lo está tocando.

Trust Agent explora automáticamente sus repositorios integrados para descubrir a todos los contribuidores de código activos en toda su base de código. Esto ayuda a abordar un reto crítico de la incorporación, un proceso continuo, y responde a la pregunta: ¿sabe cuándo se incorporan nuevos ingenieros o contratistas, y si están recibiendo formación inmediata y relevante sobre codificación segura? Mediante la supervisión continua de los commits, nos aseguramos de que todos los desarrolladores sean identificados inmediatamente y de que su viaje hacia la codificación segura pueda comenzar, eliminando los retrasos típicos de la incorporación y garantizando el alcance integral del programa.

‍

Competencia verificada: Supervisar el código, no sólo la finalización del aprendizaje

Además de descubrir a todos los contribuidores de código, Trust Agent transforma los datos de aprendizaje en pruebas fehacientes mediante la supervisión continua de las habilidades de codificación segura aplicadas en tiempo real. Proporciona una profunda capacidad de observación mediante la correlación de cada confirmación de código con la competencia de codificación segura específica del lenguaje verificada del desarrollador.

Esto es crucial para mandatos como PCI DSS 4.0 (Requisito 6.2.2), que exige específicamente la formación en código seguro cada 12 meses en el lenguaje o marco en el que los desarrolladores envían el código. Trust Agent le proporciona las pruebas auditables necesarias para demostrar que la competencia en seguridad está alineada con los lenguajes y marcos de trabajo utilizados en sus aplicaciones críticas.

Además, Trust Agent proporciona información inmediata sobre su postura de riesgo al señalar qué equipos o repositorios de código tienen grandes volúmenes de commits de desarrolladores sin los conocimientos de seguridad adecuados. Esta visibilidad permite a los administradores del programa asignar fácilmente la formación adecuada a los desarrolladores adecuados basándose en los datos más relevantes en tiempo real.

Gobernanza integrada y control de las políticas

En última instancia, la gobernanza debe aplicarse para reducir realmente el riesgo para la seguridad de los desarrolladores. Trust Agent ofrece la posibilidad de hacer obligatoria la competencia en seguridad trasladando los controles directamente a los flujos de trabajo de desarrollo existentes, con la capacidad de definir políticas de confirmación basadas en la tolerancia al riesgo de su organización. Trust Agent automatiza la gobernanza directamente en el flujo de trabajo de confirmación, con puertas de políticas que pueden configurarse para registrar, advertir o bloquear solicitudes de extracción si el nivel de conocimientos de codificación segura de un desarrollador es insuficiente. Esta gobernanza integrada es la clave para garantizar realmente que la seguridad es un requisito y no una sugerencia opcional.
‍

Garantizar el futuro del desarrollo

El paso a una competencia verificable en codificación segura no consiste solo en pasar auditorías; al fin y al cabo, se trata de enviar código innovador y seguro. Incluso o especialmente con el aumento del desarrollo asistido por IA, el principio fundamental sigue siendo: los desarrolladores deben ser competentes en seguridad para reducir realmente el riesgo. Al hacer que la competencia en codificación segura de los desarrolladores sea un requisito medible, SCW Trust Agent es la pieza crítica que garantiza que su organización no solo cumpla las obligaciones normativas y de conformidad, sino que refuerce fundamentalmente su postura de seguridad desde dentro.

Para obtener más información, reserve una demostración o póngase en contacto con su Gestor de Éxito de Clientes hoy mismo.

‍

Le développement assisté par l'IA n'est plus à l'horizon : il est là, et il redéfinit rapidement la façon dont les logiciels sont écrits. Des outils tels que GitHub Copilot, Cline, Roo, Cursor, Aider et Windsurf transforment les développeurs en leurs propres copilotes, permettant des itérations plus rapides et accélérant tout, du prototypage aux grands projets de refactoring.

Mais ce changement s'accompagne d'une tension familière : rapidité contre sécurité.

Chez Secure Code Warrior, nous avons beaucoup réfléchi à la manière d'aider les développeurs à rester en sécurité lorsqu'ils travaillent avec des outils de codage basés sur l'IA. C'est pourquoi nous sommes ravis de lancer quelque chose de simple, puissant et immédiatement utile : notre Règles de sécurité de l'IA — une ressource publique et gratuite accessible à tous sur GitHub. Vous n'avez pas besoin d'être un client de Secure Code Warrior pour les utiliser ; nous fournissons ces règles sous la forme d'une base communautaire gratuite que chacun peut adopter et étendre à ses propres projets.

Ces règles sont conçues pour servir de garde-fou, incitant les outils d'IA à adopter des pratiques de codage plus sûres, même lorsque les développeurs évoluent à une vitesse vertigineuse.

Résumé pour les plus pressés :

Alors que les outils de codage d'IA tels que Copilot et Cursor deviennent essentiels au développement moderne, la sécurité ne doit pas être une question secondaire. C'est pourquoi nous avons élaboré un ensemble de règles légères et axées sur la sécurité, conçus pour guider la génération de code d'IA vers des valeurs par défaut plus sûres.

• Couvre le frontend Web, le backend et les appareils mobiles
• Accès facile aux outils d'IA
• Public, gratuit et prêt à être intégré à vos propres projets

Découvrez les règles → https://github.com/SecureCodeWarrior/ai-security-rules

Faisons du codage sécurisé la valeur par défaut, même avec l'IA au clavier.

1. Pourquoi les règles sont importantes à l'ère du codage assisté par l'IA

Les outils de codage de l'IA sont incroyablement utiles, mais ils ne sont pas infaillibles. Bien qu'ils puissent générer rapidement du code fonctionnel, ils n'ont souvent pas les nuances nécessaires pour comprendre les normes, conventions et politiques de sécurité spécifiques d'une équipe ou d'un projet donné.

C'est là que les fichiers de règles au niveau du projet entrent en jeu.

Les outils d'IA modernes tels que Cursor et Copilot prennent en charge les fichiers de configuration qui influencent la façon dont le code est généré. Ces fichiers de règles agissent comme un murmure à l'oreille de l'IA et lui indiquent :

« Dans ce projet, nous ne concaténons jamais de chaînes SQL. »
« Préférez la récupération avec des en-têtes sécurisés aux valeurs par défaut non sécurisées. »
« Évitez d'utiliser eval () sauf si vous souhaitez un audit de sécurité. »

Ces règles ne constituent pas une solution miracle, ni un substitut à de solides pratiques de révision du code et à des outils de sécurité, mais elles peuvent aider à aligner le code généré par l'IA sur les pratiques que les équipes suivent déjà ou devraient suivre pour un développement sécurisé.

2. Ce que nous avons construit (et ce que nous n'avons pas construit)

Nos règles de démarrage sont disponibles dès maintenant dans dépôt GitHub public. Ils sont :

• Organisé par domaine, y compris le frontend Web, le backend et le mobile
  
• Axé sur la sécurité : couverture des problèmes récurrents tels que les failles d'injection, la manipulation non sécurisée, la protection CSRF, les faibles flux d'authentification, etc.
  
• Légers de par leur conception, ils sont conçus comme un point de départ pratique et non comme un livre de règles exhaustif

Nous connaissons la valeur de vos fenêtres contextuelles d'IA et la rapidité avec laquelle le code consomme ces jetons. Nous avons donc veillé à ce que nos règles soient claires, concises et strictement axées sur la sécurité. Nous avons délibérément pris la décision d'éviter les directives spécifiques à un langage ou à un framework, en optant plutôt pour des pratiques de sécurité largement applicables et à fort impact qui fonctionnent dans un large éventail d'environnements sans avoir d'opinion sur l'architecture ou le design.

Ces règles sont écrites pour être facilement intégrées dans les formats de configuration pris en charge par les outils d'IA, avec peu ou pas de refactorisation. Considérez-les comme un ensemble de politiques de départ qui incitent l'IA à adopter des paramètres par défaut sécurisés.

3. Une nouvelle couche de défense

Voici à quoi cela ressemble en pratique :

• Lorsque l'IA suggère un code qui gère les entrées de l'utilisateur, elle privilégie la validation et l'encodage, et non le simple traitement.
  
• Lors de la création de requêtes de base de données, il est plus probable de recommander le paramétrage, et non la concaténation de chaînes.
  
• Lors de la génération de flux d'authentification frontaux, l'IA sera plus susceptible de promouvoir les meilleures pratiques en matière de gestion des jetons, et non des piratages de stockage local non sécurisés.

Rien de tout cela ne remplace la gestion stratégique des risques pour les développeurs dans le cadre d'un programme de sécurité, y compris le renforcement continu des compétences en matière de sécurité. Cela n'élimine pas non plus le besoin de développeurs compétents en matière de sécurité, d'autant plus qu'ils demandent de plus en plus de LLM et examinent le code généré par l'IA. Ces garde-fous ajoutent une couche de défense significative, en particulier lorsque les développeurs agissent rapidement, effectuent plusieurs tâches à la fois ou font simplement un peu trop confiance à l'outil.

Quelle est la prochaine étape ?

Il ne s'agit pas d'un produit fini, mais d'un point de départ.

À mesure que les outils de codage de l'IA évoluent, notre approche en matière de développement sécurisé doit également évoluer. Notre Règles de sécurité de l'IA sont libres d'utilisation, adaptables et extensibles à vos projets. Nous nous engageons à faire évoluer ces règles en permanence, et nous aimerions avoir votre avis. Essayez-les et dites-nous ce que vous en pensez.

Découvrez les règles sur GitHub
Consultez la directive relative aux règles d'utilisation dans SCW Explore

Le codage assisté par l'IA redéfinit déjà la façon dont nous créons des logiciels. Faisons en sorte qu'il soit sécurisé dès le départ.

De nos jours, presque toutes les équipes de développeurs proposent une forme ou une autre de formation à la conformité, que ce soit dans le cadre d'un processus de certification initial utilisé pour garantir qu'une entreprise respecte les limites des cadres industriels ou des réglementations gouvernementales, ou dans le cadre d'une exigence ou d'une révision annuelle. Il s'agit d'une étape importante, car si une organisation ne parvient pas à satisfaire aux exigences de conformité de base, ses employés ne pourront pas s'acquitter de 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 respect des exigences minimales obligatoires ne garantit pas une véritable sécurité des applications. Cela est particulièrement vrai pour les développeurs qui essaient d'intégrer des compétences de codage sécurisé dans leur flux de travail quotidien. Presque tous les développeurs suivent une forme ou une autre de formation à la conformité, et pourtant, selon une enquête, 67 % ont admis qu'ils laissaient souvent des vulnérabilités dans leur code.

Pourquoi ?

Pour la deuxième année consécutive, Secure Code Warrior a mené une enquête sur l'état de la sécurité menée par les développeurs en 2022 en partenariat avec Evans Data Corp en décembre 2021. Nous avons interrogé 1 200 développeurs dans le monde entier afin de 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 sur le cycle de vie du développement logiciel (SDLC).

En ce qui concerne les raisons pour lesquelles la formation à la conformité ne permet pas d'améliorer la sécurité des logiciels, c'est une question dont nous parlons depuis longtemps. La récente enquête ne fait que mettre en lumière ce problème.

D'une part, les développeurs sont invités à assumer de nouveaux rôles en intégrant la cybersécurité tout au long du processus de développement logiciel, y compris lors de la rédaction initiale du code des applications et des programmes. Mais écrire du code sécurisé, ou même simplement tout apprendre sur les problèmes de cybersécurité et les vulnérabilités qui pourraient l'affecter, n'est pas une tâche facile. Dans l'enquête, 63 % des développeurs ont déclaré que l'écriture de code sécurisé était une tâche difficile.

La difficulté d'écrire du code sécurisé ne devrait pas être 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 vacants dans le monde au dernier décompte. Si c'était un travail facile, tout le monde se lancerait dans ce domaine. Il est difficile d'apprendre à combattre les menaces et à éliminer les vulnérabilités du code, et le paysage des menaces est en constante évolution. Les formations statiques sur la conformité ou les cours ponctuels ne peuvent pas suivre le rythme ou fournir le type de formation dont les développeurs ont besoin. Il peut cocher une case en termes de conformité, mais ne peut pas fournir de réelles garanties de sécurité des applications à votre organisation, ni permettre aux développeurs d'écrire du code sécurisé, ni acquérir les compétences nécessaires pour détecter et corriger les vulnérabilités du code.

La formation à la conformité et à la sécurité est importante, mais différente

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

Les cadres de conformité qui les intéressaient le plus à la formation comprenaient ceux qui sont spécifiques à divers secteurs, bien que plusieurs cadres généraux de cybersécurité aient également figuré sur la liste. Il s'agissait notamment du cadre de sécurité de la CEI, de la norme PCI DSS, du Top 10 de l'OWASP, de la MISRA C, de l'ISO/IEC, de la loi HIPAA (Health Insurance Portability and Accountability Act).

Alors oui, entraînez-vous à utiliser ces frameworks, mais sachez que cocher une case sur la formation à la conformité ne signifie pas fournir une base pour la création continue de code sécurisé.

Considérez plutôt la formation à la conformité comme une opportunité continue de développer les compétences de codage sécurisé de votre développeur, qui peuvent être répétées en dehors du cycle de conformité, afin qu'il puisse créer et publier des logiciels sécurisés chaque jour. Ne donnez plus la priorité à la mise en conformité, mais permettez aux équipes de développement de coder en toute sécurité grâce à un apprentissage continu. En investissant du temps et des ressources dans l'habilitation des développeurs, les exercices ou examens annuels de conformité aux cases à cocher deviendront un jeu d'enfant pour votre personnel, tout en bénéficiant d'une productivité globale améliorée.

Comment passer à une sécurité pilotée par les développeurs ?

Les développeurs ont déclaré à une écrasante majorité que la formation était utile, mais ont contesté le type de formation qu'ils ont reçu au fil des ans en matière de codage sécurisé. Les développeurs ont indiqué qu'ils souhaitaient que l'accent soit davantage mis sur la formation pratique à l'aide d'exemples concrets pertinents pour leur travail (30 %). Une plus grande interactivité était également considérée comme essentielle par 26 % des personnes interrogées, en particulier s'ils pouvaient réellement s'entraîner à écrire du code sécurisé dans le cadre de ces exercices.

23 % des développeurs interrogés ont estimé qu'ils souhaitaient bénéficier d'une formation plus guidée axée sur les vulnérabilités spécifiques qu'ils étaient les plus susceptibles de rencontrer dans leur secteur d'activité ou leur secteur d'activité, tandis que 22 % souhaitaient voir davantage d'exemples de vulnérabilités réelles dans leurs cours de formation.

Il est clair que le simple fait de proposer une formation statique et non interactive (ce qui constitue généralement l'expérience de 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 entreprises devraient plutôt se concentrer sur des éléments tels que la formation juste à temps, qui permet aux développeurs d'apprendre les notions de sécurité au fur et à mesure de leur travail. Vous pourriez même envisager de mettre en œuvre un programme d'apprentissage à plusieurs niveaux.

Dans le cadre d'une approche par étapes, les sujets plus vastes sont généralement divisés en expériences ou concepts d'apprentissage distincts. Au fur et à mesure que les développeurs progressent, des concepts plus avancés s'ajoutent à ceux déjà maîtrisés, tout comme un échafaudage physique est construit à 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 parties plus petites et moins complexes, puis en renforçant la complexité sur cette base.

Quelle que soit la manière dont vous déciderez d'aborder votre programme de compétences en matière de sécurité pour les développeurs, il sera essentiel de le séparer des exercices de conformité. La formation à la conformité et à la sécurité est importante, et toutes deux nécessitent des approches différentes pour réussir.

Pour en savoir plus

Livre blanc : Les défis (et opportunités) liés à l'amélioration de la sécurité logicielle.

Livre blanc : L'approche préventive des développeurs en matière de sécurité logicielle.

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

Les 10 mêmes vulnérabilités logicielles ont causé plus de failles de sécurité au cours des 20 dernières années que tout autre. Pourtant, de nombreuses entreprises optent toujours pour des mesures correctives après une violation ou un événement, tout en confondant les conséquences humaines et commerciales de tout cela. Mais aujourd'hui, une nouvelle étude indique une nouvelle direction, dirigée par l'homme.

‍Ce qui suit présente les conclusions d'une étude menée par Secure Code Warrior avec Evans Data Corp intitulée « Shifting from reaction to prevention : The changing face of application security » (2021) explorant les attitudes des développeurs à l'égard du codage sécurisé, des pratiques de code sécurisées et des opérations de sécurité. Téléchargez le livre blanc ici.

‍‍Dans l'étude qui sera bientôt publiée, les développeurs et les responsables du développement ont été interrogés sur les activités qu'ils associent au codage sécurisé. Les trois réponses les plus fréquentes étaient les suivantes :

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

Alors, qu'est-ce que cela nous apprend ? Deux des trois réponses les plus fréquentes sont toujours axées sur les approches réactives, la première dépendant de l'outillage (scanners), et la seconde du fait que le développeur (c'est-à-dire l'homme) effectue des vérifications manuelles, dans les deux cas après le code est écrit. Les vulnérabilités détectées à l'aide de ces méthodes doivent être renvoyées à l'équipe de développement pour être retravaillées, avec des répercussions sur les délais et les coûts des projets.

Dans le même temps, deux des trois activités proposées font appel à l'élément humain, ce qui témoigne de la perception croissante de la sécurité en tant que problème humain. Mais de toutes les activités nominées, la plus révélatrice est la troisième, qui identifie le facteur humain un logiciel écrit qui est protégé contre les vulnérabilités en premier lieu. Cela met en évidence un changement vers la gauche : une approche proactive et préventive qui intègre la sécurité dans les logiciels dès le début du cycle de vie de développement logiciel.

Réactif peut être cher

Selon une étude d'IBM*, il est trente fois plus coûteux de corriger des vulnérabilités dans le code postérieur à la publication que si elles étaient détectées et corrigées au début. Il s'agit d'une puissante incitation à adopter une nouvelle approche proactive et plus humaine de la défense de la sécurité logicielle, qui permet aux développeurs de coder de manière plus sécurisée, dès le départ.

C'est ce que l'on pourrait appeler défense dirigée par l'homme. Mais pour que les développeurs commencent à se préoccuper de la sécurité, celle-ci doit faire partie intégrante de leur façon de penser et de coder au quotidien. Il s'agit d'un appel en faveur de nouvelles approches de formation qui soient très pertinentes pour le travail quotidien des développeurs et les incitent à vouloir apprendre, ce qui n'est pas le cas des modèles de formation actuels.

Pour créer une culture de sécurité proactive, une nouvelle formation est nécessaire pour :

• fait du codage sécurisé une expérience positive et engageante pour les développeurs qui améliorent leurs compétences en matière de sécurité logicielle
• encourage les développeurs à envisager leurs tâches de codage quotidiennes dans une optique de sécurité
• intègre le codage sécurisé à leur flux de travail quotidien
  

Lorsque ces fils de discussion sont réunis, les vulnérabilités sont évitées dès le départ, ce qui permet aux équipes d'expédier code de qualité plus rapidement, en toute confiance. La bonne nouvelle, c'est qu'il existe déjà une plateforme d'apprentissage qui « commence à gauche » dans le processus de développement logiciel, une plateforme qui donne déjà aux développeurs les compétences et les outils nécessaires pour créer du code de qualité dès le début.
‍‍

‍

*IBM Software Group ; réduction des défauts de code pour améliorer la qualité des logiciels et réduire les coûts de développement
https://docplayer.net/11413245-Minimizing-code-defects-to-improve-software-quality-and-lower-development-costs.html

Une version de cet article a été publiée dans Lecture sombre. Il a été mis à jour et diffusé ici.

Lorsque je parle de sécurité aux développeurs, l'un de mes mantras est que « le seul code de qualité est un code sécurisé ». Cela reste vrai ; nous aurions peut-être échappé à la catastrophe lorsque des logiciels vulnérables sont apparus dans la nature dans les années 90, mais le risque n'en vaut pas la peine aujourd'hui. Beaucoup ont travaillé d'arrache-pied pour inculquer aux développeurs un état d'esprit soucieux de la sécurité au fil des ans et, ce faisant, ils ont, espérons-le, fait de la sécurité un synonyme de qualité lorsqu'il s'agit d'auto-évaluer leur code.

Après réflexion (et après quelques débats entre pairs), cela simplifie peut-être trop le concept. Il est tout à fait possible de créer un code qui soit effectivement sécurisé, mais qui présente des signes de technique de développement novice ou d'autres problèmes qui le rendent loin d'être idéal.

Notre industrie parle longuement de la notion de « glissement vers la gauche ». À mon avis, il s'agit de « repartir » vers la gauche en permettant aux cohortes d'ingénieurs de partager la responsabilité de la sécurité (en tant qu'aspect de la qualité) et en leur donnant le pouvoir d'effacer les vulnérabilités courantes du bout des doigts (littéralement). À la lumière de cette énigme actuelle, il semble toutefois que les limites doivent être repoussées un peu plus loin.

Un code d'un certain niveau de qualité est par définition également sécurisé, mais tout code sécurisé n'est pas nécessairement de bonne qualité. Commencer « à gauche de gauche » est-il la formule pour garantir des normes de codage purement sécurisées ?

À quoi ressemble un code sécurisé « de mauvaise qualité » ?

Passons la loupe à la loupe à cet extrait de code :

Si nous analysons ce code du point de vue de la sécurité, cet extrait est en effet sécurisé et ne constitue pas un point d'entrée permettant à un attaquant d'exploiter une vulnérabilité d'injection SQL.

S'agit-il d'un exemple de code de haute qualité ? Pas vraiment, malheureusement. Une simple modification de l'argument d'un int (entier) à un Corde value permet à l'utilisateur de saisir librement la requête, contrairement à un nombre qui ne le peut pas. Ce changement, ou un copier-coller aléatoire de la chaîne sql depuis un autre endroit, crée immédiatement un environnement dans lequel des vulnérabilités d'injection SQL sont possibles, avec tous les risques qui y sont associés :

Les mesures de sécurité avaient une portée très limitée ici, alors qu'un développeur plus minutieux (ou expérimenté) aurait peut-être adopté une approche différente et envisagé les implications d'une structure d'arguments inefficace. Un code d'expédition comme celui-ci n'est pas seulement une mauvaise pratique, mais aussi un mauvais exemple pour les autres membres de la cohorte de développement.

La « triple menace » logicielle : forme, fonction, forteresse ?

Une « triple menace » dans l'industrie du divertissement est une personne capable de jouer, de danser et de chanter avec un niveau de compétence tout aussi élevé. Ce sont les personnes redoutées et enviées à chaque audition, et ce sont les licornes d'un espace déjà compétitif. Chaque secteur possède sa propre version d'un exemple exceptionnel de ses produits et services, les logiciels ne faisant pas exception.

Si nous pensons à trois éléments clés des applications qui sont difficiles à équilibrer avec une qualité (élevée) égale, ils peuvent être la fonctionnalité et l'élégance, une sécurité irréprochable et la rentabilité compte tenu de la rapidité de livraison requise. Ce dernier attribut est sans aucun doute un facteur déterminant dans la manière dont les deux autres options sont appliquées, et il peut être le catalyseur d'une baisse de la qualité globale au fil du temps.

Cependant, tous les logiciels doivent-ils fonctionner comme Hugh Jackman, ou pouvons-nous nous en tirer avec Nicolas Cage ? En d'autres termes, si vous pouvez intégrer Wolverine dans votre équipe, vous faites de votre mieux.

Martin Fowler a posé la question, La haute qualité en vaut-elle le coût ? dans le développement de logiciels, en concluant que non seulement cela « en valait la peine », mais que cela coûtait en fait moins cher au fil du temps. La plupart des utilisateurs ne vont pas regarder sous le capot pour déterminer si le code est un gâchis ou si la sécurité a été accordée à tout le reste. Cependant, les utilisateurs des outils perdront un temps précieux à refaire du code bâclé pour ajouter de nouvelles fonctionnalités, à parcourir les principales parties du projet pour comprendre ce qui se passe, ou, dans le pire des cas, à corriger une vulnérabilité qui a été rebondie par l'équipe AppSec et a retardé la production. Passer du temps maintenant à rendre le code à la fois sécurisé et de bonne qualité permet d'éviter bien des soucis futurs, sans parler des coûts liés à la résolution de tâches mal exécutées.

Les développeurs expérimentés soucieux de la sécurité écrivent du code qui conserve leur vision créative et leur capacité à résoudre les problèmes lors de la fourniture de fonctionnalités, en veillant à éliminer les pièges de sécurité courants que les ingénieurs peuvent contrôler à leur stade du processus. Le code sécurisé n'est pas très efficace lorsqu'il est isolé, et c'est pourquoi l'idée de commencer « de gauche à gauche » contribuera à promouvoir une culture de la sécurité considérée comme une seconde nature pour les développeurs, intégrée à leur capacité à fournir des fonctionnalités exceptionnelles avec un risque réduit.

Pour une expérience utilisateur sécurisée, il est essentiel de commencer « de gauche à gauche ».

La sécurité est prise en compte dans l'expérience utilisateur des logiciels depuis longtemps, mais elle s'est clairement soldée par un succès mitigé. Erreurs de configuration de sécurité prises en compte 21 % des violations de données basées sur le cloud au cours de l'année écoulée, des erreurs commises par des amateurs, telles que le stockage de mots de passe en texte clair, ont entraîné de graves pertes de productivité, de revenus et de confiance des clients pour les entreprises concernées.

Cela, et les utilisateurs eux-mêmes peuvent être leur pire ennemi lorsqu'il s'agit de protéger leurs propres données. Beaucoup trop de monde utilisent toujours « mot de passe » comme mot de passe, ou utilisent la même combinaison sur plusieurs comptes sensibles.

Je ne connais aucun développeur qui fasse preuve de souplesse lorsqu'on leur demande de travailler sur un écran de connexion, et ce n'est pas étonnant : concevoir un flux de sécurité robuste et fonctionnel dans lequel les utilisateurs pourront naviguer de la manière qui leur convient le mieux, avec le moins de perturbations possible, est un équilibre délicat.

Si vous introduisez trop d'étapes et de restrictions complexes, les utilisateurs risquent de se déconnecter pour ne jamais revenir (ce qui est un désastre pour une nouvelle application), de créer trop de confusion, et vous pourriez finir par donner à l'équipe d'assistance une migraine collective lorsqu'elle répondra aux questions des utilisateurs qui tentent d'accéder à leur compte. Si vous le faites trop facilement, vous échouerez en quelque sorte sur le plan de la sécurité.

Une expérience utilisateur sécurisée réussie doit intégrer une sécurité renforcée dans un flux logique, présenté de manière à ne pas nuire à tout ce qui est convaincant à propos du logiciel. Vous pouvez certainement atteindre l'objectif qui consiste à coder une fonction de connexion sécurisée, en introduisant toutes sortes de mots de passe complexes, un CAPTCHA, des mini-boss et quatre vagues de zombies, mais s'il s'agit d'un désordre total qui repousse les utilisateurs, c'est passer à côté de la cible.

Jeter les bases de l'excellence logicielle.

En tant que développeur, je sais que la grande majorité d'entre nous sont fiers de notre travail et veulent faire le bon choix. Les aléas tels que les contraintes de temps, les changements brusques de l'objectif actuel ou les correctifs urgents peuvent perturber le flux et entraîner des erreurs, mais la dure vérité est que de nombreux ingénieurs logiciels ne sont pas prêts à réussir.

Commencer « de gauche à gauche » est un concept qui donne la priorité aux développeurs et qui oblige les organisations à sérieusement améliorer leur cohorte d'ingénieurs. Les développeurs sensibilisés à la sécurité valent leur pesant d'or, et le soutien sous forme de formation, de fourniture des bons outils et de la possibilité d'être encadré par des développeurs plus expérimentés favorisera un environnement dans lequel le code est conçu avec une approche axée sur la sécurité, avec la précision et l'attention aux détails nécessaires pour faire passer les logiciels au niveau supérieur.

Êtes-vous prêt à allumer le feu du codage sécurisé en vous ? Relevez le défi.

‍

C'est cette période spéciale de l'année (pour nous, en tout cas) où je pense à notre dernier tour du soleil et à ce qui a été fait au cours des trois cent soixante-cinq derniers jours pour nous préparer à une nouvelle année pleine de croissance, de leçons et d'inévitables imprévus.

Bien que personne n'ait pu prévoir les rebondissements de l'année dernière. Après tout, je pense que la plupart d'entre nous ont affronté plus de courbes que les Los Angeles Dodgers, nous sommes toujours là. Le fait de tourner en longueur n'a pas mis fin aux difficultés de cette année qui ne peut pas être nommée, mais tout autour de moi, je constate la résilience inébranlable des individus, des entreprises et de notre secteur d'activité.

Alors, quels progrès avons-nous réalisés dans notre objectif de sécuriser le code à travers la galaxie ?

Nous avons dynamisé notre gamme de produits.

La plateforme de formation Secure Code Warrior sera toujours au cœur de nos offres, mais nous nous efforçons de créer plus de variété et d'utiliser davantage d'outils choisis par les développeurs.

Nous voulons inciter les développeurs à adopter une approche de codage préventif et sécurisée qui permet à chaque équipe de livrer des logiciels de qualité en toute confiance.

Je suis très fière de détailler ce que notre équipe produit a travaillé si dur pour déployer ; elle s'est fixé des objectifs incroyables tout au long de l'année :

• Nous avons acquis Adversary.io et intégré sa technologie, son équipe incroyablement qualifiée et ses clients professionnels en moins de 9 mois.
• Nous avons franchi une étape incroyable en soutenant plus de 50 langages de programmation, y compris l'infrastructure en tant que piliers du code tels que Docker, Ansible, Terraform, Kubernetes, Powershell et CloudFormation, ainsi que de nouveaux acteurs tels que Rust and Go.
• Apporter les connaissances en matière de sécurité au développeur en publiant de toutes nouvelles extensions pour les actions et les problèmes liés à GitHub, en plus d'Atlassian JIRA Cloud & Server, qui propose un apprentissage contextuel là où les développeurs jouent sans avoir à passer d'une tâche à l'autre
• Guidage du code de qualité en temps réel dans l'IDE avec Senseï, désormais disponible dans Place de marché JetBrains pour que chaque développeur détecte les bogues de sécurité, applique les meilleures pratiques, partage des connaissances et évite les problèmes de performances et les dettes techniques
• Permettre aux entreprises d'interagir plus facilement avec les développeurs et de développer le codage sécurisé en publiant Cours, une toute nouvelle fonctionnalité permettant des parcours d'apprentissage sélectionnés pour atteindre les objectifs les plus pertinents pour une organisation et ses objectifs de sécurité. Nous avons également ajouté Missions, une amélioration intéressante de la plateforme phare, qui place les développeurs dans le siège du pilote d'un exploit. Il s'agit de la prochaine étape d'une approche d'apprentissage échafaudée visant à donner aux développeurs une base viable et durable pour réussir.

... et si vous connaissez des débutants en programmation, ils devraient consulter l'application gratuite Secure Code Bootcamp et commencer leur parcours en matière de sécurité.

Nous avons atterri, nous nous sommes développés, nous avons influencé.

Nous aimons aborder le codage sécurisé de manière légèrement différente et, naturellement, nous espérons que cette philosophie se répandra dans l'ensemble du secteur. Il est important que les développeurs reconnaissent leur capacité à lutter efficacement contre les cyberattaquants, et leur donner le goût de l'apprentissage de la sécurité est l'un des principaux objectifs.

Des milliers de développeurs du monde entier ont participé à nos tournois virtuels, dont plus de 80 ont eu lieu rien qu'en 2020. Nous avons été ravis de voir des gens jouer dans le cadre de L'univers GitHub, mondial Cisco événements, et DevSecCon.

Nous avons examiné nos données et avons constaté que des centaines de milliers d'utilisateurs uniques avaient joué sur notre plateforme en 2020, ce qui est époustouflant quand je pense à nos débuts il y a six ans.

J'ai été très heureuse de constater que nous avions considérablement augmenté notre présence auprès des entreprises du Fortune 1000, chacune d'entre elles étant prête à essayer quelque chose de nouveau dans le cadre de ses programmes de sécurité. Nous avons trouvé une synergie avec les entreprises technologiques en particulier, dont beaucoup ont opté pour le télétravail et ont vu l'intérêt des options de formation à distance.

Team Awesome s'est agrandie et s'est renforcée ensemble.

L'une des évolutions les plus importantes que nous avons connues en tant qu'entreprise au cours de l'année écoulée a été l'acquisition de la société de cybersécurité islandaise, Adversary. Nous avions beaucoup en commun : une position similaire sur l'approche de la cybersécurité axée sur les personnes, des valeurs harmonisées et des produits complémentaires. Nous avons accueilli leur équipe au sein de la nôtre, ce qui nous a permis d'acquérir une expertise et un talent inestimables auprès de personnes formidables.

Nous avons également accueilli John Wilson en tant que vice-président des ventes mondiales, bénéficiant de ses 25 années d'expérience en matière de stimulation de la croissance et de transformation des entreprises de technologie cloud et de cybersécurité en leaders du marché. Ses vastes compétences techniques ont été une force d'innovation dans des entreprises telles que Symantec, Qualys, BlackBerry et Verizon, et nous ne pourrions être plus heureux de le voir opérer sa magie avec nous.

Le manque de bureaux physiques ne nous a pas empêchés d'intégrer soixante nouveaux employés dans cinq pays et de leur permettre de démarrer dès le départ grâce à une assistance virtuelle, des présentations et, bien sûr, le très convoité pack cadeau pour les employés livré à leur porte.

Nous avons poursuivi notre croissance dans tous les départements, tous d'une importance égale dans la réalisation de notre mission mondiale qui consiste à permettre un code de qualité rapidement. Et pourtant, j'ai toujours l'impression que nous ne faisons que commencer.

2021, l'année qui a changé la donne.

J'ai le sentiment depuis longtemps que la société ne se soucie tout simplement pas assez de la cybersécurité, et ce n'est que lorsque quelque chose d'incroyablement radical se produit que nous pouvons voir les choses changer en termes d'action et de sensibilisation.

Avec l'énorme brèche de SolarWinds survenue à la fin de l'année dernière, de plus amples détails apparaissent. L'étendue des dégâts n'est toujours pas connue, mais cet incident pourrait être le catalyseur d'un changement généralisé. Les départements du gouvernement américain sont déjà en train de remanier leurs programmes de sécurité, et le cyberespionnage est un sujet très brûlant pour ceux qui ont beaucoup à perdre.

Nous pouvons toujours mettre un peu de fun dans tout ce que nous faisons, mais le moment est venu de retrousser nos manches et de nous mettre au travail pour vraiment changer les choses.

Chaque développeur soucieux de la sécurité rend notre monde un peu plus sûr contre les cyberattaques, et notre objectif sera toujours de leur donner les connaissances nécessaires pour réussir, et peut-être même aimer ça. Nous travaillons d'arrache-pied chaque jour pour créer des outils que les développeurs choisissent d'utiliser pour en savoir plus sur la sécurité et créer un code de la plus haute qualité. Le code sécurisé devrait être la norme, et nous pouvons tous donner un coup de main pour en faire une réalité.

On dirait que la « conformité en matière de cybersécurité » est à la mode depuis des années, avec une infinité d'articles, d'initiatives et de comités discutant de la meilleure façon dont le monde devrait lutter contre l'énorme bête multimenace qu'est la cybercriminalité.

Le problème, c'est que nous ne semblons pas avoir fait cette de nombreux progrès. À l'échelle mondiale, le coût des violations de données n'a cessé d'augmenter, augmentant de 12 % en cinq ans pour s'établir à environ 3,92 millions de dollars américains par violation en 2019. Alors que notre utilisation d'Internet a explosé en quelques décennies à peine, de nombreuses entreprises ont dû se battre sans armes pour se lancer rapidement en ligne, créer leur boutique et faire face aux conséquences de logiciels non sécurisés, de ressources AppSec limitées et, dans certains cas, d'abus de confiance des clients.

De nos jours, nous sommes irréfutablement plus mûrs. Nous comprenons et discutons longuement de l'ampleur de la menace, les entreprises sont bien conscientes de l'impact qu'une cyberattaque peut avoir sur le sentiment des clients, leur réputation et leurs résultats, et de nombreuses entreprises cherchent activement à améliorer la sécurité des logiciels grâce à des formations à la conformité, à des recrutements qualifiés et, de plus en plus, à des initiatives DevSecOps. Malgré ces énormes avancées, nous ne sommes pas en train de gagner le combat, même pas de près. Il y a eu au moins quatre milliards de disques volés en matière de violations de données rien qu'en 2019.

L'un des ingrédients manquants était une répercussion quelque peu lente (au niveau gouvernemental) sur les normes de cybersécurité, les attentes et les conséquences d'une violation. L'avènement de GDPR a connu un certain essor, du moins en Europe, mais de nombreux organismes gouvernementaux sont en train de rattraper leur retard, et la nécessité soudaine de se conformer rapidement à de nouvelles initiatives de conformité pourrait avoir des effets indésirables à l'avenir.

Des imbéciles se précipitent (vers le mauvais entraînement)

Des directives robustes sous la forme de NIST, de nouvelles réglementations pour État de New York et la création du Conseil britannique de cybersécurité ont toutes été des victoires monumentales pour ceux qui mènent le bon combat pour assurer la sécurité de nos données. Ils reconnaissent les problèmes liés au développement logiciel actuel et prennent des mesures pour guider les organisations sur les normes qu'elles doivent désormais respecter pour être considérées comme éthiques et conformes, en termes de meilleures pratiques de sécurité.

Malheureusement, à ce stade, certains des éléments les plus importants sont un peu trop sujets à interprétation. Par exemple, l'un des mandats de la législation du Conseil britannique de cybersécurité est le suivant :

« Créer une liste définie de certifications et un cadre facile à comprendre expliquant comment elles sont toutes liées entre elles et quelles sont les capacités qu'elles véhiculent, en s'appuyant sur les cheminements de carrière déjà entrepris ».

Bien que leurs initiatives s'amélioreront et se développeront sans aucun doute au fil du temps, si les organisations sont déjà en train d'appuyer sur le bouton de panique et de se lancer dans la formation dès maintenant, elles pourraient bien se retrouver mal équipées pour l'avenir.

Les exigences d'une organisation en matière de cybersécurité évoluent rapidement, et il est peu probable que les solutions de formation statiques puissent endiguer le flux de logiciels non sécurisés au rythme requis. Le paysage évolue plus rapidement qu'un cours traditionnel ne peut être mis à jour, ce qui peut entraîner des difficultés à certains endroits dans le piège des exercices de conformité à cocher ; les développeurs, les sous-traitants et les autres professionnels de la sécurité ne reçoivent pas une formation adéquate, et nous sommes redevenus des cibles faciles.

L'entraînement statique et les outils statiques présentent les mêmes problèmes

Les outils d'analyse statique font partie intégrante du SDLC et font leur travail en analysant des outils de pointe pour les spécialistes AppSec rares et surchargés de travail que l'on trouve dans la plupart des grandes entreprises. Ils font un excellent travail, mais il y a un défaut : aucun outil ne peut détecter toutes les vulnérabilités, prenant en charge la vaste gamme de frameworks de programmation disponibles. C'est également un processus lent, et il suffit d'un bogue de sécurité pour passer entre les mailles du filet pour laisser une porte ouverte à un attaquant.

Avec l'entraînement statique, le problème est similaire. Si les développeurs reçoivent une formation à la sécurité sous la forme d'un cours rigide et « personnalisé », il est très peu probable qu'ils aient suivi le rythme des problèmes de sécurité les plus courants au cours de cette période. Il donne un aperçu de l'époque à laquelle il a été écrit, et il est rarement suffisamment revu, présenté dans la langue et le cadre préférés de l'étudiant, et il n'est pas non plus contextuel aux vulnérabilités auxquelles il est susceptible de faire face dans son travail quotidien. Imaginez que vous essayez de vous souvenir d'une information pertinente contenue dans une vidéo que vous avez regardée il y a des mois, tout en essayant de respecter les délais de livraison et de diffuser du code... il est peu probable que cela se produise.

Les méthodes de formation traditionnelles sont en train d'être réévaluées dans de nombreux secteurs, mais lorsqu'il s'agit de former les développeurs à la sécurité, il suffit de prendre en compte le volume considérable de violations de données que nous subissons encore (en particulier celles qui peuvent être attribuées à des vulnérabilités que nous savons comment éviter en matière de codage depuis des décennies) comme une injection SQL) pour réaliser que nous devons essayer une autre méthode.

Nous avons besoin d'une formation qui dépasse les limites d'un cours linéaire unique, capable de s'adapter aux besoins en constante évolution des meilleures pratiques en matière de cybersécurité.

Entraînement dynamique : la référence absolue

En proposant aux développeurs une solution de formation dynamique, qui peut être adaptée rapidement à l'entreprise, au niveau de compétence individuel et aux évolutions générales du secteur, vous leur fournissez les meilleures bases pour coder en toute sécurité, en gardant la sécurité au premier plan et en agissant dans un esprit conscient de la sécurité.

Une formation qui convient à tous, qui ne sera jamais revisitée et qui ne soit pas engageante au départ sera une perte de temps totale. Malheureusement, cela signifie que vous pourriez finir par acheter impulsivement un programme inefficace pour des raisons de conformité. Il peut être obsolète avant même que vous ne le déployez, ou à peine adapté aux besoins de leur travail quotidien.

L'entraînement dynamique est un outil vivant qui est constamment mis à jour, adapté aux besoins quotidiens, qui engage les utilisateurs à faire preuve d'esprit critique et leur permet réellement d'acquérir des compétences et de résoudre les problèmes.

Alors, à quoi ressemble un programme de formation dynamique dans un contexte de sécurité ?

Il s'agira de :

• De la taille d'une bouchée: Les développeurs peuvent acquérir des compétences par étapes faciles à gérer et beaucoup plus faciles à mémoriser (et surtout à appliquer) que de longs modules de formation et des vidéos
• Pertinent : À quoi sert une formation générique à la sécurité dont les exemples sont en C#, par exemple, lorsque le développeur code principalement en Java ? Toute formation doit s'appliquer directement à leur rôle, leur permettant de voir ce qu'ils doivent trouver et corriger (et, idéalement, éviter en premier lieu) pendant qu'ils codent.
• Actuel : Cela semble évident, mais ce n'est pas souvent le cas. Le paysage de la cybersécurité est en constante évolution, et l'augmentation du code entraîne une augmentation des responsabilités. Pour que les développeurs soient votre première ligne de défense, ils ont besoin d'une formation adaptée aux meilleures pratiques de sécurité modernes.
• Engagement : Ce n'est un secret pour personne que la « sécurité » peut être une corvée pour les développeurs, surtout si cela interfère avec leur flux créatif. Une formation adaptée leur montrera le pouvoir dont ils disposent pour résoudre les problèmes de sécurité quotidiens qui peuvent se transformer en risques énormes, en développant une culture de responsabilité et de sensibilisation à la sécurité.
• Amusant : L'entraînement dynamique est rarement ennuyeux ; il est censé être au moins un peu excitant de par sa conception. Pensez à ce que les développeurs adorent : résoudre des problèmes, rivaliser avec leurs pairs et, comme beaucoup d'entre nous sur le marché du travail, être récompensés et reconnus. Tirez parti de leurs points forts et concentrez-vous sur l'obtention des meilleurs résultats.

C'est une période passionnante pour les ingénieurs logiciels ; ils jouent un rôle essentiel dans l'innovation numérique, contribuent à créer des entreprises extraordinaires et prennent même le monde d'assaut avec leurs propres créations. Cependant, les organismes gouvernementaux et les grandes entreprises étant conscients du rôle qu'ils doivent jouer dans l'établissement de normes en matière de sécurité logicielle, il est important de les soutenir en leur proposant des solutions de formation efficaces et dynamiques qui favorisent l'amour pour le codage sécurisé, et non un exercice bureaucratique à cocher des cases.

Selon une étude d'IBM, il est trente fois plus coûteux de corriger les vulnérabilités après leur publication que de les détecter et de les corriger initialement. Dans cette optique, il n'est pas surprenant que les DSI tournés vers l'avenir mettent en œuvre des pratiques de codage sécurisées. Cela implique de former et d'équiper les développeurs pour qu'ils écrivent du code de manière plus sécurisée dès le départ, ce qui en fait la « première ligne de défense » de leur organisation. Pour mesurer les impacts réels de cette tendance, Secure Code Warrior s'est associé à Evans Data Corp* et a commandé une étude récente sur l'attitude des développeurs à l'égard du codage sécurisé, des pratiques de code sécurisées et des opérations de sécurité. Cette étude révèle que la mise en œuvre de pratiques de code sécurisées est transformatrice pour les entreprises sur plusieurs fronts. Téléchargez votre copie du livre blanc ici.

Codage sécurisé avec plus de confiance et de pleine conscience

Il ne fait aucun doute que la mise en œuvre de pratiques de codage sécurisées sensibilise les développeurs à la sécurité d'une manière qui profite à leurs employeurs. Notre étude révèle que 55 % des développeurs affirment qu'une bonne formation leur a permis de renforcer leur confiance dans leurs techniques de codage, et 53 % ont déclaré qu'une bonne formation leur avait permis d'être plus prudents lorsqu'ils déboguaient et testaient leur propre code. De même, 53 % pensent être devenus plus attentifs à la sécurité lorsqu'ils écrivent du code.

Qu'est-ce que cela nous apprend ? Cela nous indique qu'avec un peu de perfectionnement, les développeurs peuvent devenir votre première ligne de défense.

Sélection d'outils plus intelligente + vitesse de lancement accrue

Lorsque nous avons interrogé les responsables sur les impacts de la formation au code sécurisé, leurs points de vue reflétaient leurs responsabilités managériales. 43 % des responsables ont reconnu que la formation au code sécurisé avait aidé leurs organisations à faire preuve de plus de prudence lors du débogage et des tests de leur code. 47 % ont indiqué qu'une formation de qualité leur avait permis d'être plus sélectifs dans les choix d'outils offrant plus de sécurité. Mais ce qui est peut-être le plus important, 44 % ont indiqué que la formation et les techniques de codage sécurisé avaient permis de gagner du temps et d'accélérer la publication des logiciels, un avantage considérable lorsque la rapidité de mise sur le marché est primordiale.

Productivité accrue à tous les niveaux

Lorsque nous avons demandé aux développeurs comment le codage sécurisé avait contribué à améliorer la productivité, plus de la moitié ont estimé qu'il avait contribué à améliorer la qualité du codage et de la conception des applications.

63 % ont déclaré qu'il réduisait les retouches en prévenant les vulnérabilités récurrentes. 70 % ont déclaré qu'il avait aidé à éliminer les erreurs qui entraînaient des retouches ou des correctifs. 56 % affirment qu'il a amélioré la productivité en matière de débogage et de test. Nous pouvons constater la transformation en cours à plusieurs étapes du cycle de vie du développement logiciel.

Dynamique d'équipe et qualité du code

Les pratiques de code sécurisé ont également un impact sur la dynamique des équipes. Bien que les développeurs apprennent individuellement à coder de manière plus sécurisée, leur code n'existe pas dans le vide. Leur code dépend souvent du travail des autres et vice versa. La mise en œuvre de pratiques de codage sécurisées amène les développeurs à partager et à rechercher des connaissances en matière de codage sécurisé, ce qui améliore la communication entre les développeurs, les développeurs et la direction, ainsi qu'entre l'équipe de développement et ses parties prenantes.

• 60 % des développeurs interrogés pensent que l'utilisation de pratiques de code sécurisées a amélioré leur communication avec les autres développeurs
• 45 % affirment que les contacts avec la direction ont augmenté.

Ces sentiments sont partagés par les managers, mais d'un point de vue différent. 62 % des managers interrogés affirment que les pratiques de code sécurisées les obligent à consacrer plus de temps à la gestion des personnes et contribuent à accélérer la publication du code.

Pour les organisations qui mettent en œuvre des pratiques de code sécurisées, l'augmentation de la communication a un impact transformateur sur la dynamique des équipes, avec un impact positif sur la qualité du code et la rapidité de mise sur le marché.

Passer d'une approche réactive à une approche préventive

Enfin, le code sécurisé a un impact sur la manière dont les développeurs et les responsables de développement appliquent les mesures de sécurité et les indicateurs qui les accompagnent.

Aujourd'hui, 81 % des entreprises s'appuient toujours sur des indicateurs réactifs tels que le nombre de défauts et les indicateurs des scanners pour déterminer la qualité de la sécurité.

Mais ces activités réactives sont de plus en plus complétées par des indicateurs proactifs ou préventifs ou cèdent la place à de tels indicateurs. 67 % des organisations évaluent désormais le niveau de sensibilisation des développeurs au Top 10 de l'OWASP en tant que mesure de leur niveau de préparation en matière de sécurité. Parmi les autres indicateurs proactifs dont l'utilisation augmente, citons :

• Mesurer les compétences des développeurs en matière de sécurité des applications
• Utilisation d'un code pré-approuvé
• Conformité aux exigences réglementaires.

90 % des développeurs sont désormais attentifs à ces mesures préventives. Mais alors que la prise de conscience et la mise en œuvre de pratiques de codage sécurisé augmentent, il reste encore du chemin à parcourir pour en exploiter tout le potentiel.

Où aller à partir d'ici ?

En tant que champion du changement en matière de codage sécurisé, Secure Code Warrior adopte une approche dirigée par l'homme pour vous aider à faire de vos développeurs votre première ligne de défense, et à faire passer votre approche globale de la sécurité de réactive à proactive. Notre plateforme d'apprentissage éprouvée propose une formation contextuelle et pratique dans 52 catégories linguistiques spécifiques au framework, avec des défis qui imitent ceux auxquels les développeurs sont confrontés dans le monde réel. Nous savons par expérience que les développeurs préfèrent la méthode de l'apprentissage par la pratique à la difficulté de l'apprentissage statique basé sur la théorie. Si vous souhaitez voir l'impact transformateur que cela peut avoir sur vos équipes et sur leur capacité à envoyer du code de qualité en toute confiance, réservez une démo dès maintenant.

‍

*Passer de la réaction à la prévention : le nouveau visage de la sécurité des applications Secure Code Warrior et Evans Data Corp. 2020
1. IBM Software Group ; minimiser les défauts de code pour améliorer la qualité des logiciels et réduire les coûts de développement - https://docplayer.net/11413245-Minimizing-code-defects-to-improve-software-quality-and-lower-development-costs.html

‍

Partager des livres de cuisine au sein d'une équipe

Lorsqu'une personne crée une recette Sensei pour améliorer la qualité de son code ou sa productivité, tous les membres de l'équipe peuvent bénéficier du partage des livres de recettes.

Sensei propose un certain nombre de mécanismes pour partager des livres de cuisine :

• Stockez les livres de recettes dans le projet sous contrôle de version
• Stockage des livres de recettes dans un dossier partagé
• Stockez des livres de recettes sur Github
• Fichiers compressés via HTTP (s)

En partageant les livres de recettes, Sensei aide les équipes à collaborer sur le partage des connaissances. La collaboration permet d'améliorer la communication et d'intégrer les approches convenues en matière de qualité du code.

Par exemple, partager un livre de recettes :

• aide les membres de l'équipe à partager des recettes utiles entre eux.
• aide les chefs d'équipe à codifier les pratiques de codage convenues, pour le personnel subalterne, afin d'identifier les violations courantes et de trouver une solution rapide à la version convenue.
• favorise une coopération accrue entre les équipes, par exemple une équipe AppSec peut créer des recettes pour mettre en évidence un problème dans le code, et l'équipe de développement pourrait écrire la solution rapide.

Les sections suivantes expliquent comment mettre en œuvre chacun des mécanismes de partage.

Stockez les livres de recettes dans le projet sous contrôle de version

Le dossier .sensei du projet est l'option par défaut lors de la création d'un fichier de livre de recettes.

• `projet : //.sensei`

Tous les livres de recettes et recettes seraient stockés dans un dossier .sensei de votre projet.

L'approche la plus simple pour partager est d'ajouter le dossier .sensei du projet au contrôle de version.

Ensuite, le dossier .sensei peut être géré comme n'importe quel autre artefact de code partagé associé au projet. Les livres de recettes sont stockés en tant que configuration YAML, ce qui facilite leur fusion lors de tout processus de validation et de révision.

C'est l'approche adoptée pour le projet public sensei-blog-examples.

• https://github.com/SecureCodeWarrior/sensei-blog-examples

Le dossier .sensei contient le livre de recettes avec toutes les recettes, et elles sont accessibles à tous ceux qui clonent le référentiel.

Rangez les livres de cuisine dans n'importe quel dossier

Les équipes peuvent également utiliser des livres de recettes stockés dans des emplacements centraux.

L'enregistrement du livre de recettes dans n'importe quel dossier doté d'autorisations d'écriture partagées permettra à toute l'équipe de mettre à jour les recettes et de les importer dans n'importe quel projet sur lequel elle travaille.

L'emplacement serait défini sur le chemin du répertoire.

Stockez les recettes sur Github

Sensei peut également accéder à des recettes stockées dans un dépôt Github. Les dépôts privés et publics sont pris en charge.

Github via SSH

L'accès au référentiel SSH est configuré à l'aide de la syntaxe suivante pour l'emplacement

git@github.com : SecureCodeWarrior/ACookbook.git

Pour que cela fonctionne, le référentiel contiendrait le contenu d'un dossier de livres de recettes.

Il est également possible de configurer la branche et le sous-dossier du livre de recettes, par exemple dans la branche principale du sous-dossier du livre de recettes.

p. ej.

• git@github.com : SecureCodeWarrior/sensei-blog-examples.git|master|.sensei

Une clé SSH doit être configurée pour les référentiels privés.

• https://github.com/settings/keys

Et la clé ne doit pas comporter de mot de passe.

Github via HTTPS

Il est également possible d'accéder aux dépôts publics via HTTPS, et la même syntaxe repo.git|branch|folder est utilisée, par ex.

Pour nos exemples de projets de blog :

• https://github.com/SecureCodeWarrior/sensei-blog-examples.git|master|.sensei

Pour notre ensemble d'exemples de protection de base, nous pouvons ignorer la branche et le sous-dossier car nous obtiendrons la branche principale par défaut et le fichier rules.sensei se trouve dans le dossier racine. :

• https://github.com/SecureCodeWarrior/cookbook-basic-protection-set

Zippé via HTTP (s)

Sensei peut également accéder à des livres de recettes compressés, via HTTP ou HTTPS.

par exemple si j'avais un serveur HTTP écoutant localement sur le port 8000

• http://localhost:8000/rules.sensei.zip

Le fichier zip du livre de recettes doit contenir le contenu d'un dossier de livres de recettes, par exemple le fichier rules.sensei.

Résumé du partage

Sensei prend en charge l'utilisation de plusieurs livres de recettes afin que chaque programmeur puisse disposer de recettes qui favorisent son apprentissage et sa productivité.

Plus important encore, nous savons que les équipes travaillent plus efficacement lorsque les connaissances sont partagées. Le fait de disposer de référentiels d'équipe partagés, par exemple pour un projet ou une bibliothèque spécifique, ou pour un ensemble partagé de modèles de migration, peut contribuer à améliorer la productivité de l'équipe et à codifier l'expérience de l'équipe.

Lorsqu'un livre de recettes est partagé, plusieurs équipes peuvent utiliser le même livre de recettes, ce qui peut également améliorer la collaboration entre les équipes issues de différentes disciplines, par exemple la sécurité des applications ou le développement.

Avec quatre principaux mécanismes de partage disponibles, Sensei propose, espérons-le, au moins une approche que vous pouvez utiliser pour améliorer la collaboration en matière de partage des connaissances.

---

Vous pouvez installer Sensei depuis IntelliJ en utilisant « Préférences \ Plugins » (Mac) ou « Paramètres \ Plugins » (Windows), puis recherchez simplement « Sensei Secure Code ».

Tous les articles du blog Sensei, le code et les recettes sont sur Github en :

•  https://github.com/SecureCodeWarrior/sensei-blog-examples