Informations concernant le code sécurisé

Le développement piloté par l'IA a introduit de toutes nouvelles catégories de risques logiciels. L'injection rapide, la manipulation du RAG et les autorisations excessives des agents ne sont plus des préoccupations théoriques, mais des réalités actives dans les applications modernes.

Les développeurs ont besoin d'une exposition pratique à ces modèles de menaces émergentes dans des environnements reflétant la complexité du monde réel. C'est pourquoi nous avons transformé les missions boss Cybermon 2025 AI/LLM, qui n'étaient qu'une expérience à événements limités, en une collection de sujets de quêtes déployable dans Secure Code Warrior. Vous trouverez la collection Cybermon 2025 : Beat the Boss dans la section Concepts spécifiques, sous Concepts de sécurité, lors de la création d'une nouvelle quête.

Cybermon 2025 : Battez le boss permet aux organisations d'intégrer à tout moment ces défis de sécurité très complexes liés à l'IA dans leurs programmes de codage sécurisés.

Qu'est-ce que Beat the Boss ?

Beat the Boss rassemble quatre défis avancés en matière d'IA et de LLM conçus pour évaluer les capacités de développement d'une IA sécurisée dans le monde réel.

Chaque sujet comprend une courte vidéo d'introduction et des directives, un échauffement guidé étape par étape et la mission de boss originale à haut niveau de difficulté de Cybermon 2025. Ces scénarios immersifs mettent l'accent sur des classes de vulnérabilités d'IA pratiques que les développeurs doivent comprendre au fur et à mesure de l'évolution des applications basées sur l'IA.

Les quatre missions ciblent chacune une zone de risque distincte liée à l'IA, simulant des modèles de menaces réels dans des systèmes alimentés par l'IA :

• Bypassaur — Injection directe et rapide
• Keykraken — Injection rapide indirecte
• Promptgeist — Faiblesses liées aux vecteurs et à l'intégration
• Proxysurfa — Activité excessive

Veuillez procéder à votre convenance.

Nous vous recommandons de mettre en évidence un responsable à la fois afin d'accorder à chaque vulnérabilité l'attention qu'elle mérite. De nombreuses organisations choisissent de gérer :

• Un responsable par semaine dans le cadre d'un sprint axé sur la sécurité de l'IA
• Ou une fois par mois dans le cadre de l'initiative « Vulnérabilité du mois »

Des instructions de déploiement structurées et des ressources de marque téléchargeables sont disponibles dans la base de connaissances pour les administrateurs qui configurent les événements internes :
Cybermon 2025 : organisez votre propre événement Beat the Boss

Mettre en œuvre la préparation à la sécurité de l'IA

Le développement accéléré par l'IA redéfinit le paysage des risques logiciels. Les nouvelles catégories de vulnérabilité exigent plus qu'une simple prise de conscience : elles nécessitent une expérience appliquée.

Beat the Boss permet aux entreprises de traduire l'évolution des modèles de menaces liées à l'IA en fonctionnalités pratiques pour les développeurs.

Les développeurs peuvent relever chaque défi de manière indépendante, puis examiner les solutions guidées afin de renforcer l'état d'esprit de l'attaquant et les stratégies défensives. Des vidéos présentant la solution complète sont disponibles pour l'apprentissage après le défi :

De nombreuses équipes élargissent l'expérience par le biais de sessions internes de partage des connaissances, faisant passer l'apprentissage basé sur les événements d'un apprentissage compétitif à un apprentissage collaboratif. La sécurité et le développement sont des activités d'équipe. Les organisations sont mieux protégées lorsque les développeurs, les responsables de la sécurité et les équipes d'ingénierie travaillent ensemble pour comprendre et atténuer la surface d'attaque croissante de l'IA. Des comptes rendus facilités, des évaluations de solutions partagées et des discussions entre équipes permettent de transformer la résolution des défis individuels en capacité collective.

En intégrant Beat the Boss à vos initiatives de codage sécurisé, vous renforcez l'adoption sécurisée de l'IA tout en développant une maturité mesurable en matière de sécurité de l'IA au sein de vos équipes de développement.

Veuillez commencer

La collection Cybermon 2025 : Beat the Boss est accessible dans la section Concepts spécifiques, sous Concepts de sécurité, lors de la création d'une nouvelle quête. Veuillez vous connecter à votre compte Secure Code Warrior pour configurer votre déploiement et renforcer le développement sécurisé de l'IA au sein de vos équipes.

La loi sur la cyber-résilience est en train de devenir rapidement une priorité stratégique, non seulement pour les entreprises basées dans l'UE, mais aussi pour toutes les entreprises qui commercialisent des produits numériques sur le marché européen. Alors que les délais de conformité s'étendent jusqu'en 2027, les équipes d'ingénierie et de sécurité se posent déjà des questions complexes sur les pratiques de sécurité dès la conception, la gestion des vulnérabilités et les capacités de développement.

Contrairement à de nombreux règlements qui mettent l'accent sur la documentation et les audits, l'ARC place la conception et le développement de logiciels sécurisés au cœur de la conformité. Les entreprises qui investissent tôt dans des fonctionnalités de sécurité dès la conception atteindront plus rapidement la conformité et se démarqueront sur un marché où la sécurité des produits devient un critère d'achat.

Ce que la loi sur la cyber-résilience exige

La loi sur la cyber-résilience (CRA) établit des exigences de base en matière de cybersécurité pour la plupart des produits comportant un composant numérique mis sur le marché de l'UE, notamment les logiciels, les systèmes d'exploitation, les appareils connectés et les systèmes intégrés.

Plus important encore, cela modifie la question de la responsabilité.

La sécurité ne se limite plus à une simple question d'exécution ou d'exploitation. Dans le cadre de la CRA, elle devient une obligation de conception et de développement couvrant l'architecture, la mise en œuvre, la maintenance et la gestion des vulnérabilités.

Pour les responsables de l'ingénierie et de la sécurité, cela implique :

• Les produits doivent être fabriqués conformément aux principes de sécurité dès la conception.
• Les vulnérabilités connues doivent être évitées autant que possible et traitées efficacement.
• Les organisations doivent démontrer que des pratiques de développement sécurisées sont mises en place.

En résumé : la conformité est étroitement liée à la manière dont les développeurs écrivent et gèrent le code.

À qui s'adresse la CRA

Bien qu'introduite par l'UE, la CRA s'applique à toute organisation dans le monde qui commercialise des produits numériques concernés sur le marché de l'UE, notamment :

• Fournisseurs de logiciels et fournisseurs SaaS dont les services fonctionnent en tant que composants de traitement des données à distance des produits couverts
• Fabricants de produits numériques ou connectés
• Importateurs, distributeurs et détaillants
• Organisations intégrant des composants numériques tiers

Pour les entreprises mondiales, la préparation au CRA est une exigence de développement transfrontalier, et non un exercice de conformité régionale.

Pourquoi les organisations commencent-elles dès maintenant ?

Principales étapes :

• Septembre 2026 — Les obligations de signalement des vulnérabilités entrent en vigueur
• Décembre 2027 — Conformité totale requise

Sur le papier, cette chronologie peut sembler satisfaisante. En réalité, la transformation du développement ne se produit pas en trimestres, mais au fil des années.

