Longtemps considérée comme une question reléguée à un futur lointain, la cryptographie post-quantique (PQC) est aujourd’hui une réalité. Keyfactor a relevé les 6 excuses les plus courantes et explique pourquoi il est urgent de les dépasser.

1. « Nous ne savons pas quels algorithmes seront nécessaires »

Cet argument ne tient plus puisque le NIST a publié les premiers standards PQC en août 2024. Les entreprises disposent désormais d’une base solide pour tester leur interopérabilité et renforcerleur agilité cryptographique. Attendre que « tout soit finalisé » reviendrait à retarder inutilement une transition inévitable.

2. « Nous attendons de voir ce que font les autres »

A l’ère quantique, temporiser revient à s'exposer et à mettre en danger son activité. Les cybercriminels appliquent déjà la tactique du « Harvest Now, Decrypt Later », en collectant aujourd’hui les données pour les déchiffrer demain grâce à la puissance quantique. Pourtant, 24 % des entreprises préfèrent attendre que d’autres ouvrent la voie pour les suivre. Un pari risqué : chaque jour perdu réduit le temps de migration et augmente l’exposition aux menaces. 

3. « Ce n’est pas notre priorité absolue »

De nombreuses entreprises continent de reléguer la transition vers le PQC au second plan, alors même que : 

• 72 % des décideurs reconnaissent qu’il s’agira d’une transition majeure,
• 20 % estiment même qu’il s’agira du défi le plus important depuis le passage à l’an 2000,

Malgré cette prise de conscience, seuls 28 % des dirigeants ont alloué un budget et des ressources humaines pour mener leur migration vers la PQC. Ce décalage entre conscience du risque et action concrète pourrait avoir de graves conséquences. Par ailleurs, les entreprises dont l’autorité de certification racine expire dans les 3 prochaines années doivent obligatoirement préparer leur infrastructure PKI de nouvelle génération.

4. « Nous attendrons que les risques soient imminents »

Un tiers des entreprises (33%) n’envisagent d’agir que lorsque la menace sera tangible. C’est ignorer que le PQC n’est pas une simple mise à jour « clé en main » : il s’agit d’un projet qui exige uninventaire des systèmes, une planification et des tests approfondis. Ce processus prendra plusieurs années. Lorsque la menace sera avérée, il sera probablement déjà trop tard pour réagir. 

5. « Les normes et les délais ne sont toujours pas clairs »

C’était peut-être le cas hier mais aujourd’hui le NIST a officialisé les premiers standards PQC et l’Union Européenne a fixé des stratégies claires d’ici 2026 et impose des mises à jour critiques à réaliser avant 2030. Autrement dit, le calendrier est désormais établi et attendre n’a plus de raison d’être.

6. « Nous ne disposons pas des ressources nécessaires »

C’est l’un des arguments les plus fréquents : 40 % des entreprises font état d’un manque de compétences internes, et 31 % invoquent des contraintes budgétaires. Bien que réels, ces freins ne sont pas insurmontables. Comme pour toute évolution majeure de cybersécurité, la clé est de convaincre la direction (avec des arguments solides) et de constituer des équipes d’experts internes sont sécuriser le budget et les talents nécessaires.

« Trop tôt ? Non, déjà urgent » résume parfaitement la situation. La cybersécurité post-quantique n’est pas un chantier que l’on peut repousser. Les normes existent, le calendrier est fixé, et la migration nécessitera plusieurs années mais reporter sa mise en œuvre ne fait qu’accroître les risques.

Pour améliorer la sécurité de NuGet et renforcer la confiance dans les packages, NuGet.or renforce sa sécurité avec le Trusted Publishing. Il s'appuie sur GitHub Actions. L'idée est d'utiliser le GitHub OIDC token ayant une courte vie pour être la clé API NuGet. Ces clés expirent après environ 1h. De facto, la surface de vulnérabilité se réduit et NuGet retire les secrets ayant une longue vie.

Les avantages :

