Dans une nouvelle analyse consacrée à l’évolution des opérations du groupe APT36 (également connu sous le nom de Transparent Tribe), Bitdefender documente l’émergence d’un modèle de développement de malwares assisté par l’IA que ses chercheurs qualifient de « vibeware ».

L’intelligence artificielle n’a pas encore produit le cyberattaquant omniscient que certains redoutaient. Ce qu’elle produit, en revanche, est peut-être plus insidieux : une chaîne de production automatisée de logiciels malveillants médiocres, jetables, et suffisamment nombreux pour saturer les défenses.

Un nouveau modèle industriel de la menace

Le vibeware désigne une approche du développement de malwares pilotée par l’IA qui privilégie la quantité sur la qualité. L’idée n’est pas de concevoir une cyberattaque brillante, mais d’en produire des dizaines, chaque jour, de manière automatisée.

Des groupes comme APT36, groupe de cybercriminels pakistanais bien documenté, seraient désormais capables de maintenir une cadence d’un nouveau variant de malware par jour. Ce rythme industriel permet de « saturer » la télémétrie défensive standard. Chaque nouveau binaire nécessite une analyse, chaque nouvelle signature doit être établie. Les équipes de sécurité se retrouvent à courir après un flot continu de menaces mineures, au risque de manquer l’essentiel.

Les chercheurs ont qualifié cette stratégie de DDoD pour Distributed Denial of Detection, ou déni de détection distribué. Par analogie avec les attaques DDoS classiques qui submergent un serveur par le volume de requêtes, le DDoD submerge les capacités d’analyse et de détection des équipes cyber avec un flux constant de codes renouvelés. L’objectif n’est pas de surpasser les défenses par le génie technique, mais d’épuiser les défenseurs.

Des langages exotiques pour réinitialiser les détections

L’un des leviers techniques les plus efficaces du vibeware réside dans le recours à des langages de programmation inhabituels. Les moteurs de détection sont, pour la plupart, optimisés pour analyser du code écrit en C++, C# ou .NET. Les attaquants l’ont bien compris.

Grâce aux LLM, il est désormais possible de porter la logique d’un malware existant vers un langage de niche sans disposer d’une expertise préalable. Les langages favorisés par APT36 incluent notamment :

• Nim : représentant moins de 0,1 % de l’indice TIOBE, ce langage compile en C ou C++ mais utilise un moteur d’exécution unique. Les scanners de sécurité le classent souvent comme « inconnu » plutôt que « malveillant ». Il est utilisé comme enveloppe (wrapper) furtive pour masquer des charges utiles plus anciennes.
• Zig : utilisé pour des outils comme ZigShell ou ZigLoader, ce langage offre des performances élevées tout en échappant aux signatures comportementales des solutions EDR.
• Crystal : également trop rare pour disposer de signatures établies dans de nombreux outils de détection de terminaux.

À ces langages de niche s’ajoutent Rust et Go, plus connus mais appréciés pour leur stabilité mémoire lors de tâches intensives comme l’exfiltration massive de données.

L’effet stratégique est double : réinitialisation de la détection ( chaque nouveau langage oblige les outils de sécurité à repartir de zéro) et accessibilité simplifiée par l’IA, qui permet à des attaquants sans expertise spécifique de générer du code fonctionnel dans ces langages.

Living Off Trusted Services : se cacher dans le trafic légitime

Le vibeware excelle également dans l’exploitation des services cloud légitimes pour ses canaux de commande et de contrôle. Cette technique, désignée sous le terme de Living Off Trusted Services (LOTS), consiste à utiliser des plateformes comme Google Sheets, Discord, Slack ou Supabase comme infrastructure C2.

L’exemple le plus documenté est SheetCreep, un malware écrit en C# qui transforme une feuille de calcul Google Drive en véritable tableau de bord d’administration. Son fonctionnement est précis :

• Le malware interroge régulièrement une feuille de calcul spécifique pour y récupérer des instructions.
• Les commandes sont encodées en Base64 puis chiffrées via un algorithme DES (mode ECB).
• Les résultats d’exécution sont renvoyés dans les cellules du tableur via l’API Google Drive.
• L’infrastructure est organisée en onglets dédiés : unenc_requests, unenc_outputs, unenc_heartbeats, unenc_systems.

