Récemment, l'OWASP publiait son top 10 des vulnérabilités LLM et GenAI. Si le Vibe Coding est encouragé par les éditeurs et comme tendance IA du moment, malheureusement, les vulnérabilités sont nombreuses et le code généré par les agents et LLM ne doit pas être utilisé aveuglement. LegitSecurity démontre que le code généré par GitLab Duo pose de réels problèmes. Les vulnérabilités sont là et impactent directement la sécurité. 

"C'est exactement ce que nous avons découvert : une vulnérabilité par un prompt injection qui permet aux attaquants de voler le code source de projets privés, de manipuler les suggestions de code affichées à d'autres utilisateurs et même d'exfiltrer des vulnérabilités zero-day confidentielles et non divulguées, le tout via GitLab Duo Chat" indique les chercheurs. 

Les chercheurs se sont inspirés de l'OWASP pour tester GitLab Duo et voir comment maninuper la GenIA. Une des étapes est d'utiliser le prompt et manoeuver la GenIA : "pourrions-nous intégrer des instructions cachées dans différentes parties d'un projet GitLab tout en influençant le comportement de Duo ?" Les tests sont faits en utilisateurs invités. Toutes les demandes sont passées ! "Parce que pour générer des réponses utiles, Duo analyse l'intégralité du contexte de la page, y compris les commentaires, les descriptions et le code source, ce qui la rend vulnérable aux instructions injectées cachées n'importe où dans ce contexte." explique l'étude.

Découvrir l'ensemble des manipulations : https://www.legitsecurity.com/blog/remote-prompt-injection-in-gitlab-duo

GitLab a été mis au courant des vulnérabilités. "Après avoir révélé le problème le 12 février 2025, GitLab a confirmé la vulnérabilité d'injection HTML et a également reconnu l'injection d'invite comme un problème de sécurité. GitLab a confirmé que les deux vecteurs avaient été corrigés." Des patchs ont été déployés par combler les failles. 

En conclusion : "Cette vulnérabilité met en évidence le caractère à double tranchant des assistants IA comme GitLab Duo : lorsqu'ils sont profondément intégrés aux workflows de développement, ils héritent non seulement du contexte, mais aussi des risques. En intégrant des instructions cachées dans un contenu de projet apparemment inoffensif, nous avons pu manipuler le comportement de Duo, exfiltrer du code source privé et démontrer comment les réponses de l'IA peuvent être exploitées à des fins imprévues et néfastes."

Parmi les tendances de cybersécurité, le post-quantique agite beaucoup les experts et les éditeurs de solutions, du moins nous le supposons. L'ANSSI regarde naturellement ce qu'il se passe sur la cryptographie post-quantique (ou PQC) et sa prise en compte par les entreprises et les institutions. L'agence française vient de publier une étude réalisée depuis 2023 et le résultat n'est pas brillant.

" La transition post-quantique concerne en premier lieu la cryptographie asymétrique, notamment pour les usages en confidentialité et échanges de clé pour se prémunir contre des attaques rétroactives. Les primitives cryptographiques actuellement déployées (« pré-quantiques ») sont bien maîtrisées par les développeurs en cybersécurité et il en existe de nombreuses implémentations efficaces et robustes, sous forme de bibliothèques commerciales ou libres. La situation des futurs standards post-quantiques est différente. En effet, seuls quelques spécialistes du domaine maîtrisent complètement ces primitives. Des implémentations efficaces et durcies – qu’elles soient logicielles ou sur plateforme matérielle – vont demander beaucoup de temps et d’efforts. De même, les mécanismes et protocoles qui mettent en oeuvre ces nouvelles primitives sont récents et ne jouissent pas du même niveau d’assurance et de confiance dans leur niveau de sécurité. Ce constat global s’applique autant aux algorithmes d’établissement de clé qu’aux signatures numériques." introduit l'ANSSI.