La sécurité dès la conception n'est pas une simple mise à jour de politique. Elle implique :

• Améliorer les compétences de milliers de développeurs dans tous les langages et dans toutes les équipes
• Intégrer les exigences de sécurité dès la conception dans les processus de travail quotidiens
• Passer de la remédiation réactive des vulnérabilités à la prévention
• Fournir des preuves tangibles que les pratiques de développement sécurisées sont appliquées de manière cohérente

Ces changements ont un impact sur le recrutement, l'intégration, les décisions relatives à l'architecture, les processus SDLC et la culture de l'ingénierie. Les organisations qui reportent jusqu'à la fin de 2026 tenteront de moderniser leurs capacités sous la pression réglementaire, une solution bien plus coûteuse et perturbatrice.

L'application de la loi comporte également des risques financiers importants. En vertu de l'article 64 de la CRA, les sanctions peuvent atteindre 15 millions d'euros, soit 2,5 % du chiffre d'affaires annuel mondial, en cas de violation des exigences essentielles en matière de cybersécurité.

Il est tout simplement trop tard d'attendre la fin de l'année 2026.

Le CRA représente en fin de compte un défi de capacité pour les développeurs.

De nombreuses réglementations mettent l'accent sur les politiques et la documentation. La CRA va plus loin en établissant un lien entre la conformité et les pratiques réelles utilisées pour concevoir et créer des logiciels. Cela soulève des attentes quant au développement sécurisé en tant que discipline opérationnelle, et pas seulement en tant qu'exigence de gouvernance.

Pour les responsables de l'ingénierie, cela implique que la conformité dépend de l'application systématique par les équipes de développement de pratiques sécurisées, notamment :

• Comprendre les classes de vulnérabilité courantes
• Appliquer les principes de conception et d'architecture sécurisés
• Éviter les modèles de mise en œuvre non sécurisés
• Gestion responsable des composants tiers et open source

Les outils de sécurité jouent un rôle important dans la détection des problèmes. Cependant, ces outils révèlent leurs faiblesses une fois le code écrit. La sécurité dès la conception impose aux développeurs de prévenir les vulnérabilités en premier lieu, et de le faire de manière cohérente dans toutes les équipes, tous les langages et tous les produits.

Les outils seuls ne peuvent pas y parvenir. Les résultats en matière de sécurité dès la conception dépendent de la capacité humaine.

Comment Secure Code Warrior à la préparation de la CRA

Secure Code Warrior des parcours d'apprentissage alignés sur le CRA qui combinent :

• Une demande standard CRA conforme aux exigences de vulnérabilité technique de l'annexe I, partie I
• Collection UNE Conceptuelle Sécurisée dès la conception
• Formation pratique sur les vulnérabilités spécifiques à la langue

Veuillez consulter notre guide d'une page sur l'ensemble du contenu d'apprentissage aligné sur le CRA dans SCW. SCW ne certifie pas la conformité. Nous soutenons la préparation au CRA par un apprentissage structuré et une amélioration mesurable des capacités conformément aux principes de développement sécurisé de la réglementation.

Veuillez commencer dès maintenant à vous préparer pour la CRA.

Le CRA reflète l'orientation prise par l'industrie : la sécurité par l'ingénierie de conception est l'attente par défaut. Les organisations qui investissent dès maintenant dans les capacités des développeurs seront mieux placées pour assurer la conformité et créer des logiciels plus résilients et moins risqués à long terme.

Pour plus de détails sur la manière dont Secure Code Warrior vous aider à atteindre la conformité, veuillez consulter notre base de connaissances : Comment Secure Code Warrior vous aider à atteindre la conformité

Nous débutons notre analyse approfondie des 10 facteurs de réussite par l'étape fondamentale du facilitateur 1 : des critères de réussite définis et mesurables. Si un programme de codage sécurisé est un voyage, la première étape, et la plus cruciale, consiste à savoir exactement où vous allez. C'est l'essence même du premier facilitateur.

Relier les critères de réussite aux résultats commerciaux

La mise en place d'un programme de codage sécurisé efficace nécessite la définition d'objectifs clairs étroitement liés aux résultats commerciaux. L'Enabler 1 répond aux questions fondamentales suivantes : « Quel est, en termes très spécifiques et mesurables, le problème ou la difficulté que nous essayons de résoudre avec notre programme de codage sécurisé ? »

Il est possible que votre organisation souhaite respecter les exigences de conformité ou prévenir les failles de sécurité et les cyberattaques. Ou peut-être envisagez-vous de vous démarquer en tant qu'organisation, en réduisant les coûts et les délais de retouche, en formant les développeurs à coder de manière sécurisée dès le début.

Quelles que soient vos motivations, l'état actuel de votre organisation ou même la plateforme de formation à la sécurité que vous choisissez, le succès à long terme de votre programme dépend largement de la définition d'objectifs clairement définis liés aux objectifs commerciaux afin de gagner l'adhésion et d'assurer un succès durable.

Tenez compte des principales parties prenantes de votre programme lorsque vous déterminez les critères de réussite. Connaître vos sponsors exécutifs et leurs objectifs commerciaux vous aidera à favoriser une adoption plus large dans tous les services.

Rendre le succès tangible et mesurable

Ces objectifs doivent, de par leur nature même, être spécifiques à votre organisation. Cela dit, veuillez examiner ces objectifs commerciaux types et réfléchir à la manière dont ils pourraient vous inspirer d'autres idées :

Réduction des risques : atténuez les risques liés aux développeurs et réduisez les vulnérabilités introduites par les failles de codage. Cela inclut l'identification des risques et la réduction de la surface d'attaque des applications.

Les programmes visent souvent des indicateurs tels que la réduction et la prévention de la densité des vulnérabilités ou du taux d'injection de vulnérabilités.

Vitesse opérationnelle : optimisez la vitesse de livraison des produits, réduisez la frustration et l'attrition des développeurs, et diminuez le temps consacré aux retouches. La formation au code sécurisé constitue une incitation importante pour les développeurs, car elle leur permet d'éviter les retouches fastidieuses du code bogué identifié plus tard dans le cycle de vie du développement logiciel.

Les programmes visent souvent à réduire le temps moyen de correction (MTTR) des vulnérabilités par les développeurs.

Conformité réglementaire : Assurez la conformité externe, par exemple en respectant des normes telles que PCI-DSS (qui impose une formation à tous les développeurs travaillant sur des systèmes de paiement).

Talent et confiance : Renforcez l'engagement et la sensibilisation à la sécurité et aux vulnérabilités au sein de l'organisation des développeurs, tout en maintenant et en renforçant la confiance des clients. Pour certaines entreprises, les développeurs sensibilisés à la sécurité contribuent à établir une différenciation sur le marché.

Les programmes établissent souvent des exigences minimales en matière de compétences pour les développeurs ou créent même des programmes spécialisés de champions de la sécurité.

Documenter le succès dans un plan de réussite conjoint

Unefois que vous avez défini vos critères de réussite, l'étape suivante consiste à les documenter dans un Plan de réussite conjoint. Ce plan est un plan commun interfonctionnel, impliquant toutes les parties prenantes clés de votre programme, y compris un soutien externe tel que votre plateforme de formation CSM.

Le plan de réussite comprend :