- pas de longue vie des secrets

- des credentials à vie courte, environ 1h

- 1 token = 1 clé

Pour utiliser Trusted Publishing, il faut sélectionner l'action dans le menu utilisateur. 

Annonce et exemple : https://devblogs.microsoft.com/dotnet/enhanced-security-is-here-with-the-new-trust-publishing-on-nuget-org/

Depuis quelques mois, les attaques contre la supply chain logicielle se multiplient et constituent une menace malheureusement trop souvent ignorée des développeurs. Or, si des paquets NPM sont compromis, potentiellement, VOTRE propre chaîne peut l'être si vous récupérez des paquets malveillants. "Pour faire face à une augmentation des attaques contre le registre de packages, GitHub renforce la sécurité de npm avec une authentification plus stricte, des jetons granulaires et une publication de confiance améliorée pour restaurer la confiance dans l'écosystème open source." introduit GitHub.

Il faut de la transparence et apporter des réponses à ces attaques notamment contre NPM. Une des dernières en date remonte au 14 septembre avec l'attaque Shai-Hulud qui a compromis des comptes et injecter des scripts post-installation dans des packages très utilisés. En réponse à cette attaque, GitHub a retiré plus de 500 packages et NPM a bloqué l'upload de nouveaux paquets ayant un indice de compromission élevé.

Pour répondre à ces attaques, de plus en plus fréquentes et massives, GitHub a décidé de réagir et propose de changements dans les mécanismes de sécurité :

- authentification à 2 facteurs (2FA) pour les publications locales

- tokens avec durée de vie limitée à 7 jours

- publication certifiée et vérifiée pour pallier aux faiblesses des tokens

- dépréciation des tokens actuels

- interdire les tokens par défaut

- pas de bypass 2FA

GitHub sait que ces nombreux changements impacteront les développeurs : "Nous sommes conscients que certaines des modifications de sécurité que nous apportons peuvent nécessiter des mises à jour de vos workflows. Nous allons déployer ces changements progressivement afin de minimiser les perturbations tout en renforçant la sécurité de npm. Nous nous engageons à vous accompagner tout au long de cette transition et vous fournirons les prochaines mises à jour avec des échéanciers clairs, de la documentation, des guides de migration et des canaux d'assistance."

Pour les mainteneurs de paquets NPM, GitHub préconise une utilisation de la publication de confiance au lieu de tokens, généraliser le 2FA et utiliser WebAuthn au lieu de TOTP

Notre avis : GitHub a le mérite de prendre en main la sécurité des packages et d'inciter à des changements profonds même s'il doit les imposer. Il y a trop d'attaques et de campagnes de phishing contre NPM, PyPi, etc. Et malheureusement, la réponse de ces référentiels est malheureusement trop lente, pis, inexistante. La supply chain de développement est vitale. Sa compromission est une réelle danger pour les développeurs, les entreprises et in fine, les utilisateurs. 

Changez vos identifiants PyPi au plus vite ! C'est un peu le conseil urgent de Seth Larson, expert en sécurité à la fondation Python. Une nouvelle campagne de phishing s'attaque à PyPi. Les hackers veulent semer le doute dans les noms de domaine utilisés. Ce phishing cible les utilisateurs de PyPi via une campagne de faux mails demandant à vérifier l'adresse mail pour une maintenace de sécurité (sic). Ce faux mail utilise le domaine pypi-mirror.org. Seth précise que ce domaine ne dépend pas de PyPi ou de la fondation. 

Si vous avez cliqué sur le lien : changer immédiatement vos identifiants et vérifier vos logs et historique d'activité.

Le post de Seth : https://blog.pypi.org/posts/2025-09-23-plenty-of-phish-in-the-sea/ 