Les primitves post-quantique seraient maîtrisées par les développeurs en cybersécurité. Nous ne serons pas aussi affirmatifs que l'ANSSI. Non, de nombreux experts et développeurs en sécurité ne connaissent pas ou maîtrisent mal ces concepts. Déjà le terme même de post-quantique reste souvent nébuleux. De même, "De même, les mécanismes et protocoles qui mettent en oeuvre ces nouvelles primitives sont récents et ne jouissent pas du même niveau d’assurance et de confiance dans leur niveau de sécurité. Ce constat global s’applique autant aux algorithmes d’établissement de clé qu’aux signatures numériques.". Oui le post-quantique est relativement récent mais nous disposons dores et déjà d'une base solide : la PQC poussée par l'agence américaine NIST. Ces "standards" sont aujourd'hui ceux qui sont les plus utilisés par les éditeurs de solution de sécurité. Et les Etats-Unis poussent au déploiement du PQC. Sur ce point, la France est en retard et les seuls "standards" réellement utilisés sont ceux du NIST. 

"Plus de la moitié des bénéficiaires de l’ANSSI interrogés semble dès aujourd’hui être à risque vis-à-vis de la menace de l’ordinateur quantique. En cause : leur recours à des pratiques vulnérables aux attaques rétroactives, telles que l’usage de VPN pour transmettre des informations sensibles dont la confidentialité doit être assurée pour une durée supérieure à 10 ans, ou l’exploitation de certificats dont la durée de vie excède également 10 ans. La grande majorité des bénéficiaires a connaissance de cette menace quantique d’un point de vue théorique ; mais l’impact concret de celle-ci sur leurs systèmes d’information ne leur est pas connu." poursuit l'agence.

L'ANSSI pointe un problème crucial : la compréhension de la PQC et les risques liés. Une attaque quantique sur la cryptographie actuelle peut théoriquement cassée toutes les clés. C'est peut-être largement théorique, le risque est réel. L'étude déplore une absence de plan de transition vers le post-quantique. 

"L’enquête fait très nettement ressortir un fort besoin d’accompagnement de ces entités par des prestataires externes, tant pour les travaux préparatoires d’élaboration d’un plan de transition (analyse de risque quantique, identification des cas d’usages prioritaires, inventaire des actifs cryptographiques, classification des données) que pour accompagner la transition elle-même (formation, conseil, transformation, suivi des fournisseurs, mise à jour des applications métier, etc.)." explique l'agence. 

Les équipes de cybersécurité manqueraient de budget et de compétences. Mais les répondants à l'étude attendent un soutien actif de l'ANSSI pour cette transition PQC. Sous-entendu, on rejette la responsabilité du PQC sur l'ANSSI. Or, l'agence rappelle le rôle des équipes et de la direction générale et qu'elle n'est pas là pour faire le travail des équipes et des directions générales.

L'étude pointe 4 raisons sur l'absence de la PQC :

- une mauvaise compréhension des enjeux et les risques réels de la PQC

- un manque financier et de compétences

- un manque d'offres réelles de PQC pour entamer (ou planifier) la transition PQC

- pas d'obligation réglementaire : l'ANSSI précise que la réglementation est malheureusement parfois la seule contrainte efficace ! Bref : on ne bouge pas et on verra bien sauf si on est obligé de le faire !

L'étude conclut sans détour : "Face à ces observations, l’ANSSI rappelle l’importance de démarrer sans tarder les actions préparatoires à la transition post-quantique, dans tout type d’organisations. Il est important que chaque organisation évalue son niveau de risque réel vis-à-vis de la menace quantique et élabore son plan de transition. Certaines actions devront être mises en oeuvre sans délai et d’autres, progressivement, sur les années à venir."

Source : Etude de l'ANSSI sur la transition post-quantique, mars 2025 (avec mise à jour de mai 2025)

Comment rendre plus autonome l'AppSec ? Checkmarx veut pousser les agents IA au coeur de l'AppSec. « La plateforme AppSec Checkmarx One  a récemment dépassé les 500 milliards de lignes de code analysées chaque mois. Cette échelle sans précédent, et les enseignements qui en découlent, constituent le socle de notre vision de l’IA agentique — une approche qui repose sur des volumes massifs de données pour entraîner efficacement les grands modèles de langage (LLM) et renforcer leur pertinence dans des contextes applicatifs réels», a déclaré Sandeep Johri, CEO de Checkmarx. « L’Agentic AI Summit consacre plus de dix ans d’innovation vers une sécurité applicative pilotée par l’intelligence artificielle. »

L'éditeur présentera son approche durant un webinaire le 24 juin prochain. Le Sommet aura lieu le 24 juin 2025 à 13h00, heure de la côte Est (Eastern Time) soit à 19h00, heure de Paris (CEST) en présence de : 