1. Facteur(s) de valeur: il s'agit notamment des objectifs commerciaux de haut niveau liés à l'amélioration de la sécurité du code et à la réponse au « pourquoi » de votre programme.
2. État actuel: Cela soulève la question suivante : « Où en sommes-nous actuellement ? » (par exemple, les compétences actuelles en matière de codage sécurisé ou les programmes de formation existants).
3. État futur (souhaité): Ensuite, vous documentez « Où voulons-nous être ? » et déterminez comment combler le déficit de compétences en matière de codage sécurisé.
4. Indicateurs clés de performance/mesures: Il s'agit des indicateurs qui évaluent le succès et démontrent que l'écart entre les situations actuelles et futures diminue à mesure que le programme est déployé.

Nous vous recommandons de commencer par un ou deux indicateurs spécifiques et de les étendre ultérieurement si nécessaire. Ces KPI/mesures doivent respecter le principe S.M.A.R.T. (spécifique, mesurable, réalisable, pertinent, limité dans le temps). Ils devraient être faciles à suivre et ne pas donner lieu à des interprétations floues. La responsabilité de toutes les parties est requise pour mettre le plan en œuvre, avec un rythme régulier et convenu pour examiner la valeur et le retour sur investissement avec la direction.

En définissant et en évaluant ces critères de manière explicite, votre programme de codage sécurisé évolue d'un simple centre de coûts à un moteur vérifiable de résultats commerciaux essentiels, une première étape nécessaire pour atteindre la maturité du programme.

Ensuite, nous allons examiner le Facilitateur 2 : Parrainage de la haute direction afin de discuter du rôle clé que joue le leadership dans le déploiement réussi d'un programme de codage sécurisé.

Avez-vous d'autres questions ? Les clients peuvent contacter l'équipe chargée du compte ou support@securecodewarrior.com. Les clients potentiels peuvent s'adresser à un membre de notre équipe commerciale en nous contactant ici.

Une personne qui décide de se lancer dans une start-up peut être qualifiée de différentes manières, du titre ambitieux d'« entrepreneur » à celui, nettement moins flatteur, de « fou ». Après onze ans à la tête de Secure Code Warrior, je me situe volontiers quelque part entre les deux. 

Les cinq dernières années ont été une leçon de résilience pour beaucoup, avec des imprévus, économiques et autres, que même les personnes les plus brillantes de la planète n'avaient pas su prévoir. On pourrait penser ici à la « loi du plus fort », mais je préfère cette citation :

Ce ne sont pas les espèces les plus robustes qui survivent, ni les plus intelligentes, mais celles qui s'adaptent le mieux au changement.

(Cette citation est souvent attribuée à tort à Charles Darwin, mais elle a en réalité été prononcée par le professeur Leon C. Megginson, qui résumait l'ouvrage de Darwin, L'Origine des espèces. Nous espérons que cela vous permettra de remporter un prix lors d'un quiz dans un pub à l'avenir.)

À l'heure actuelle, quel meilleur exemple de changement et d'adaptabilité existe-t-il dans notre monde que l'intelligence artificielle ? Plus de trois ans après l'annonce de la bombe LLM, nous nous efforçons toujours de comprendre ce qu'est cette itération, ce qu'elle peut accomplir et comment elle peut nous servir au mieux dans pratiquement tous les rôles qui existent aujourd'hui. Quoi qu'il en soit, elle est là pour rester, et en tant que professionnels de la cybersécurité en particulier, nous devons garder une longueur d'avance pour la protéger, même en l'absence de garde-fous et de réglementations officiels.

2025 a été une année importante pour l'IA, la cybersécurité et SCW. J'aborde 2026 avec une confiance sereine et l'optimisme que seul le travail acharné peut apporter. 

Nous avons franchi plusieurs étapes importantes, notamment notre incursion dans la sécurisation du développement de logiciels basés sur l'intelligence artificielle. Nous avons :

• Publié Trust Agent : IA en phase de test bêta : les dernières recherches de la CCIA confirmant que l'IA générative est la technologie qui a connu l'adoption la plus rapide de l'histoire, il n'est pas surprenant de constater l'engouement des développeurs pour les agents et assistants de codage IA, y compris les déploiements précipités au niveau des entreprises qui avancent plus vite que leurs programmes de sécurité.
  
  Notre dernière technologie, Trust Agent : AI, apporte la visibilité et la gouvernance qui faisaient défaut au code généré par l'IA. Elle offre aux responsables de la sécurité des entreprises l'observabilité et le contrôle approfondis dont ils ont besoin pour gérer en toute confiance l'adoption de l'IA dans leur cycle de vie de développement logiciel (SDLC) sans sacrifier la sécurité.
• Nous avons dépassé notre dernier objectif majeur en matière de chiffre d'affaires : le dépassement de notre objectif de chiffre d'affaires témoigne de la ténacité et de l'esprit d'innovation de toute Secure Code Warrior . Lorsque nous nous sommes lancés dans cette aventure, notre mission était d'aller au-delà de l'approche « checklist » en matière de sécurité et de donner aux développeurs les moyens d'écrire du code sécurisé dès la première ligne.
  
  Le fait que cette vision trouve un écho auprès d'un si grand nombre d'entreprises internationales prouve que le secteur se tourne enfin vers une sécurité centrée sur les développeurs, et je suis extrêmement fier de la manière dont nos Warriors se sont investis pour rendre les logiciels plus sûrs pour tous.
• Intégrations expertes avec des partenaires stratégiques : nos partenariats avec des entreprises de renom telles qu'Aikido, OpenText et Black Duck représentent une avancée significative dans notre mission visant à créer un écosystème de sécurité transparent et centré sur les développeurs. En comblant le fossé entre l'identification des vulnérabilités et la fourniture des compétences spécifiques nécessaires pour les corriger, nous bouclons efficacement la boucle en matière de risques logiciels liés aux développeurs.
  
  Je suis extrêmement fier de ce partenariat, qui marque un changement stratégique, passant d'outils fragmentés à une expérience unifiée où la sécurité est le prolongement naturel du processus de développement.

Alors que nous nous apprêtons à vivre une nouvelle année importante, je tiens à remercier nos nombreux supporters, en particulier ceux de la communauté cybernétique au sens large, qui continuent à lutter contre les vulnérabilités récurrentes, le manque de sensibilisation à la sécurité et la mauvaise qualité des codes produits. En adoptant une nouvelle norme plus sûre, nous pouvons commencer à constater de réelles améliorations dans la sécurité de nos logiciels, services et technologies. 

Nous investissons pleinement dans un avenir où l'IA écrira la majorité du code, sous la supervision d'humains qualifiés. Notre SCW Learning évolue rapidement pour répondre aux exigences de ce nouveau monde, et notre SCW Trust Agent : AI sera disponible dans les trois prochains mois pour soutenir le fonctionnement sécurisé des LLM, MCP et autres dans le SDLC. Nous sommes également sur le point d'annoncer très prochainement un nouveau partenariat passionnant avec un acteur majeur du marché.

Restez à l'écoute !

Une version de cet article a été publiée dans Revue SC. Il a été modifié et diffusé ici.