Kali Linux est une des distributions Linux pour le pentest et le hacking les plus connues. La version 2025.3 vient d'être annoncée. Elle est toujours basée sur Debian.  Elle introduit une dizaine de nouveaux outils dont Nexmon. Nexmon permet de monitorer et de faire de l'injection vers une Raspberry Pi. Parmi les nouveaus outils de hack, citons Caido et Caido-cli, un outil d'audit pour la sécurité web, Gemini CLI, vwifi-dkms, pour éprouver le réseau wifi. llm-tools-nmap permet d'utiliser un LLM pour découvrir et scanner ne nmap. A noter que ARMel n'est plus supporté. 

Liste complète des outils introduits dans la 2025.3 :

• Caido - The client side of caido (the graphical/desktop aka the main interface) - a web security auditing toolkit
• Caido-cli - The server section of caido - a web security auditing toolkit
• Detect It Easy (DiE) - File type identification
• Gemini CLI - An open-source AI agent that brings the power of Gemini directly into your terminal
• krbrelayx - Kerberos relaying and unconstrained delegation abuse toolkit
• ligolo-mp - Multiplayer pivoting solution
• llm-tools-nmap - Enables LLMs to perform network discovery and security scanning tasks using the nmap
• mcp-kali-server - MCP configuration to connect AI agent to Kali
• patchleaks - Spots the security fix and provides detailed description so you can validate - or weaponize - it fast
• vwifi-dkms - Setup “dummy” Wi-Fi networks, establishing connections, and disconnecting from them

Site : https://www.kali.org/

Note de version complète : https://www.kali.org/blog/kali-linux-2025-3-release/

Les attaques contre les NPM, GitHub et la chaîne logicielle globalement, posent de réelles questions sur l'intégrité des extensions et des codes. GitHub propose une fonctionnalité qui pourrait nous sauver, du moins, partiellement, "c’est le genre de truc que tous les développeurs devraient activer illico sur leurs repos." commente Korben. Il s'agit de l'immutable releases. La notion d'immutable, d'immutabilité, est importante en informatique. 

En gros, l'immutable est un asset technique que l'on ne peut pas changer, modifier. Il peut être en lecture seule. Un élément immutable ne change pas et on ne peut pas le corrompre. On parlera en Français d'immuable. En programmation, on parle aussi d'immutable. 

Par la fonction immutable release, théoriquement, on bloque les attaques essayant d'injecter ou de corrompre notre dépôt. Bref, cette fonction doit bloquer :

Il n'est jamais inutile de rappeler le TOP 10 LLM de l'OWASP. La version 2025 est disponible. Plusieurs changements importants apparaissent dans les failles potentielles. 

Voici un récapitulatif des vulnérabilités LLM :

LLM01 : prompt injection

Une vulnérabilité d'injection d'invites se produit lorsque les prompts des utilisateirs modifient le comportement ou le résultat du LLM de manière inattendue. Ces entrées peuvent affecter le modèle même si elles sont imperceptibles pour l'utilisateur. Par conséquent, les injections d'invites n'ont pas besoin d'être visibles/lisibles par l'utilisateur, tant que le contenu est analysé par le modèle.

Contre-mesures : contraindre l'usage du LLM, bien définir le format et les données en sortie et en entrée, renforcer les droits, validation humaine pour les demandes les plus critiques, isoler les données externes

LLM02 : données sensibles sont dévoilées / accessibles

Les informations sensibles peuvent affecter le LLM et son contexte d'application. Cela inclut les informations personnelles identifiables, les données financières, les dossiers médicaux, les données commerciales confidentielles, les informations d'identification de sécurité et les documents juridiques. Les modèles propriétaires peuvent également avoir des méthodes de formation spécifiques et un code source considéré comme sensible, en particulier dans les modèles fermés ou de fondation.

Contre-mesures : renforcer les accès aux données, sensibiliser les utilisateurs sur l'usage sécurisé des LLM

LLM03 : supply chain

Les chaînes d'approvisionnement LLM sont exposées à diverses vulnérabilités, susceptibles d'affecter l'intégrité des données d'entraînement, des modèles et des plateformes de déploiement. Ces risques peuvent entraîner des résultats biaisés, des failles de sécurité ou des pannes système. Alors que les vulnérabilités logicielles traditionnelles se concentrent sur des problèmes tels que les défauts de code et les dépendances, en ML, les risques s'étendent également aux modèles et données pré-entraînés tiers.