• Sandeep Johri, CEO, Checkmarx 
• Jonathan Rende, CPO, Checkmarx 
• Katie Norton, Research Manager, DevSecOps et Supply Chain Security, IDC 
• Steve Yegge, Software Engineer, Sourcegraph et co-auteur du “Vibe Coding”
• Ori Bendet, VP of Product Management, Checkmarx 
• Andrew Zigler, défenseur des développeurs (Developer Advocate) chez LinearB et animateur du podcast Dev Interrupted

Pour participer à ce webinaire : https://www.checkmarx.ai/?utm_source=press_release&utm_medium=referral&utm_campaign=agentic_ai

Pen Test Partners, spécialisé dans le pentest, a voulu voir si Copilot pouvait accéder et lire des fichiers sensibles à accès restreint. Le test fut mené avec Copilot pour Sharepoint. Les testeurs ont pu lire un fichier protégé contenant des mots de passe alors que Sharepoint n'avait pas autorisé l'accès. Copilot a bypassé la restriction ! L'agent IT a pu afficher tout le contenu normalement inaccessible... 

Cela prouve donc des trous dans la sécurité à cause de Copilot sur Windows. Le PoC se limite à SharePoint mais l'équipe de pentesteurs a découvert d'autres possibilités qui n'ont pas été publiées pour le moment. 

Démonstration complète : https://www.pentestpartners.com/security-blog/exploiting-copilot-ai-for-sharepoint/

Suite à la conférence Pwn2Own, Mozilla déploie en urgence une mise à jour de sécurité : la 138.0.4. Elle fixe 2 vulnérabilités jugées sévères et exploitées durant la conférence de hacking : les CVE-2025-4918 et 4919. 

Ces deux vulnérabilités permettent de lire et écrire des objets JavaScript, provoquant une corruption de mémoires, donner accès à des données de l'utilisateur ou encore permettre d'exécuter du code malveillant. 

Note d'information : https://blog.mozilla.org/security/2025/05/17/firefox-security-response-to-pwn2own-2025/

Dans près d’une entreprise logicielle sur deux, la responsabilité du suivi de la sécurité n’est plus du ressort de la RSSI. C'est l'étonnante conclusion du rapport A CISO's guide to steering AppSec in the Age of DevSecOps publié par Checkmarx.

"À mesure que les applications gagnent en complexité et en évolutivité, sous l’effet combiné de l’intelligence artificielle, des micro-services et des architectures hybrides, les équipes d’ingénierie assument une responsabilité croissante dans la livraison de solutions à la fois sécurisées et évolutives. Dans un contexte de cycles de développement toujours plus courts et de lignes de code en constante expansion, les décisions stratégiques en matière d’AppSec, tout comme les budgets qui les accompagnent, sont de plus en plus transférés aux développeurs. Objectif : intégrer la sécurité dès les premières étapes du cycle de développement de manière plus efficace." explique l'annonce du rapport.

Le Secure by Design est un débat depuis 30 ans. Oui, il faut que la sécurité se fasse dès la conception et dans le code. Les équipes doivent s'assurer d'un code de qualité, respecter les règles de codage. Rappelons qu'un bug, ou une faille, découvert seulement en production ou en phase finale de développement, coûte cher à corriger car il faut lancer une itération. Plus le problème est identifié tôt, plus il est "rapide" à fixer. Le secure by design, ou l'AppSec au sens large, permet de réduire la surface d'attaque potentielle et réduire l'impact des TOP 10 de l'OWASP. 

Mais attention, les équipes sécurité, et donc le RSSI, ne doivent pas se décharger du AppSec et de tout faire peser sur les développeurs. Ce serait une erreur. Il ne faut pas oublier que l'AppSec dépasse le rôle du développeur et concerne l'ensemble du cycle de l'application. 

• 49 % des RSSI interrogés déclarent que les acheteurs prennent régulièrement en compte la sécurité des applications dans leurs décisions d'achat.
• 24 % indiquent que la sécurité applicative est toujours un critère déterminant dans ces choix. 
• Cette tendance est particulièrement marquée en Europe, où 58 % des répondants affirment que la sécurité est systématiquement prise en compte, contre 33 % en Asie-Pacifique et seulement 8 % en Amérique du Nord.