Si vous avez déjà été victime d'un cambriolage, vous comprenez ce sentiment initial que quelque chose ne va pas, suivi de la prise de conscience que vous avez bel et bien été volé et violé. Cela entraîne généralement un inconfort durable, sans parler de la nécessité de passer à des mesures de sécurité comparables à celles de Fort Knox.

Imaginez maintenant que votre domicile soit cambriolé, car les voleurs se sont procuré une clé. Ils s'introduisent, vont et viennent à leur guise, mais prennent soin de ne pas être détectés. Puis, un jour, vous vous rendez compte trop tard que les bijoux que vous aviez cachés dans le congélateur ont disparu, que votre coffre-fort a été vidé et que vos effets personnels ont été saccagés. C'est la même réalité à laquelle une organisation est confrontée si elle est victime d'une cyberattaque de type « jour zéro ». En 2020, une étude du Ponemon Institute a révélé que 80 % des violations de données réussies étaient le résultat d'exploits zero-day et, malheureusement, la plupart des entreprises ne sont toujours pas équipées pour améliorer de manière significative cette statistique.

Les attaques « jour zéro », par définition, ne laissent pas le temps aux développeurs de détecter et de corriger les vulnérabilités existantes susceptibles d'être exploitées, car c'est l'auteur de la menace qui est intervenu le premier. Le mal est fait et il s'ensuit alors une course effrénée pour réparer à la fois le logiciel et l'atteinte à la réputation de l'entreprise. Les attaquants ont toujours un avantage, et il est crucial de réduire cet avantage autant que possible.

Le cadeau de Noël dont personne ne souhaitait, Log4Shell, est actuellement en train de perturber Internet, avec plus d'un milliard d'appareils qui seraient affectés par cette vulnérabilité critique de Java. Cela s'annonce comme la pire attaque de type « zero-day » jamais enregistrée, et ce n'est que le début. Bien que certains rapports indiquent que les exploits aient commencé quelques jours avant leur divulgation publique, une présentation donnée à la Black Hat Conference en 2016 suggère que ce problème est connu depuis un certain temps. De plus, il est extrêmement facile à exploiter, et tous les scénaristes et acteurs de menaces de la planète sont à la recherche de gains grâce à cette vulnérabilité.

Quelle est donc la meilleure voie à suivre pour se prémunir contre une menace insidieuse et insaisissable, sans mentionner les vulnérabilités qui n'ont pas été détectées lors du processus de développement logiciel ? Examinons cela de plus près.

Les attaques « jour zéro » contre des cibles importantes sont peu fréquentes (et coûteuses).

Il existe un marché considérable pour les exploits sur le Dark Web, et les jours zéro ont tendance à être coûteux, pour ne citer qu'un exemple dans cet article évalué à 2,5 millions de dollars au moment de la rédaction. Signalé comme un exploit d'Apple iOS, il n'est pas surprenant que le prix demandé par le chercheur en sécurité soit exorbitant. Après tout, il pourrait s'agir d'une passerelle permettant de compromettre des millions d'appareils, de récolter des milliards de données sensibles et de le faire le plus longtemps possible avant qu'elles ne soient découvertes et corrigées.

Cependant, qui dispose de telles ressources financières ? En général, les syndicats de cybercriminels organisés trouvent les fonds nécessaires s'ils le jugent utile, en particulier pour les attaques de ransomware qui sont de plus en plus courantes. Cependant, les gouvernements mondiaux et les départements de la défense font partie de la clientèle pour les exploits qu'ils peuvent utiliser à des fins de renseignement sur les menaces, et dans des scénarios plus positifs, les entreprises elles-mêmes peuvent acheter leurs propres exploits Zero Day potentiels afin de pouvoir atténuer les catastrophes.

L'année 2021 a vu des records battus en matière de découverte d'exploits zero-day en temps réel, et ce sont les grandes organisations, les services gouvernementaux et les infrastructures qui sont les plus susceptibles d'être sondés afin de détecter d'éventuelles faiblesses. Il n'existe aucun moyen d'être totalement à l'abri d'une attaque zero-day, mais vous pouvez « jouer le jeu » en proposant un programme de bug bounty généreux et bien structuré. Au lieu d'attendre que quelqu'un vous offre les clés de votre château de logiciels sur un marché du dark web, faites appel à des professionnels de la sécurité légitimes et offrez-leur des récompenses adéquates en cas de divulgation éthique et de correctifs potentiels.

Et s'il s'avère qu'il s'agit d'une menace de jour zéro exceptionnelle, on peut supposer que vous aurez besoin de plus qu'une carte-cadeau Amazon (et cela en vaudra la peine).

Votre équipement pourrait constituer un obstacle pour votre personnel de sécurité.

La complexité des outils de sécurité constitue un problème de longue date, le RSSI moyen gérant entre 55 et 75 outils dans son arsenal de sécurité. Outre le fait qu'il s'agit du couteau suisse le plus confus (métaphorique) au monde, 53 % des entreprises ne sont même pas convaincues de travailler efficacement, selon une étude du Ponemon Institute. Une autre étude a révélé que seulement 17 % des RSSI pensaient que leur solution de sécurité était « totalement efficace ».

Dans un domaine réputé pour son épuisement professionnel, son manque de personnel qualifié en matière de sécurité pour répondre à la demande et son besoin d'agilité, il est fastidieux d'exiger des professionnels de la sécurité qu'ils travaillent avec une surcharge d'informations sous forme de données, de rapports et de surveillance d'énormes ensembles d'outils. C'est précisément ce type de scénario qui peut les amener à manquer une alerte critique, ce qui a peut-être été le cas lorsqu'il s'est agi d'évaluer correctement les faiblesses de Log4j.

La sécurité préventive doit inclure une modélisation des menaces pilotée par les développeurs.

Les vulnérabilités au niveau du code sont souvent introduites par les développeurs, qui ont besoin de conseils précis et de parcours d'apprentissage réguliers pour développer des compétences de codage sécurisées. Cependant, les développeurs sécurisés de niveau supérieur ont eu l'opportunité d'apprendre et de pratiquer la modélisation des menaces dans le cadre de leur processus de création de logiciels.

Il n'est pas surprenant que les personnes qui connaissent le mieux leur logiciel soient les développeurs qui l'ont créé. Ils possèdent des connaissances approfondies sur la manière dont les utilisateurs interagissent avec celui-ci, sur l'endroit où les fonctionnalités sont utilisées et, lorsqu'ils sont suffisamment conscients de la sécurité, sur les scénarios potentiels dans lesquels il pourrait être piraté ou exploité.

En rapport avec l'exploit Log4Shell, nous observons malheureusement un scénario dans lequel une vulnérabilité catastrophique a échappé à la détection par des experts et des ensembles d'outils complexes, mais elle n'aurait peut-être pas eu lieu si la bibliothèque avait été configurée pour assainir les entrées des utilisateurs. La décision de ne pas le faire semble avoir été une fonctionnalité obscure pour plus de commodité, mais l'a rendu extrêmement facile à exploiter (pensez au niveau de l'injection SQL, ce n'est certainement pas génial). Si la modélisation des menaces avait été réalisée par un groupe de développeurs passionnés et férus de sécurité, il est fort probable que ce scénario aurait été théorisé et envisagé.