Contre-mesures : vérifier la source des données, utiliser des LLM validés, monitorer l'activité de la supply chain

LLM04 : données corrompues

L'empoisonnement (=corrompues volontairement) des données se produit lorsque les données de pré-entraînement, de réglage fin ou d'intégration sont manipulées pour introduire des vulnérabilités, des portes dérobées ou des biais. Cette manipulation peut compromettre la sécurité, les performances ou le comportement éthique du modèle, entraînant des résultats néfastes ou une altération des fonctionnalités. Les risques courants incluent une dégradation des performances du modèle, un contenu biaisé ou toxique et l'exploitation des systèmes en aval.

Contre-mesures : tracer la donnée (source et transformation), valider les sorties, mettre en sandbox les données externes non validées, intégrer du RAG dès l'inférence 

LLM05 : sortie incorrecte

La gestion incorrecte des sorties fait spécifiquement référence à une validation, un nettoyage et une gestion insuffisants des sorties générées par les LLM avant leur transmission vers d'autres composants et systèmes. Le contenu généré par LLM étant contrôlable par une saisie rapide, ce comportement revient à fournir aux utilisateurs un accès indirect à des fonctionnalités supplémentaires. La gestion incorrecte des sorties diffère de la surdépendance en ce qu'elle traite les sorties générées par LLM avant leur transmission en aval, tandis que la surdépendance se concentre sur des préoccupations plus larges liées à la dépendance excessive à l'exactitude et à la pertinence des sorties LLM. L'exploitation d'une vulnérabilité de gestion incorrecte des sorties peut entraîner des attaques XSS et CSRF dans les navigateurs web, ainsi que des attaques SSRF, une élévation de privilèges ou l'exécution de code à distance sur les systèmes back-end. 

Contre-mesures : approche zero trust, vérifier strictement les entrées et les sorties, ne pas autoriser des sorties non prévues, application stricte des règles et limitations, monitorer les sorties LLM

LLM06 : Excessive agency

Ce problème est une vulnérabilité affecte les actions suite à des résultats inattendus ou manipulés. Les principales causes : hallucinations, pauvre qualité du prompt, injection directe pour compromettre le comportement et les réponses. Les causes de l'excessive agency peuvent être des excès de permissions ou d'autonomie de fonctionnement, une saise non sécurité, non contrôlée

Contre-mesures : limiter l'action des agents, limiter les permissions des extensions et l'action des LLM, validation humaine pour certains prompts et des réponses sensibles. Nettoyer les demandes et les réponses

LLM07 : système de prompt défaillant

Le système prompt est là pour orienter, définir les réponses et les usages. Si ce système n'est pas bien déployé ou défini, cela peut entraîner hallucinations et mauvais usages

Contre-mesures : encadrer et limiter l'accès aux données sensibles, installer des garde-fous

LLM08 : vecteurs et vulnérabilités embarquées

Les vulnérabilités liées aux vecteurs et aux intégrations présentent des risques de sécurité importants dans les systèmes utilisantdu RAG avec des LLM. Les faiblesses dans la manière dont les vecteurs et les intégrations sont générés, stockés ou récupérés peuvent être exploitées par des actions malveillantes (intentionnelles ou non) pour injecter du contenu nuisible, manipuler les résultats des modèles ou accéder à des informations sensibles.

Contre-mesures : installer un contrôle d'accès, authentification des sources de données et validation des données, monitoring du système, classification des données selon la sensibilité

LLM09 : désinformation