Il serait temps que la sécurité par défaut soit un critère mais malheureusement, les délais toujours plus serrés nuient à l'AppSec car encore trop souvent, les développeurs doivent travailler dans l'urgence ou avec des spécifications floues ou trop complexes. D'autre part, avec des codes générés par l'IA dont la sécurité et la qualité ne sont pas forcément assurées, on introduit une nouvelle incertitude dans l'AppSec.

L'étude de Checkmarx met également en lumière une décentralisation croissante des décisions en matière de sécurité, avec un rôle renforcé des équipes de développement, tant sur le plan opérationnel que budgétaire. Dans les entreprises développant des ogiciels, la responsabilité de la sécurité est désormais partagée :

• 50 % continuent de l’attribuer aux RSSI,
• 43 % la transfèrent aux équipes de développement.
• 56 % des organisations indiquent que la majorité de leurs équipes de développement sont pleinement intégrées aux programmes AppSec

Oui, il était temps que les développeurs soient pleinement intégrés au AppSec mais, comme nous l'avons dit plus haut, il ne faut pas que le RSSI s'en lave les mains : "ah non, c'est pas moi, c'est lui". « À mesure que la responsabilité de la sécurité se déplace vers les équipes de développement, les budgets suivent la même voie. Les RSSI doivent désormais exercer leur influence non pas en imposant des barrières, mais en définissant un cadre clair : protéger sans freiner l’innovation. » poursuit Jonathan Rende.

Pour faire du secure by design, de l'AppSec au niveau du code, il faut sensibiliser, former, établir des règles claires, laisser le temps nécessaire.

Si 62 % des RSSI déclarent présenter des indicateurs AppSec à leur conseil d’administration, la majorité d’entre eux se contentent de rapporter le volume de vulnérabilités, sans les relier à des enjeux métier concrets. Seuls 25 % parviennent à établir un lien clair entre ces risques techniques et leurs conséquences sur la réputation de la marque, la conformité réglementaire ou la performance économique. Ce décalage illustre l’urgence, pour les RSSI, de repositionner la sécurité dans une logique de gestion des risques business, condition indispensable pour obtenir un engagement durable de la Direction.

Le gouvernement fédéral américain poursuit les coupes dans les budgets des agences officielles. C'est au tour de l'agence de la sécurité des infrastructures et de la cybersécurité d'être confrontée aux menaces et aux coupes budgétaires. La CISA pourrait perdre 491 millions $.

La CISA est accusé par Trump de contribuer à la censure et d'abandonner sa mission première. La menace est pour le moment de pure forme car le congrès américain doit valider cette réduction qui représente 17 % du budget de fonctionnement de l'agence. Un des reproches concerne la sécurité des élections et le président évoque les résultats de 2020 et la victoire de Biden. La maison blanche veut que la CISA se recentre sur les missions premières et qu'elle se préoccupe plus de censurer que de protéger les intérêts du pays. 

La CISA emploie 3 600 personnes et possède un budget de 3 milliards $. 

L'éditeur Armis lance Armis Vulnerability Intelligence. Cette nouvelle base de données a l'ambition d'agréger les vulnérabilités exploitées, les menaces et des compléments d'informations liées à ces vulnérabilités. Cette base est communautaire et gratuite. 

Le projet est alimenté par les données d'Armis Labs et des diverses solutions de l'éditeur. "La base de données Armis Vulnerability Intelligence est une ressource clé, pensée par la communauté pour la communauté de la cybersécurité. Elle transforme les données de vulnérabilités en informations concrètes, permettant aux entreprises de mieux se protéger contre les cybermenaces grâce à une adaptation plus rapide et des prises de décisions éclairées." explique Nadir Izrael, CTO et cofondateur d'Armis.

Pour Armis, il s'agit d'aider les entreprises à réagir plus vite et si possible avant une attaque : 58 % des grandes entreprises réagissent après l'attaque et les conséquences de celle-çi. Par ailleurs, près d'un quart (22 %) des décideurs informatiques reconnaissent l'absence d’une évaluation continue des vulnérabilités comme une faiblesse dans leurs dispositifs de sécurité, et nombreux sont ceux qui s’appuient encore sur des feuilles Excel pour suivre les vulnérabilités et les résultats de sécurité. Ces lacunes doivent ainsi être comblées en amont pour éviter les impacts négatifs.