D’autres outils de la flotte APT36 s’appuient sur Discord (CrystalShell), Slack (ZigShell), Firebase et Supabase pour la gestion des sessions et le stockage des données volées, ou encore sur Microsoft Graph API via l’infostealer MailCreep.
Azure Front Door est également utilisé pour masquer les communications malveillantes dans du trafic HTTPS légitime.

L’IA joue ici un rôle d’accélérateur décisif : ces plateformes disposent de documentations publiques abondantes et de SDK bien référencés dans les données d’entraînement des LLM. Générer du code d’intégration stable pour Google Sheets ou Discord est devenu trivial, même pour un attaquant sans compétence technique approfondie.

Les limites du vibeware

Il serait inexact de présenter le vibeware comme une rupture technologique car le code généré par l’IA est souvent dérivé, incohérent, et sujet à des erreurs logiques critiques.

Plusieurs cas documentés illustrent ces failles :

• Des binaires déployés avec l’URL du serveur C2 laissée en « placeholder » (modèle vide), rendant l’exfiltration de données impossible.
• Des composants qui s’effondrent dès que la logique atteint un niveau de complexité modéré.
• Dans le cas de CrystalShell, l’absence de protocole de communication entre les bots aurait généré des « broadcast storms » inutiles, et la commande de statut réinitialisait la métrique qu’elle était censée mesurer.
• Des outils incapables de supprimer leurs propres fichiers temporaires après exécution, facilitant l’analyse forensique post-attaque.

Cette fragilité structurelle explique pourquoi les groupes comme APT36 continuent d’utiliser des frameworks classiques et éprouvés (Cobalt Strike ou Havoc) comme filet de sécurité. Les outils « vibe-coded » ne sont pas encore assez fiables pour porter seuls la responsabilité d’une opération critique.

Par nature, les LLM sont entraînés sur des dépôts publics comme GitHub : ils réorganisent des patterns existants sans inventer de nouvelles méthodologies d’attaque. Ils manquent de véritable compréhension du contexte de sécurité.

Comment se défendre : passer du statique au comportemental

Face au vibeware, une défense basée sur les signatures est structurellement inadaptée. Les recommandations convergent vers une approche dynamique et comportementale.

> Prioriser l’analyse comportementale. L’injection de processus ou le process hollowing restent des constantes, quel que soit le langage utilisé. Les solutions EDR/XDR doivent surveiller ces comportements plutôt que les signatures de binaires. La surveillance des répertoires d’écriture utilisateur (%APPDATA%, %TEMP%) et le scan régulier de la mémoire complètent ce dispositif.

> Auditer les services cloud. Les connexions persistantes vers Discord, Slack ou Google Sheets provenant de binaires non vérifiés doivent être traitées comme des indicateurs de compromission potentiels. Un monitoring strict de ces plateformes s’impose dans les environnements sensibles.

> Compliquer la phase post-intrusion. Les opérations de piratage proprement dites restent manuelles. Réduire la surface d’attaque pour introduire de la friction lors du mouvement latéral, filtrer rigoureusement les fichiers LNK, ZIP ou ISO reçus par email, et maintenir les navigateurs à jour pour bénéficier de mécanismes comme l’App-Bound Encryption (ABE) sont autant de mesures qui forcent l’attaquant à utiliser des méthodes plus lourdes et donc plus détectables.

> S’appuyer sur des SOC ou MDR matures. Compte tenu de la cadence de production des variants (parfois un par jour), seule une surveillance 24/7 permet de distinguer le « bruit » généré par le vibeware des véritables intrusions critiques.

Le vibeware n’est pas l’avènement du cyberattaquant surhumain. C’est l’industrialisation du cyber-médiocre. Et c’est précisément pour cette raison qu’il mérite une attention soutenue.

*Image : © DR
*L’analyse des chercheurs de Bitdefender a révélé la présence récurrente du pseudonyme  « Nightmare  » sur plusieurs systèmes. Ce personnage semble jouer un rôle central dans le développement des malwares assistéw par l’IA

The post Vibeware : quand l’IA industrialise la cybercriminalité médiocre appeared first on Silicon.fr.

On entend beaucoup parler de l'IA générative ces derniers temps. Et dans les médias classiques, c'est souvent pour s'en inquiéter (pas ici, vous savez que j'essaye de rester positif). Il faut quand même reconnaitre que : phishing plus convaincant, deepfakes, malware qui s'adapte tout seul... la liste des risques est longue et légitime.