Un programme de sécurité efficace comporte une composante émotionnelle, l'intervention humaine et la nuance étant au cœur de la résolution des problèmes créés par l'homme. La modélisation des menaces nécessite de l'empathie et de l'expérience pour être efficace, tout comme le codage et la configuration sécurisés au niveau de l'architecture des logiciels et des applications. Les développeurs ne devraient pas être confrontés à cette tâche du jour au lendemain, mais l'idéal est de trouver une voie claire pour les améliorer à un niveau qui leur permette de soulager la pression sur l'équipe de sécurité pour cette tâche importante (et c'est un excellent moyen d'établir des relations entre les deux équipes).

Un jour zéro conduit à n jours

La prochaine étape pour faire face à un jour zéro consiste à publier les correctifs le plus rapidement possible, en espérant que chaque utilisateur du logiciel vulnérable les appliquera le plus rapidement possible, et certainement avant qu'un attaquant n'arrive le premier. Avec Log4Shell, cela pourrait éclipser Heartbleed en termes de persistance et de puissance, compte tenu de son intégration dans des millions d'appareils et de la création de dépendances complexes au sein d'une conception logicielle.

En réalité, il n'existe aucun moyen d'empêcher complètement ce type d'attaque insidieuse. Cependant, si nous nous engageons à utiliser tous les moyens pour créer des logiciels sécurisés et de qualité, et à aborder le développement avec le même état d'esprit que s'il s'agissait d'une infrastructure critique, nous pouvons tous avoir une chance de réussir.

Le développement assisté par l'IA (ou, dans sa version la plus tendance, le « vibe coding ») a un effet transformateur considérable sur la création de code. Les développeurs confirmés adoptent ces outils en masse, et ceux d'entre nous qui ont toujours souhaité créer leurs propres logiciels mais qui ne disposent pas de l'expérience requise en tirent également parti pour créer des actifs qui, auparavant, auraient été prohibitifs en termes de coûts et de temps. Bien que cette technologie promette d'inaugurer une nouvelle ère d'innovation, elle introduit toute une série de nouvelles vulnérabilités et de nouveaux profils de risque que les responsables de la sécurité ont du mal à atténuer.

Une récente découverte par InvariantLabs a révélé une vulnérabilité critique dans le Model Context Protocol (MCP), un framework de type API permettant à de puissants outils d'IA d'interagir de manière autonome avec d'autres logiciels et bases de données, qui rend possible ce que l'on a surnommé les « attaques par empoisonnement des outils ». », une nouvelle catégorie de vulnérabilité qui pourrait s'avérer particulièrement préjudiciable pour les entreprises. Les principaux outils d'IA, tels que Windsurf et Cursor, ne sont pas à l'abri, et avec plusieurs millions d'utilisateurs, la sensibilisation et les compétences nécessaires pour gérer ce problème de sécurité émergent sont primordiales.

Dans l'état actuel des choses, le résultat de ces outils n' est pas suffisamment sécurisé pour les qualifier de prêts à être utilisés en entreprise, comme indiqué dans un article de recherche récent de Vineeth Sai Narajala et Idan Habler, chercheurs en sécurité chez AWS et Intuit : «À mesure que les systèmes d'IA deviennent plus autonomes et commencent à interagir directement avec des outils externes et des données en temps réel via des outils tels que le MCP, il devient absolument essentiel de garantir la sécurité de ces interactions. »

Les systèmes d'IA agentique et le profil de risque du Model Context Protocol

Le Model Context Protocol est un logiciel pratique développé par Anthropic qui permet une meilleure intégration et une interaction plus fluide entre les agents IA LLM (Large Language Model) et les autres outils. Il s'agit d'un cas d'utilisation puissant, qui ouvre un monde de possibilités entre les applications propriétaires et les outils SaaS critiques pour l'entreprise tels que GitHub, en interaction avec des solutions d'IA de pointe. Il suffit d'écrire un serveur MCP et de commencer à définir les directives concernant la façon dont vous souhaitez qu'il fonctionne et dans quel but.

Les implications de la technologie MCP en matière de sécurité sont en fait essentiellement positives. La promesse d'une intégration plus directe entre les LLM et la technologie utilisée par les professionnels de la sécurité est trop alléchante pour être ignorée, et représente la possibilité d'une automatisation précise des tâches de sécurité à des niveaux auparavant impossibles, du moins pas sans écrire et déployer du code personnalisé, généralement pour chaque tâche. L'interopérabilité améliorée des LLM offerte par MCP représente une perspective intéressante pour la sécurité des entreprises, étant donné qu'une visibilité et une connectivité étendues entre les données, les outils et le personnel sont essentielles pour une défense et une planification efficaces de la sécurité.

Cependant, l'utilisation du MCP peut introduire d'autres vecteurs de menaces possibles, élargissant considérablement la surface d'attaque des entreprises à moins d'être gérée avec soin. Comme l'a noté Laboratoires invariants, les attaques par empoisonnement d'outils constituent une nouvelle catégorie de vulnérabilité qui peut entraîner l'exfiltration de données sensibles et des actions non autorisées de la part de modèles d'IA. À partir de là, les implications en matière de sécurité s'estompent très rapidement.

InvariantLabs souligne qu'une attaque par empoisonnement d'outils est rendue possible lorsque des instructions malveillantes sont intégrées dans les descriptions des outils MCP qui ne sont pas visibles pour les utilisateurs, mais qui sont entièrement lisibles (et exécutables) par les modèles d'IA. Cela incite l'outil à effectuer des actions inappropriées non autorisées à l'insu de l'utilisateur. Le problème réside dans l'hypothèse du MCP selon laquelle toutes les descriptions d'outils sont fiables, ce qui est avantageux pour les acteurs de la menace.

Ils notent les conséquences possibles d'un outil compromis :

• Diriger les modèles d'IA pour accéder à des fichiers sensibles (tels que des clés SSH, des fichiers de configuration, des bases de données, etc.) ;
• Demander à l'IA d'extraire et de transmettre ces données, dans un environnement où ces actions malveillantes sont intrinsèquement cachées à l'utilisateur non averti ;
• Créez un décalage entre ce que l'utilisateur perçoit et ce que fait le modèle d'IA en dissimulant les arguments et les résultats des outils derrière des représentations d'interface utilisateur d'une simplicité trompeuse.

Il s'agit d'une catégorie de vulnérabilité émergente préoccupante, que nous rencontrerons certainement de plus en plus fréquemment à mesure que l'utilisation des MCP continuera inévitablement de croître. Il sera nécessaire de prendre des mesures minutieuses pour détecter et atténuer cette menace à mesure que les programmes de sécurité de l'entreprise évolueront, et il est essentiel de préparer correctement les développeurs à participer à la solution.

Pourquoi seuls les développeurs compétents en matière de sécurité devraient utiliser les outils d'IA agentiques

Les outils de codage Agentic AI sont considérés comme la prochaine évolution du codage assisté par l'IA, car ils renforcent leur capacité à offrir une efficacité, une productivité et une flexibilité accrues dans le développement de logiciels. Leur capacité accrue à comprendre le contexte et les intentions les rend particulièrement utiles, mais ils ne sont pas à l'abri de menaces telles que les injections rapides, les hallucinations ou la manipulation du comportement de la part des attaquants.