L'une des principales causes de désinformation est l'hallucination : le LLM génère un contenu apparemment exact, mais fabriqué de toutes pièces. Les hallucinations surviennent lorsque les LLM comblent des lacunes dans leurs données d'entraînement à l'aide de modèles statistiques, sans en comprendre véritablement le contenu. Par conséquent, le modèle peut produire des réponses apparemment correctes, mais totalement infondées. Si les hallucinations sont une source majeure de désinformation, elles ne sont pas la seule cause ; les biais introduits par les données d'entraînement et les informations incomplètes peuvent également y contribuer.

Contre-mesures : déployer un RAG, tuning fin des modèles, vérification croisée automatique et humaine, bonnes pratiques sur l'usage et sur le code d'intégration 

LLM10 : consommation excessive / inattendue (de l'infrastructure, du service LLM ou IA)

Les attaques visant à perturber le service, à épuiser les ressources financières de la cible, voire à voler la propriété intellectuelle en clonant le comportement d'un modèle, reposent toutes sur une même classe de vulnérabilité de sécurité pour réussir. La consommation illimitée se produit lorsqu'une application LLM (Large Language Model) permet aux utilisateurs d'effectuer des inférences excessives et incontrôlées, entraînant des risques tels que le déni de service (DoS), des pertes économiques, le vol de modèles et la dégradation du service. Les exigences de calcul élevées des LLM, en particulier dans les environnements cloud, les rendent vulnérables à l'exploitation des ressources et aux utilisations non autorisées.

Contre-mesures : limitation les entrée, définir des quotas limites, gestion de timeout, réduire l'accès des LLM aux ressources réseaux ou aux API, dégradation du service en cas de forte charge, réduire le nombre de requête autorisée et réduire la file d'attente

OWASP top 10 LLM : https://genai.owasp.org/llm-top-10/

L'éditeur JFrog a annoncé plusieurs nouveautés sur les agents IA, l'IA en générale et la sécurité. 

1 / Ai Catalog : un catalogue IA pour mieux découvrir et déployer les LLM incluant les modèles NVIDIA Nemotron. Disponible dès à présent, cette nouvelle offre permet aux entreprises de créer en  des solutions agentiques spécialisées et d’intégrer des services d’IA dans leur chaîne d’approvisionnement logicielle, tout en conservant une visibilité, un contrôle et une conformité complets. 

2 / DevGovOps avec AppTrust : une nouvelle offre sur la gouvernance DevOps dans la production logicielle. AppTrust doit aider les entreprises à automatiser et à mieux gérer les exigences d’audit et de conformité sur l’ensemble de leur chaîne d’approvisionnement logicielle, réduisant ainsi les risques et renforçant la confiance dans les applications.

3 / FLY : Fly a été pensé pour offrir aux petites équipes de développement une expérience pilotée par l’IA, sans contraintes, et parfaitement intégrée à GitHub ainsi qu’aux outils d’IA natifs tels que Cursor, Claude Code et GitHub Copilot. Fly est un dépôt d'agents IA

4 / L'éditeur renforce la partie agent. « Nous voulons aider les développeurs à passer d'une sécurité réactive à une sécurité proactive, avec une gestion continue des vulnérabilités et une remédiation autonome, où la sécurité n'est plus une réflexion après coup, mais un élément intégral, un agentic de résolution de problèmes de codage », déclare Asaf Karas, CTO de JFrog Security. « Nos connaissances avancées en matière de recherche sur la sécurité, associées à notre intégration GitHub Copilot, aident les équipes à automatiser des mesures de protection essentielles telles que la correction des CVE et la sélection de paquets sécurisés. Cela permet aux utilisateurs d'innover en toute confiance, tout en réduisant les risques et en accélérant la livraison de logiciels sécurisés. ». La sécurité est un des défis majeurs des agents et de l'IA en général. Les nouvelles fonctionnalités de correction agentique de JFrog sont disponibles dès maintenant dans le cadre des offres de sécurité JFrog Ultimate ou Unified. 

Toutes les offres JFrog : https://jfrog.com/

DuckDB met en garde contre la compromission de packages NPM officiels. La campagne malveillante a été découverte en début de semaine !

4 packages malveillants ont été détectés :

• @duckdb/node-api@1.3.3
• @duckdb/node-bindings@1.3.3
• duckdb@1.3.3
• @duckdb/duckdb-wasm@1.29.2

DuckDB a rapidement déprécié la version en cause et fait supprimer les paquets en cause. Une nouvelle version des packages a été déployée avec un changement de numérotation : 1.3.4 et 1.30.0. Une des techniques utilisés est le classique phishing par mail se faisant passer pour le support NPM. Ce phishing permettait ensuite aux hackers d'envoyer le code malveillant. Les hackers ont ensuite remplacé les packages officiels par des paquets compromis intégrant des mécanismes pour faire de la cryptomonnaie. L'auteur de l'attaque est un certain Qix. 

Résultat : 360 000 téléchargements ! La question est comment des paquets ont pu être "facilement" remplacés. La sécurité 2FA ne suffit plus à garantir un minimum de sécurité. Le compte DuckDB officiel a-t-il été compromis ? Si oui, comment ? Ici, ce n'est pas une attaque Typosquatting. Bien entendu, le code malveillant était obfusqué.

L'attaque se comprend ainsi : 

- compromission d'une manière ou d'une autre du compte duckdb_admin qui maintient 12 paquets NPM

- seuls 4 paquets ont été changés avec le code malveillant

Un mainteneur officiel a confirmé la technique du phishing en suivant les liens du (faux) mail. "L'un des responsables a lu ce texte et l'a trouvé plutôt raisonnable. Il a suivi le lien (aujourd'hui disparu) vers un site web hébergé sous le domaine npmjs.help. Ce site web contenait une copie parfaite du site npmjs.com. Il s'est connecté avec l'utilisateur et le mot de passe duckdb_admin, suivis de l'authentification à deux facteurs. Là encore, le profil utilisateur, les paramètres, etc. étaient une copie parfaite du site npmjs.com, y compris toutes les données utilisateur. Comme demandé dans l'e-mail, il a ensuite réinitialisé la configuration de l'authentification à deux facteurs." a commenté DuckDB.

Les contre-mesures possibles :

- n'installer pas les paquets compromis

- installer uniquement les versions saines et clairement identifiées

- auditer les installations récentes et le trafic réseau

Qix ne s'est pas arrêté à DuckDB :

Réaction officielle : https://github.com/duckdb/duckdb-node/security/advisories/GHSA-w62p-hx95-gf2c

Plex subit une nouvelle faille de sécurité avec une fuite de donnée. La plateforme préconise de changer en urgence votre mot de passe sur vos comptes. Cela fait suite à la découverte d'une nouvelle faille exposant les données personnelles. Une attaquant peut accéder aux mails, nom du compte, au mot de passe et toutes les données d'authentification. 

" Un tiers non autorisé a accédé à un sous-ensemble limité de données clients provenant de l'une de nos bases de données. Bien que nous ayons rapidement maîtrisé l'incident, les informations consultées comprenaient des adresses e-mail, des noms d'utilisateur, des mots de passe chiffrés de manière sécurisée et des données d'authentification. Tous les mots de passe de compte éventuellement consultés ont été chiffrés de manière sécurisée, conformément aux bonnes pratiques, ce qui signifie qu'ils ne peuvent être lus par un tiers. Par mesure de précaution, nous vous recommandons de prendre des mesures supplémentaires pour sécuriser votre compte. Soyez assuré que nous ne stockons pas de données de carte bancaire sur nos serveurs ; ces informations n'ont donc pas été compromises lors de cet incident." explique PLEX. 

Le service préconise de faire un reset du mot de passe si vous faites une authentification directe. 

Sitecore prévient qu'une vulnérabilité potentiellement critique touche plusieur services de l'hébergeur. Elle est connue sous le numéro CVE-2025-53690. Il s'agit d'une attaque par désérialisation ViewState suite à une mauvaise configuration d'une clé machine ASP.Net d'exemple publiée dans la documentation. Cette faille permet d'installer le logiciel espion WEEPSTEEL qui donne accès aux données et aux repertoires. Les données contenues par le ViewState sont protégées par une clé machine. Et ici, la clé étant connue, il est facile de faire une attaque. Sitecore précise que les services concernés sont Experience Manager, Experience Platform, Managed Cloud. 

L'hébergeur préconise plusieurs actions :

- surveiller les instances et les services pour observer une activité anormale

- changer la clé machine utilisée dans le fichier web.config

- vérifier que les éléments <machineKey> soient chiffrés dans les fichiers web.config

- limiter l'accès au web.config uniquement aux administrateurs

Explication en profondeur de l'attaque : https://cloud.google.com/blog/topics/threat-intelligence/viewstate-deserialization-zero-day-vulnerability?hl=en

La réaction de Sitecore : https://support.sitecore.com/kb?id=kb_article_view&sysparm_article=KB1003865

JetBrains avait annoncé début 2025 un partenariat avec Mend.io pour améliorer la sécurité dans les codes sur les différents IDE de l'éditeur et Qodana. Mend.io édite une plateforme de sécurité orientée AppSec. Les équipes ont travaillé à intégrer API Vulnerable et des fonctions d'analyse de code des librairies open source. Ces fonctions sont intégrées dans le plugin Package Checker de Mend.io. 

Ce plugin couvre Java, Kotlin, C#, JavaScript, TypeScript, Python. Pour l'activer, il faut aller dans seetins -> editor -> inspections. Il suffit de sélectionner l'inspection souhaitée. Ce faisant, vous pourrez utiliser directement l'analyse AppSec dans vos codes. Package Checker permet également de consulter la liste des vulnérabilités dans une fenêtre dédiée de l'IDE. Il suffit d'utiliser le lien « Afficher tout… ». Cela vous mènera à la fenêtre « Dépendances vulnérables », qui affiche l'état général du projet et fournit des informations sur chaque dépendance vulnérable détectée.

Annonce : https://blog.jetbrains.com/idea/2025/09/enhanced-vulnerable-api-detection-in-jetbrains-ides-and-qodana/

C'est l'Everest de nombreux éditeurs de sécurité avec l'IA, les agents IA et tout ce qui Vibe Coding. La sécurité des codes générés par l'IA est loin d'être acquise. Pis, certains outils dérivent au fur et à mesure des itérations IA. « Les assistants IA comme Copilot ou Cursor permettent à un développeur de produire autant de code que trois à cinq développeurs traditionnels. Mais pendant que la productivité explose, les équipes sécurité restent à taille constante. Résultat : 76 % du code généré par IA nécessite une refonte pour des raisons de sécurité. On ne peut pas faire du vibe coding et accélérer le développement sans repenser en profondeur la sécurisation du code. » explique Fabien Petiau, Country Manager de Checkmarx. « Avec les agents IA, la surface d’attaque dépasse largement le code source : elle englobe désormais toutes les actions invisibles menées par ces agents tout au long du cycle de développement. Exposition de données, actions non autorisées, shadow code, dépendances hallucinées… Le Vibe Coding impose une nouvelle cartographie des risques, difficile à surveiller et encore plus complexe à maîtriser. »

Il faut donc faire du secure by design dès la génération et corriger les problèmes tout de suite. Chechmarx propose pour cela 3 agents dédiés : 

• Developer Assist Agent (Agent pour développeurs) disponible dès aujourd’hui : intégré aux principaux IDE IA comme Windsurf, Cursor ou encore GitHub Copilot, il fournit aux développeurs une détection, une correction et des recommandations contextuelles en temps réel, directement dans leur environnement de développement. Cette solution permet d’identifier et de sécuriser le code généré par l’IA dès sa création, accélérant le développement sans compromettre la sécurité. Les premiers retours clients, issus des secteurs de la santé, des services financiers et des produits grand public, montrent une détection plus rapide et des remédiations plus efficaces.
• Policy Assist Agent (Agent de gouvernance) : orchestre l'application des politiques de sécurité dans les pipelines CI/CD, priorise les failles exploitables, automatise les flux de remédiation et fournit une vue complète de la dette de sécurité.
• Insights Assist Agent (Agent analytique exécutif) : offre une vision stratégique avec un suivi en temps réel de la posture de risque sur l’ensemble du portfolio logiciel, l’alignement sur les métriques DORA et MTTR, l’automatisation de la conformité et un reporting clair à destination des comités de direction.

Derrière, l'éditeur entraîne les modèles chaque mois et intègre les vulnérabilités détecturées et référencées. 

JFrog a mis en évidence 8 paquets open source malveillants s'attaquer aux données via la version Windows de Chrome. Ces paquets, notamment react-sxt (version 2.4.1), react-typex (version 0.1.0), et react-native-control (version 2.4.1), ont été téléchargés par des utilisateurs malveillants de npm. Ils contenaient un obscurcissement multicouche très sophistiqué, avec plus de 70 couches de code dissimulé, permettant aux attaquants d'exécuter des charges utiles malveillantes sur les machines des développeurs sans interaction avec l’utilisateur.

Ils peuvent :

• Vol de données : extraire les données sensibles de tous les profils utilisateur, y compris les mots de passe, les informations de carte de crédit, les cookies et les portefeuilles de cryptomonnaie, depuis le navigateur Chrome.
• Techniques d'évasion : utiliser le contournement des clichés instantanés, l'usurpation d'identité LSASS, plusieurs méthodes d'accès aux bases de données et le contournement du verrouillage des fichiers pour éviter la détection.
• Exfiltration de données : télécharger les données volées vers des serveurs contrôlés par les pirates, y compris l'infrastructure hébergée par Railway.

« Les référentiels de logiciels open source sont devenus l'un des principaux points d'entrée des pirates dans le cadre des attaques de la chaîne d'approvisionnement, avec des vagues croissantes utilisant le typosquatting et le masquage, en se faisant passer pour légitimes. » a déclaré Guy Korolevski, chercheur en sécurité chez JFrog. « L'impact des campagnes sophistiquées à plusieurs niveaux conçues pour contourner la sécurité traditionnelle et voler des données sensibles souligne l'importance d'avoir une visibilité sur l'ensemble de la chaîne d'approvisionnement logicielle grâce à un scan automatisé rigoureux et à une source unique de vérité pour tous les composants logiciels. »

NPM a été prévenu. Les paquets ont été supprimés. Les utlisateurs les ayant téléchargés doivent impérativement changer les identifiants. Pour l'équipe JFROG, ces paquets montrent une complexité dans le code et les méthodes d'attaques. Les paquets possèdent une obfuscation multiple et des techniques d'évasion avancées. 

Annonce complète de l'attaque : https://jfrog.com/blog/malicious-npm-packages-chrome-browser-information-stealer/?utm_source=press&utm_medium=mediaalert&utm_campaign=npmpackage&utm_content=ma

Synacktiv propose un framework orienté pentest : MOFOS. Il permet de créer rapidement des VM sur Libvirt, QEMU, KVM, avec Python. C'est un équivalent à Qubes OS. Mofos est axé sur la gestion sécurisée des machines virtuelles, notamment avec les fonctions suivantes :

La vulnérabilité CVE-2025-8088, avec un score de 8,8, est en cours sur WinRAR. Cette faille est dite "path traversal" et impacte les versions Windows de WinRAR et UnRAR. L'archive contient le code malveillant que peut lors de la décompression s'installer sur l'OS cible et s'activait ! Il ouvre alors un accès de type porte dérobée sur votre Windows. Les codes sourcs UnRAR et la dll sont touchés. Une faille identique avait été reperée et fixée en juin dernier (CVE-2025-6218). Des groupes de hackers russes seront impliqués dans les deux failles. 

Les versions 7.12 et plus anciennes sont concernées par cette CVE. Mettez à jour sans délai.