Mais il y a un angle qu'on oublie parfois : cette même technologie peut aussi renforcer sérieusement nos défenses. C'est exactement la position que défend Surfshark depuis quelques mois. Pas en mode "l'IA va tout résoudre", mais avec une approche pragmatique. À savoir comment utiliser ces outils pour anticiper, tester et contrer les menaces avant qu'elles n'arrivent jusqu'à vous. Je vous explique comment ça fonctionne, ce que ça change concrètement, et pourquoi c'est une bonne nouvelle pour votre sécurité au quotidien.

L'IA générative n'est pas juste un outil d'attaque

Quand on parle de cybersécurité et d'IA, le premier réflexe est de penser aux cybercriminels. C'est vrai, ils l'utilisent. Pour écrire du code malveillant plus vite, personnaliser des campagnes de phishing, ou générer des variantes de malware qui contournent les signatures classiques. Mais les équipes de défense ont accès aux mêmes capacités. La différence ? L'intention et le cadre d'utilisation.

La "generative AI", dans ce contexte, c'est la capacité à produire du contenu nouveau à partir de modèles entraînés. Cela peut être du texte, du code ou encore des scénarios d'attaque simulés. Ce n'est pas de la magie. C'est de l'ingénierie appliquée à la sécurité. Concrètement, ça permet trois choses essentielles :

D'abord, la détection proactive. Au lieu d'attendre qu'une menace soit identifiée pour la bloquer, les modèles peuvent simuler des milliers de variantes d'attaques plausibles, puis entraîner les systèmes de détection à les reconnaître. C'est comme faire des exercices d'incendie avant que le feu ne se déclare.

Ensuite, l'analyse comportementale. L'IA peut modéliser ce à quoi un trafic réseau "normal" ressemble pour votre infrastructure, puis signaler les écarts subtils qui échapperaient à des règles statiques. Pas besoin que l'attaque corresponde à une signature connue, si le comportement est suspect, le système alerte.

Enfin, l'automatisation des réponses. Quand un incident est détecté, chaque minute compte. L'IA peut résumer les alertes, suggérer des actions de confinement, isoler un compte compromis, générer un rapport pour l'équipe, etc. Les analystes gardent la main sur les décisions stratégiques, mais ne perdent plus de temps sur des tâches répétitives.

Comment Surfshark met ça en pratique

Surfshark n'utilise pas l'IA générative pour faire du marketing ou ajouter des fonctionnalités gadget. L'approche est plus terre-à-terre.

Leur équipe sécurité s'appuie sur ces modèles pour tester en continu leurs propres défenses. Ils génèrent des scénarios d'attaque réalistes, adaptés à leur infrastructure, puis vérifient que leurs systèmes réagissent comme prévu. C'est une forme de "pen-testing" augmenté, plus rapide et plus exhaustif que les méthodes manuelles.

Un autre usage concret c'est l'entraînement des équipes. Plutôt que de se baser uniquement sur des incidents passés, ils peuvent créer des simulations dynamiques, avec des variantes imprévisibles. Ça permet de préparer les analystes à des situations qu'ils n'ont jamais rencontrées, sans attendre qu'elles arrivent pour de vrai.

Côté produit, certaines fonctionnalités bénéficient indirectement de ces avancées. CleanWeb , par exemple, qui bloque pubs et trackers, s'appuie sur des modèles capables d'identifier des schémas de collecte de données de plus en plus sophistiqués. L'IA ne remplace pas les listes de blocage, mais elle aide à les mettre à jour plus vite, face à des acteurs qui adaptent leurs techniques en permanence.

Et pour ceux qui s'inquiètent de la confidentialité, Surfshark précise que les données utilisées pour entraîner ces modèles sont soit synthétiques, soit anonymisées. Rien de ce que vous faites via leur VPN ne sert à nourrir des modèles externes. La politique no-logs, auditée par Deloitte ou très récemment SecuRing (audit en janvier 2026), reste la règle.

Utiliser l'IA en sécurité sans se mettre en danger