Les développeurs représentent la ligne de défense entre les bonnes et les mauvaises validations de code, et il sera essentiel de maintenir à la fois les compétences en matière de sécurité et de pensée critique pour l'avenir du développement de logiciels sécurisés.

Les résultats de l'IA ne devraient jamais être mis en œuvre avec une confiance aveugle, et ce sont les développeurs expérimentés en matière de sécurité qui appliquent une pensée contextuelle et critique qui peuvent tirer parti en toute sécurité des gains de productivité offerts par cette technologie. Il est toutefois essentiel de travailler en binôme, dans un environnement de programmation où l'expert humain est en mesure d'évaluer et de modéliser les menaces, et, en fin de compte, d'approuver le travail produit par l'outil.

Découvrez comment les développeurs peuvent améliorer leurs compétences et accroître leur productivité grâce à l'IA ici.

Techniques d'atténuation pratiques et lectures complémentaires dans notre dernier article de recherche

Les outils de codage basés sur l'IA et la technologie MCP sont appelés à jouer un rôle important dans l'avenir de la cybersécurité, mais il est essentiel de ne pas nous y engager avant d'avoir évalué le terrain.

Le document Narajala et Habler détaille les stratégies d'atténuation complètes pour la mise en œuvre du MCP au niveau de l'entreprise et la gestion continue de ses risques. En fin de compte, il est centré sur les principes de défense en profondeur et de confiance zéro, ciblant explicitement le profil de risque unique que ce nouvel écosystème apporte à un environnement d'entreprise. Pour les développeurs en particulier, il est essentiel de combler les lacunes en matière de connaissances dans les domaines suivants :

• Authentification et contrôle d'accès: Les outils d'IA agentique permettent de résoudre des problèmes et de prendre des décisions de manière autonome afin d'atteindre les objectifs qui leur ont été fixés, de la même manière qu'un humain aborderait les tâches d'ingénierie. Cependant, comme nous l'avons établi, une supervision humaine qualifiée de ces processus ne peut être ignorée, et les développeurs qui utilisent ces outils dans leurs flux de travail doivent comprendre exactement quels accès ils ont, quelles données ils récupèrent ou sont susceptibles d'exposer, et où elles peuvent être partagées.
• Détection et atténuation générales des menaces: Comme c'est le cas pour la plupart des processus d'IA, pour détecter les failles et les inexactitudes potentielles dans les résultats de l'outil, l'utilisateur doit maîtriser lui-même la tâche. Les développeurs doivent bénéficier d'une mise à niveau et d'une vérification continues de ces compétences afin de réviser efficacement les processus de sécurité et d'examiner le code généré par l'IA avec précision et autorité en matière de sécurité.
• Harmonisation avec la politique de sécurité et la gouvernance de l'IA: Les développeurs doivent être informés des outils approuvés et avoir la possibilité d'améliorer leurs compétences et d'y accéder. Le développeur et l'outil doivent tous deux être soumis à une analyse comparative de sécurité avant que les commits ne soient approuvés.

Nous avons récemment publié un document de recherche sur l'émergence du codage par vibration et du codage assisté par l'IA, ainsi que sur les mesures que les entreprises doivent prendre pour former la prochaine génération d'ingénieurs logiciels alimentés par l'IA. Nous vous invitons à le découvrir et à nous contacter pour renforcer votre équipe de développement dès aujourd'hui.

Une version de cet article a été initialement publiée dans Zone D. Il a été mis à jour et diffusé ici.

La version 4.0 de la norme de sécurité des données de l'industrie des cartes de paiement (PCI DSS) permettra de changer presque tout en matière de sécurité pour toute entreprise ou organisation qui accepte les paiements électroniques, ce qui représente la grande majorité d'entre elles. Il est important de noter que cette mise à jour transformera la plupart des entreprises, les obligeant à mettre à niveau un grand nombre de leurs processus de sécurité et potentiellement à déployer de nouvelles protections concernant le cryptage, l'authentification, le contrôle d'accès, la gestion des clés et d'autres domaines qu'elles ont peut-être mis du temps à adopter auparavant.

En raison de la complexité des nouvelles exigences, les organisations ont jusqu'en mars 2025 pour se mettre pleinement en conformité. Cependant, cette date limite arrivera plus tôt que la plupart des gens ne le pensent. En fait, de nombreuses entreprises avant-gardistes prennent actuellement des mesures pour permettre à leurs développeurs de s'adapter au paysage de conformité en suspens.

Au-delà de la formation à cocher

Les développeurs d'une entreprise sont responsables de la rédaction du code sur lequel repose une grande partie de son infrastructure. Il est donc logique qu'ils constituent un bon point de départ lorsqu'il s'agit de mettre en œuvre les nouvelles exigences PCI DSS 4.0. Cependant, la plupart des développeurs auront besoin d'un soutien stratégique pour améliorer leurs compétences dans le cadre d'un programme de sensibilisation à la sécurité mis à jour. Cela permet de s'assurer qu'ils possèdent l'expérience nécessaire pour mettre en œuvre et maintenir les niveaux de sécurité plus élevés requis par la nouvelle norme.

En réalité, l'exigence 12.6.2 de la norme PCI DSS 4.0 demande aux entreprises de mettre en œuvre un programme de sécurité officiel et de le tenir à jour avec les dernières informations sur les menaces et les techniques de défense. Avec l'ancienne norme, les programmes de sécurité de base ou même la formation annuelle à la conformité de type « cocher les cases » permettaient d'atteindre l'objectif. Cette nouvelle norme impose bien plus encore, allant même jusqu'à exiger que les programmes de formation à la sécurité traitent des menaces et des vulnérabilités spécifiques au sein de l'environnement d'une entreprise. Par exemple, si le vol d'identité constitue un grave problème pour une organisation, la formation doit y remédier.

Il est évident qu'une formation minimale ne sera plus suffisante, que ce soit d'un point de vue pratique ou pour se conformer à la nouvelle norme. Les entreprises doivent plutôt proposer aux développeurs des parcours d'apprentissage complets et adaptés qui leur enseignent à appliquer les meilleures pratiques de sécurité dans leur travail quotidien. En allant au-delà des efforts de conformité minimaux et en fournissant aux développeurs les ressources dont ils ont besoin pour vraiment comprendre la sécurité, les entreprises peuvent donner à leurs développeurs les moyens de prendre de meilleures décisions en matière de sécurité dans l'ensemble, tout en se conformant à la norme PCI DSS 4.0.

La bonne nouvelle est que bon nombre des nouvelles exigences de la norme PCI DSS 4.0 concernent des domaines que la plupart des développeurs connaissent déjà, tels que l'authentification, le cryptage, le contrôle d'accès, la gestion des clés, etc. Lorsque les développeurs disposent de ressources adaptées, pertinentes et familières pour développer leurs compétences, les organisations peuvent plus facilement les préparer aux nouvelles normes et aux responsabilités accrues que la norme PCI DSS 4.0 exigera.

Utiliser la norme PCI DSS 4.0 comme un moyen d'améliorer la sécurité globale