Site : https://cve.armis.com/

JFrog a publié rson rapport Software Supply Chain State of the Union 2025. Il dresse un panorama de la sécurité sur les plateformes de supply chain logiciels. Cette dernière étude confirme les problèmes de sécurité autour de l'IA et des modèles LLM qui ne cessent de progresser. 

"De nombreuses organisations adoptent avec enthousiasme les modèles ML publics pour stimuler l'innovation rapide, démontrant un engagement fort à exploiter l'IA pour la croissance. Cependant, plus d'un tiers d'entre elles comptent encore sur des efforts manuels pour gérer l'accès aux modèles sécurisés et approuvés, ce qui peut conduire à des négligences potentielles," a déclaré Yoav Landman, CTO et co-fondateur de JFrog. "L'adoption de l'IA va croître encore plus rapidement. Par conséquent, pour que les organisations prospèrent à l'ère de l'IA, elles doivent automatiser leurs chaînes d'outils et leurs processus de gouvernance avec des solutions prêtes pour l'IA, garantissant qu'elles restent à la fois sécurisées et agiles tout en maximisant leur potentiel d'innovation."

Principaux éléments du rapport :

• une combinaison de vulnérabilités de sécurité menace la chaîne d'approvisionnement logicielle : on peut citer les multiples CVE, les packages malveillants (qui se multiplient partout), les expositions de secrets, et les mauvaises configurations/erreurs humaines. Par exemple, l’équipe de recherche en sécurité de JFrog a détecté 25 229 secrets/tokens exposés dans des registres publics (augmentation de 64 % par rapport à l'année précédente). La complexité croissante des menaces de sécurité logicielle rend plus difficile le maintien d’une sécurité cohérente dans la chaîne d'approvisionnement logicielle.
• La prolifération et les attaques des modèles AI/ML augmentent : En 2024, plus de 1 million de nouveaux modèles ML ont été ajoutés sur Hugging Face, accompagnés d'une augmentation de 6,5x des modèles malveillants, ce qui indique que les modèles AI et ML deviennent de plus en plus une cible privilégiée pour les acteurs malveillants.
• La gouvernance manuelle des modèles ML augmente les risques : la majorité des entreprises (94 %) utilisent des listes certifiées pour gouverner l'utilisation des artefacts ML, mais plus d'un tiers (37 %) de ces entreprises s'appuient sur des efforts manuels pour créer et maintenir leurs listes de modèles ML approuvés. Cette dépendance excessive à la validation manuelle crée de l'incertitude sur l'exactitude et la cohérence de la sécurité des modèles ML.

• Le manque de scans de sécurité est un véritable angle mort : la situation est à la fois alarmante et incomphérensible ! Seulement 43 % des professions de l'IT disent que leur entreprises réalisent des scans de sécurité à la fois sur le code et les binaires. Il y a un mieux par rapport à 2024 mais ce n'est pas glorieux pour les entreprises

• Les vulnérabilités critiques continuent d'augmenter : En 2024, les chercheurs en sécurité ont divulgué plus de 33 000 nouveaux CVE, soit une augmentation de 27 % par rapport à 2023, dépassant le taux de croissance de 24,5 % des nouveaux packages logiciels. Cette tendance soulève des inquiétudes car le nombre croissant de CVE augmente la complexité et la pression sur les développeurs et les équipes de sécurité, pouvant freiner l'innovation. Par ailleurs, l’équipe de sécurité de JFrog a constaté que seulement 12 % des CVE de haut niveau notées "critiques" (CVSS 9.0-10.0) par les organisations gouvernementales justifient le niveau de sévérité critique qui leur a été attribué, car elles sont susceptibles d'être exploitées par des attaquants₁. Ce modèle est préoccupant en raison d'une méthodologie de notation centralisée et inchangée au fil du temps, ce qui augmente le risque de faux positifs dans les évaluations et contribue à la "fatigue de vulnérabilité" chez les développeurs.

  Le manque de visibilité sur l'origine des codes utilisés est toujours d'actualité (le vibe coding va contribuer à faire exploser ce problème) et constitue une réelle menace pour l'intégrité des apps. Tout comme, il est totalement anormal de télécharger des extensions et des templates pour son IDE sans un minimum de vérification. 

  Les hacks et vulnérabilités concernent les OS, les langages, les frameworks, les codes !