Si vous êtes tenté d'expérimenter avec des outils d'IA générative dans votre propre environnement, quelques précautions s'imposent. Déjà, ne partagez jamais d'informations sensibles avec des plateformes publiques comme ChatGPT, Claude, etc. Même si l'outil semble inoffensif, vos requêtes peuvent être conservées, analysées, ou fuiter en cas de brèche. Pour du travail sur des configurations, des logs ou des politiques de sécurité, privilégiez des environnements contrôlés, en local ou avec des fournisseurs qui garantissent la confidentialité des données.

Formez vos équipes. L'IA peut générer du code, du texte, des scénarios très convaincants ... mais elle peut aussi se tromper, introduire des biais, ou proposer des solutions qui semblent logiques alors qu'elles créent des failles. Un œil humain reste indispensable pour valider, contextualiser et décider.

Enfin, gardez une approche critique. L'IA n'est pas une solution miracle. Elle amplifie les capacités humaines, mais ne les remplace pas encore. Une bonne hygiène de sécurité (mises à jour, authentification forte, segmentation réseau) reste la base. L'IA vient en couche supplémentaire, pas en fondation.

Vous le savez maintenant, je ne suis pas de ceux qui voient l'IA comme une menace absolue, ni comme une panacée. C'est juste un outil. Comme un marteau : ça dépend de la main qui le tient.

Ce qui me convainc dans l'approche de Surfshark depuis plusieurs années, c'est le pragmatisme. Pas de promesses grandioses, pas de discours "disruptif". Juste une volonté d'utiliser ce qui fonctionne pour améliorer la protection, tout en restant transparent sur les limites et les risques. Si vous cherchez un VPN qui intègre une réflexion sérieuse sur l'avenir de la cybersécurité, sans sacrifier la simplicité ni la confidentialité, Surfshark coche les cases. L'IA générative n'est pas l'argument principal de leur offre, cela dit c'est un atout discret qui renforce la crédibilité technique de l'ensemble.

L'offre du moment

Surfshark propose toujours son offre à 87% de réduction plus trois mois offerts sur l'engagement 24 mois. Cela revient à 1,99 euro HT par mois (2.39€/mois TTC), avec une garantie satisfait ou remboursé de trente jours. Vous pouvez tester le service, vérifier par vous-même les performances, la facilité d'usage, la réactivité du support et vous avez en plus l' Alternative ID inclus. Si ça ne correspond pas à vos attentes, vous êtes remboursé, sans justification. C'est le prix d'un sandwich triangle par mois pour protéger un nombre illimité d'appareils !

En plus, du 25 février au 23 mars (et dans la limite du stock disponible), Surfshark frappe fort encore plus fort avec une offre exclusive en partenariat avec CALM, l’application de méditation et de sommeil la plus téléchargée au monde. En choisissant un abonnement Surfshark de 1 ou 2 ans, vous obtenez automatiquement 12 mois de CALM Premium offerts, quelle que soit la formule choisie. Elle est pas belle la vie ?

Profitez de l'offre à prix cassé !

Note : il s'agit d'un lien affilié. Cela ne change rien pour vous, mais cela me permet de continuer à produire ce type de contenu indépendant, sans recourir à la publicité intrusive.

J'avoue que faire tourner un agent IA en mode YOLO sur votre machine, y'a de quoi flipper un peu. Un mauvais prompt et hop, votre répertoire home part en fumée.

Mais heureusement, pour ça y'a Yolobox , un outil en Go qui fait tourner vos agents IA dans un conteneur Docker isolé. En gros, l'agent a les pleins pouvoirs dans son bac à sable par défaut comme ça, votre répertoire home reste intouchable. Claude Code, Codex, Gemini CLI, GitHub Copilot, tout est compatible, préconfiguré et prêt à l'emploi.