Bien qu'il soit essentiel de répondre aux besoins des développeurs grâce à une bonne formation en matière de sécurité pour se conformer avec succès à la nouvelle norme PCI DSS 4.0, les efforts visant à faire évoluer une organisation vers une meilleure cybersécurité ne doivent pas s'arrêter là. Oui, les exigences sont rigoureuses, mais étant donné que la plupart des organisations devront s'efforcer de s'y conformer, il n'y a aucune raison de ne pas utiliser cet effort comme un tremplin pour renforcer la sensibilisation à la sécurité et la formation en général. Cela permettra non seulement à une organisation de répondre aux exigences de conformité, mais aussi de commencer à favoriser une culture de sécurité positive qui donne la priorité aux meilleures pratiques et garantit que tous les membres de l'organisation travaillent vers le même objectif, axé sur la sécurité.

Il existe une courbe d'apprentissage, bien sûr, mais les développeurs seront probablement d'accord avec un tel effort. Dans une enquête menée par Evans auprès de plus de 1 200 développeurs professionnels travaillant activement dans le monde entier, la grande majorité a déclaré soutenir le concept de création de code sécurisé et d'instauration d'une meilleure culture de la sécurité dans leurs organisations. Il est clair que la plupart des développeurs sont favorables à une transition stratégique et soutenue vers un codage sécurisé et à une redéfinition des priorités de la sécurité dans le cadre du processus de développement.

Les mises à niveau de sécurité imposées par la norme PCI DSS 4.0 offrent une excellente occasion aux entreprises qui souhaitent investir dans l'amélioration des meilleures pratiques et des formations en matière de sécurité, et adopter une meilleure culture globale de la sécurité au sein de leur organisation.

Les développeurs peuvent plus facilement atteindre des niveaux de maturité en matière de sécurité si leurs entreprises investissent dans un programme leur permettant d'intégrer leurs compétences en matière de codage sécurisé à des outils et à des formations pertinents. Cela peut à son tour contribuer à créer une culture de la sécurité dans laquelle les développeurs sont davantage en mesure de prendre de meilleures décisions qui améliorent la posture de sécurité globale de leur organisation bien au-delà des nouvelles normes rigoureuses PCI DSS 4.0.

Après seulement quelques minutes passées à parcourir les actualités technologiques, vous comprendrez rapidement à quel point le paysage des menaces devient préoccupant. Chaque jour semble être marqué par le signalement d'une violation majeure, d'une nouvelle vulnérabilité ou d'une grave menace d'exploitation active par des cyberattaquants et des criminels. Presque tous les indicateurs et rapports du secteur indiquent une augmentation du nombre de cybermenaces, la plupart des experts prévoyant que cette tendance se poursuivra dans les années à venir.

Face à ces nouvelles menaces, les agents de première ligne chargés de la sécurité informatique sont épuisés et en sous-effectif. Bien que les salaires soient élevés et que ce poste soit presque indispensable à toute entreprise ou organisation, il n'y a jamais assez de personnel de sécurité pour répondre à tous les besoins. Dans une enquête récente menée par le Center for Strategic and International Studies, 82 % des décideurs informatiques ont déclaré que leur organisation souffrait d'une pénurie de compétences en cybersécurité, et 71 % ont déclaré que cette pénurie avait entraîné des dommages directs et mesurables pour leurs organisations. Rien qu'aux États-Unis, le rapport indique qu'il y avait plus de 520 000 emplois vacants en cybersécurité dans un domaine où seulement 940 000 personnes sont employées.

À l'échelle mondiale, il existe actuellement environ 3,5 millions de postes vacants dans le domaine de la cybersécurité, ce qui signifie que même les organisations prêtes à investir des sommes considérables pour recruter et fidéliser des professionnels hautement qualifiés rencontrent des difficultés à trouver des candidats adéquats. En moyenne, il faut environ 21 % de temps supplémentaire pour pourvoir un poste dans le domaine de la cybersécurité par rapport à tout autre emploi, si tant est qu'ils puissent être pourvus.

L'activation des développeurs a été négligée pendant une période trop longue.

Nous avons observé dans de nombreux articles précédents que les développeurs peuvent être sollicités pour combler certaines lacunes critiques en matière de défenses de cybersécurité. Cependant, traditionnellement, les développeurs n'étaient jamais formés à la cybersécurité. Leurs performances professionnelles étaient presque entièrement basées sur la rapidité et le délai de déploiement. La sécurité était confiée aux équipes AppSec situées plus loin.

Malheureusement, il ne s'agit pas simplement de changer de vitesse et de demander aux développeurs de commencer soudainement à renforcer la sécurité de leurs applications et de leurs programmes. Même s'ils sont disposés à apporter ces changements, et des enquêtes ont montré que bon nombre d'entre eux le sont, ils ont encore besoin d'une formation pour y parvenir. Ils ont également besoin des encouragements et du soutien de la haute direction, mais le fait de pouvoir bénéficier d'un apprentissage significatif constitue le premier obstacle, et souvent le plus important.

Il n'est pas surprenant que des millions de postes bien rémunérés et hautement sécurisés dans le domaine de la sécurité informatique restent vacants à travers le monde. Si ce travail était facile, tout le monde s'y lancerait. Il est difficile d'apprendre à lutter contre les menaces et à éliminer les vulnérabilités du code, et le paysage des menaces est en constante évolution. Tenter d'enseigner la cybersécurité, même à des développeurs relativement férus de technologie, ne peut être réalisé efficacement à l'aide d'une formation statique qui devient rapidement obsolète, qui n'est pas mémorable et qui n'aura qu'un impact positif minime, surtout si ces exigences s'ajoutent à leurs horaires déjà surchargés.

Construisez un échafaudage pour atteindre un terrain plus élevé

Enseigner les compétences en cybersécurité à l'aide de méthodes traditionnelles revient à tenter de construire un gratte-ciel sans jamais quitter le sol. Cela n'est pas possible, car les étudiants ne disposent pas des bases nécessaires pour maîtriser les nombreux concepts de niveau supérieur d'un domaine complexe tel que la cybersécurité. Pour compenser, le concept d'apprentissage par étapes peut être utilisé.

Lorsqu'on utilise une approche progressive ou « stratifiée » de l'amélioration des compétences, les sujets plus généraux sont généralement divisés en expériences ou concepts d'apprentissage distincts. Cela garantit que les étudiants sont en mesure de maîtriser chaque concept à l'aide d'exercices et d'instructions appropriés, en fournissant tout le soutien nécessaire pour chaque composante. Des concepts plus récents et 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. De cette manière, les étudiants peuvent atteindre des niveaux de compréhension et d'acquisition de compétences supérieurs à ceux qu'ils seraient capables de maîtriser sans assistance.

Tout comme les échafaudages physiques, ce support est supprimé progressivement lorsqu'il n'est plus nécessaire, avec une plus grande responsabilité envers les étudiants à mesure qu'ils deviennent plus compétents.

L'apprentissage par échafaudage est principalement utilisé pour réduire les émotions négatives et la perception de soi que les élèves peuvent ressentir lorsqu'ils sont frustrés, intimidés ou découragés lorsqu'ils tentent une tâche difficile sans assistance. Cependant, cette approche peut également s'avérer très utile lorsqu'il s'agit d'aborder un concept extrêmement complexe tel que la cybersécurité moderne. Loin d'être une manière de traiter les développeurs comme des enfants, elle est extrêmement utile lorsque leur expérience avec l'équipe de sécurité peut avoir le même effet frustrant et décourageant, en particulier lorsque leurs efforts sont récompensés par des corrections de bogues et de nouvelles critiques.