En fait avec Yolobox, seul votre dossier projet est monté en lecture-écriture avec le même chemin que sur votre machine et comme ça, l'agent bosse comme si de rien n'était. Sauf que tout le reste (vos clés SSH, vos credentials, vos photos de vacances à la plage naturiste et j'en passe...) est inaccessible depuis le conteneur. L'agent peut faire sudo, installer ce qu'il veut, déglinguer sa config... en fait RIEN ne s'échappe.

L'installation tient en une ligne :

brew install finbarr/tap/yolobox

Par contre, faut Docker Desktop qui tourne derrière, car sans ça, rien ne démarre. Ensuite c'est yolobox claude pour lancer Claude Code, yolobox codex pour Codex, yolobox gemini pour le CLI Google. Ou yolobox run suivi de n'importe quelle commande si vous avez un agent custom...

Côté sécu, y'a 4 niveaux qui vont du basique au parano. Le mode par défaut avec isolation conteneur standard. Un cran au-dessus avec --no-network et --readonly-project pour couper le réseau et passer le projet en lecture seule. Ensuite du Podman rootless. Et le niveau max avec isolation VM complète, parce que des fois faut pas déconner. Ça supporte aussi le runtime Apple Container pour ceux qui veulent rester full macOS.

Et les outils de dev sont déjà embarqués dans l'image : Node.js 22, Python 3, Go, Bun, ripgrep, fzf, jq... Les volumes persistants gardent également vos installations entre les sessions, donc pas besoin de tout réinstaller à chaque lancement.

Attention quand même, ça ne marche pas contre un escape de conteneur délibéré car hé, Docker reste Docker. Mais si vous utilisez Claude Code en mode autonome et que vous faites du vibe coding, c'est le minimum vital pour éviter qu'un agent aille fouiller là où il faut pas .

Bref, allez voir ça et merci à Lorenper pour le partage !

BYOD, IA, réseaux sociaux professionnels, logiciels à usage industriel… Les derniers « flashs ingérence » de la DGSI ont souvent fait la part belle au numérique.

Le service de renseignement avait institué ce format en 2012. Il y présente brièvement des cas réels d’ingérence économique et y associe des préconisations. Le dernier en date (février 2026) évoque les risques de captation d’informations lors de déplacements à l’étranger.

Deepfakes, shadow AI… et due diligence sans vigilance

Le « flash ingérence » précédent (décembre 2025) est consacré à l’usage de l’IA dans le monde professionnel.

L’un des cas présentés est une tentative d’escroquerie par deepfake. Elle a visé le responsable d’un site industriel d’un groupe français. L’intéressé a reçu un appel visio. Son interlocuteur avait l’apparence physique et la voix du dirigeant du groupe. Il n’a cependant pas accédé à la demande qui lui a été faite de transférer des fonds dans le cadre d’un prétendu projet d’acquisition.

Les deux autres cas présentés touchent respectivement à l’usage d’IA sans autorisation et sans vérification. Le premier implique la traduction régulière de documents confidentiels à l’aide d’un outil « grand public » développé par une société étrangère, sans aval de la hiérarchie. Le second concerne le recours à un autre outil d’origine étrangère, pour de la due diligence. La société utilisatrice a systématiquement orienté ses décisions en fonction du retour fait par l’outil, sans contrôle complémentaire.

Des approches indésirables sur les réseaux sociaux professionnels

Le « flash ingérence » précédent (novembre 2025) est dédié aux approches malveillantes sur les réseaux sociaux professionnels.

La DGSI y expose le cas d’une start-up en difficulté financière évoluant dans un secteur sensible. Son dirigeant est approché par un prétendu cabinet de conseil étranger qui déclare opérer en qualité d’intermédiaire pour un fonds d’investissement. Convaincu, il lui dévoile des informations, dont un projet de conception d’un nouveau produit. Le service juridique de la start-up finit toutefois par détecter la supercherie. Ni le cabinet ni le fonds n’avait d’existence légale. Et on n’en trouvait trace dans aucune base de données de leurs pays d’origine déclarés.

Autre fausse promesse de financement : celle qui a ciblé le responsable d’un centre de recherche. Elle provenait du soi-disant chargé de com d’une célébrité internationale. Elle était d’autant plus crédible que cette célébrité avait récemment effectué des actions de soutien dans le domaine d’activité du centre – actions largement relayées sur les réseaux sociaux. La discussion n’est pas allée plus loin lorsque l’individu a demandé le règlement préalable d’une taxe locale de plusieurs milliers d’euros.

Le troisième cas exposé est celui de salariés piégés par un faux profil. L’escroc s’est d’abord fait passer pour un comptable interne, sans succès (le dirigeant avait repéré la supercherie). Il a eu plus de réussite quelques mois plus tard. Avec un autre faux profil, il est parvenu à engager des discussions avec des salariés. Dont un qui lui a révélé des infos stratégiques relatives au calendrier de développement de certaines activités de l’entreprise et à l’état de ses progrès technologiques.

Les points faibles des logiciels industriels

En octobre, il y avait eu un « flash ingérence » concernant les risques associés à l’absence de protection des logiciels à usage industriel.

La DGSI y présente le cas d’une entreprise française développant des systèmes industriels. Un de ses clients avait, avec l’aide d’une entreprise concurrente étrangère, détourné le programme embarqué et l’avait installé sur une machine tierce. Or, ni le programme ni la machine ne bénéficiaient d’une protection par brevet. L’entreprise française avait considéré qu’en déposer un aurait publiquement exposé ses inventions. Le client a justifié la démarche par des temps de livraison jugés trop longs.

Deuxième cas : celui d’une entreprise française commercialisant un logiciel à intégrer dans des machines-outils. Un client étranger, prétextant un défaut de mise à jour, a fait une sauvegarde totale des données et du programme. Ce sans respecter les procédures de l’entreprise française, qui, habituellement, se déplace pour faire elle-même la mise à jour.
En l’absence de possibilité de protection par brevet des logiciels en tant que tels, l’entreprise craint notamment une revente à un concurrent.

La DGSI mentionne aussi un cas d’exfiltration de code source non protégé, survenu dans une entreprise ayant développé un logiciel applicatif pour un secteur industriel de pointe. Deux anciens salariés, qui avaient eu accès à ce code source développé dans le cadre de leurs fonctions, avaient créé une société concurrente pour l’exploiter. Ce quand bien même leurs contrats de travail comprenaient des clauses de confidentialité et de non-concurrence.

Entre phishing et keyloggers, la DGSI n’oublie pas le « facteur humain »

Un peu plus tôt dans l’année était paru un « flash ingérence » intitulé « Le facteur humain, principal vecteur de compromission des systèmes d’information ».

Le premier cas présenté est celui d’un salarié d’une société hébergeant des données sensibles. L’intéressé a accédé à sa messagerie professionnelle à partir d’outils personnels, alors même que la charte informatique de son employeur l’interdisait. Cela a permis à des attaquants de pénétrer le SI puis d’exploiter une faille 0-day.

Autre entreprise, autre salarié, quant à lui approché sur un réseau social professionnel par un soi-disant chargé de recrutement dans un grand groupe étranger. Invité à ouvrir une pièce jointe dans un de ses e-mails, il a ouvert la porte à un virus qui a permis d’extraire des centaines de fichiers sensibles. Ainsi que des fichiers appartenant à son ancien employeur.

La DGSI y ajoute une action malveillante d’un salarié travaillant chez un prestataire d’un grand groupe industriel. Il a installé un keylogger sur une clé USB personnelle. Puis l’a mise à disposition de ses collègues en tant que support de stockage professionnel. Cela lui a permis de récupérer les identifiants des personnes qui l’avaient connectée à leur ordinateur.

Le BYOD, consultants compris

En mars 2025, la DGSI avait publié un « flash ingérence » sur les risques associés à l’utilisation d’outils numériques personnels à des fins professionnelles.

Premier cas évoqué : un salarié ayant utilisé à de multiples reprises son ordinateur personnel pour se connecter à la plate-forme commerciale de son entreprise. Sans dispositif d’anonymisation ni chiffrement des échanges. Un membre de sa famille utilisait régulièrement cet ordinateur. Qui, pendant une courte période, a eu un fonctionnement inhabituel, non expliqué. Plusieurs mois après, le RSSI de la société a constaté que l’identifiant et le mot de passe du salarié étaient sur le darkweb. Faute d’authentification forte sur la plate-forme commerciale, des tiers ont accédé à la base de données clients.

Autre cas : celui d’un consultant d’un prestataire informatique d’une société sensible. À son domicile, il s’est fait voler son ordinateur personnel. Il y avait transféré des données de la société depuis son poste de travail pro. Elles étaient stockées sans protection particulière et l’ordinateur n’était sécurisé que par un mot de passe. Le presta n’avait pas avisé la société de ce transfert de fichiers.

La DGSI mentionne aussi une entreprise qui encourageait le BYOD sans l’avoir encadré clairement. Et sans posséder de systèmes de gestion des appareils mobiles à distance. Elle n’a pas pu déterminer ce qui est arrivé au téléphone d’un salarié lors d’un contrôle aéroportuaire. Les autorités étrangères l’ont saisi, ont obtenu son déverrouillage et l’ont emporté dans une autre pièce…

Illustration générée par IA

The post Numérique en entreprise : les mises en garde de la DGSI appeared first on Silicon.fr.

82 314 dollars, c'est l'incroyable facture que s'est mangé un dev mexicain après 48 heures d'utilisation frauduleuse de sa clé API Gemini. Sa dépense habituelle était de 180 dollars par mois environ, j'imagine que ça lui a fait un peu mal aux fesses. Et c'est une bonne raison pour moi de vous inciter une nouvelle fois à bien sécuriser vos clés API !

Le gars bosse dans une petite startup et de ce que j'ai compris, quelqu'un a chopé ses credentials et s'est lâché sur Gemini 3 Pro pendant deux jours. La réponse de Google ? "Responsabilité partagée". En gros, eux sécurisent l'infra, et vous sécurisez vos clés. Si vous vous faites plumer, c'est votre problème !

Et c'est pas un cas isolé car les chercheurs de Truffle Security ont scanné le web et trouvé 2 863 clés Google API exposées en clair sur des sites publics. Toutes identifiables par le préfixe AIza.

Sauf que comme je vous l'expliquais dans un article précédent, ces clés, à la base, étaient conçues comme de simples identifiants de projet pour Maps et Firebase et la doc Google disait carrément qu'elles n'étaient pas secrètes ! Et quand l'API Gemini a été activée sur ces projets, hé bien ces clés sont devenues des clés d'authentification, sans que personne ne réalise ce changement de paradigme.

Mais bon, plutôt que de chialer comme des fragiles, voyons comment éviter de se retrouver dans cette situation ^^.

Scanner vos secrets existants

Avant tout, faut savoir si vous avez déjà des fuites. Deux outils open source font ça très bien.

TruffleHog scanne vos dépôts Git, vos fichiers, et même vos buckets S3 pour trouver des secrets qui traînent. L'install est simple :

brew install trufflehog
trufflehog git https://github.com/user/project --only-verified

grep -r "AIza" . --include="*.js" --include="*.py" --include="*.env"

brew install git-secrets
cd mon-projet
git secrets --install
git secrets --register-aws

git secrets --add 'AIza[0-9A-Za-z_-]{35}'
git secrets --add 'sk-proj-[0-9a-zA-Z]{48}'

gcloud services api-keys list
gcloud services api-keys create --display-name="gemini-prod-$(date +%Y%m)"
gcloud services api-keys delete ANCIENNE_CLE_ID

Cohesity renforce son dispositif français. L’éditeur américain, qui se positionne comme leader de la sécurisation des données par l’IA, annonce  la nomination de Mathias Michiels au poste de Country Manager France. Basé à Paris, il prend la tête des équipes commerciales locales avec pour ambition d’accélérer la croissance de Cohesity sur ce marché qu’elle considère comme stratégique.

Un parcours forgé dans les grandes ligues du logiciel

Mathias Michiels arrive avec plus de 15 ans d’expérience dans l’industrie du logiciel. Il a débuté dans la gestion de comptes chez Oracle et SAS Institute, avant de consacrer plus d’une décennie à VMware. Là, il a gravi les échelons jusqu’au poste de Senior Sales Director pour les solutions Tanzu sur la région SEMEA, à la tête d’une équipe transverse de 80 personnes. Un passage qui lui a permis de se forger une expertise reconnue sur les problématiques de cloud hybride, de modernisation applicative et d’espaces de travail numériques.

Cyber-résilience, le mot d’ordre

Sa mission chez Cohesity dépasse le simple pilotage commercial. Mathias Michiels devra imposer un changement de perception sur le marché : faire de Cohesity non pas une solution de protection des données parmi d’autres, mais un partenaire à part entière de la cyber-résilience des organisations capables, selon la promesse de l’entreprise, de survivre aux cyberattaques et d’en ressortir « plus fortes, plus intelligentes et plus fiables ».

Le contexte joue en sa faveur. « Nous sommes à un moment aussi critique pour les entreprises et organisations françaises face à l’accélération des cybermenaces », reconnaît lui-même le nouveau Country Manager. Pour Matthieu Gross, directeur des ventes pour l’Europe du Sud chez Cohesity, « son arrivée marque une étape clé pour notre croissance et notre succès continus dans la région ».

Photo : © DR

The post Mathias Michiels nommé Country Manager de Cohesity France appeared first on Silicon.fr.