Lorsque les développeurs disposent d'outils leur permettant de comprendre les principes fondamentaux du codage sécurisé (en commençant généralement par le Top 10 de l'OWASP), ils peuvent constater par eux-mêmes comment les bogues de sécurité se produisent, pourquoi ils sont dangereux et comment y remédier avant qu'ils ne soient mis en production. À partir de là, ils peuvent approfondir leurs connaissances en s'attaquant à des vulnérabilités plus complexes et en acquérant une expérience pratique de l'application de bonnes corrections. Les couches s'élargissent progressivement, puis lorsqu'il s'agit de problèmes de sécurité avancés tels qu'une architecture logicielle non sécurisée ou la modélisation des menaces, ces avancées ne semblent plus aussi intimidantes et peuvent être abordées avec précision.

En tant qu'industrie, nous ne devons jamais attendre des développeurs qu'ils deviennent des experts en sécurité, mais les organisations peuvent adopter de nouvelles normes pour aider les développeurs à produire des logiciels de meilleure qualité. De plus, pour les organisations dont les ingénieurs perfectionnent leurs compétences, chaque étape du processus, ou chaque niveau d'échafaudage, se traduira directement par une meilleure cybersécurité au fur et à mesure de leur apprentissage. Il n'est pas nécessaire d'attendre la fin d'un cours pour constater les résultats.

Il est difficile de se renseigner sur la cybersécurité, et il est presque impossible de la maîtriser sans l'aide et les instructions appropriées. Adopter un programme de sécurité assorti d'un apprentissage structuré peut vous aider à en tirer le meilleur parti, les avantages devenant évidents presque immédiatement. Les améliorations débuteront presque immédiatement et s'amélioreront continuellement au fil du temps.

Nous vous invitons à commencer à former des développeurs performants en matière de sécurité avec nous ; découvrez :

Cours
Missions
Formation pour développeurs

... et bien plus encore !

Nous avons récemment eu le plaisir de voir la première publication du Forbes Technology Council par notre président-directeur général, Pieter Danhieux, en ligne. L'article expliquait en quoi le renforcement des compétences des développeurs pour créer un code plus sécurisé est essentiel pour prévenir les cyberattaques et les violations de données. De plus, il a révélé comment ces mêmes développeurs soucieux de la sécurité peuvent contribuer à fournir un code de meilleure qualité et plus sécurisé, plus rapidement que ne le pensent de nombreux services informatiques. La nécessité de cette approche est certainement impérieuse. Une étude récente a révélé qu'une cyberattaque se produit désormais toutes les 39 secondes, et nous avons tous été témoins des perturbations causées par une seule attaque de ransomware réussie sur le pipeline Colonial, qui, dans l'ensemble, n'était pas aussi destructrice que le piratage de SolarWinds.

‍

De nombreuses vulnérabilités courantes persistent car personne n'a jamais pris la peine de montrer aux développeurs comment remplacer les mauvais modèles de codage par une meilleure méthode d'exécution des mêmes fonctions, de manière plus sûre et plus sécurisée. Et l'impact de la correction d'un logiciel à un stade avancé de son développement est extrêmement coûteux, à la fois en termes d'heures passées et de retards de déploiement. Corriger le code une fois qu'il a été déployé, en particulier lorsqu'un attaquant a exploité une vulnérabilité non découverte auparavant, peut parfois coûter des millions de dollars. Cela ne tient pas compte de l'atteinte à la réputation d'une entreprise à la suite d'une violation majeure.

Les développeurs formés à la sécurité deviennent naturellement de meilleurs codeurs. Les RSSI ne devraient certainement pas abandonner leurs outils de sécurité de sitôt, mais en adoptant une approche de sécurité inclusive et préventive depuis le sommet, les RSSI peuvent tirer parti de la plus grande ressource de leur entreprise, le facteur humain, en particulier lorsqu'il s'agit de sécuriser le codage dès le début du cycle de développement logiciel.

Pour ce faire, voici les trois principales stratégies de haut niveau à considérer.

1. Soyez proactif, pas réactif

Les entreprises tombent fréquemment dans le piège de la réactivité, par exemple en réagissant aux actions de la concurrence au lieu de développer et de poursuivre une vision unique. Beaucoup adoptent également cette approche lorsqu'il s'agit de failles de sécurité dans le code, ne prenant la cybersécurité au sérieux que lorsqu'elles y sont contraintes à la suite d'une violation réussie. Malheureusement, à ce moment-là, le mal est déjà fait : les amendes, les frais de recouvrement, la perte de clients et la restauration de la marque ont des répercussions sur les résultats financiers. Une autre forme de réaction plutôt que d'action consiste à s'appuyer sur l'analyse automatique ou manuelle du code pour détecter les vulnérabilités dans le code existant au lieu de se concentrer sur la création d'un code sécurisé dès le départ. Malheureusement, la numérisation du code n'est pas une solution parfaite, ce qui signifie que plus le code contient de vulnérabilités, plus il y a de chances que certaines d'entre elles passent à travers.

Seulement en adoptant une approche proactive et en collaborant avec les développeurs pour les aider à créer un code sécurisé dès le départ, vous pourrez établir un cycle de vie de développement logiciel qui réduit considérablement la possibilité que des vulnérabilités de codage soient divulguées aux utilisateurs.

2. Veuillez améliorer vos compétences, sans exagérer.

Une fois que vous avez décidé de fournir aux développeurs les connaissances nécessaires pour créer du code sécurisé, choisissez judicieusement votre approche. Les ateliers de formation internes qui interrompent le codage frustrent aussi bien les développeurs que les managers. Les cours hors site qui nécessitent une participation le soir ou le week-end sont encore moins populaires. La meilleure approche consiste à développer progressivement les compétences en matière de codage, en fournissant des informations pertinentes étape par étape pendant le processus de codage, ce qui permet essentiellement d'améliorer les compétences sans distraire les développeurs de manière significative ni ralentir le processus de développement.

3. Encouragez, ne présumez pas

Les développeurs ne doivent pas percevoir le renforcement des compétences en matière de sécurité comme une contrainte ou une corvée. Les responsables doivent inspirer les développeurs en expliquant le rôle important que joue le code sécurisé dans le succès de l'entreprise. Il est également essentiel de faire comprendre que les codeurs sécurisés sont plus précieux pour l'entreprise et bénéficieront d'opportunités de carrière élargies à l'avenir.

L'administration Biden est bien accueillie Décret exécutif a mis davantage l'accent sur la cybersécurité et sur la nécessité « d'inclure des critères pour évaluer les pratiques de sécurité des développeurs et des fournisseurs eux-mêmes, et d'identifier des outils ou des méthodes innovants pour démontrer la conformité aux pratiques sécurisées ». Cependant, si les outils sont essentiels, ils ne suffisent pas. Aucun outil ne supprimera complètement la capacité d'un individu à ignorer, à mal comprendre, à abuser ou à contourner les systèmes et les outils mis en place. Pour optimiser la sécurité de leurs entreprises, les RSSI doivent tirer parti du facteur humain et encourager les développeurs à devenir des partisans et des praticiens volontaires de la sécurité.