Chez IZZY, nous avons rencontré cette méthode sur LinkedIn il y a plus d’un an : un compte compromis proposait un projet, puis demandait d’installer un logiciel pour un exercice technique. Nous retrouvons régulièrement ce type d’approche dans notre réseau professionnel.
Les développeurs d’entreprises établies sont également visés pour les accès que donnent leurs postes au code source, aux chaînes CI/CD et à la production. Pour une entreprise qui fait développer une application ou ajoute une fonction IA, trois décisions structurent la protection : ce qui peut s’exécuter sur un poste, les données accessibles au logiciel et les preuves exigées avant livraison.
1. Comment l’IA aide les attaquants à atteindre les données
L’IA peut faciliter la recherche de cibles, la rédaction et l’adaptation linguistique de messages trompeurs, le développement ou le débogage de code malveillant, la construction et la maintenance d’infrastructures d’attaque et le traitement de données volées. Le gain peut venir d’une préparation, d’une adaptation et d’une répétition plus rapides, sans nouvel exploit. Les services IA deviennent aussi des cibles lorsque leurs identifiants ouvrent l’accès à des données ou à des ressources de calcul.
- Usurpation et vol de jetons. Profils compromis ou copiés, messages personnalisés et voix ou vidéos de synthèse peuvent soutenir une fausse identité. Des kits de phishing-as-a-service comme EvilTokens, dont Microsoft a perturbé l’infrastructure en septembre 2026, ont associé préparation des messages par IA et détournement de la connexion par code d’appareil : la victime autorise la session de l’attaquant sur une page de connexion légitime. Confirmez la demande par des coordonnées obtenues séparément ; ni le profil ni la page d’authentification ne prouvent qui en est à l’origine.
- Faux logiciels et ClickFix. ClickFix présente une exécution de code comme une réparation ou une vérification nécessaire. Des campagnes macOS ont distribué des voleurs d’informations tels que MacSync et Atomic Stealer (AMOS). Lumma, autre voleur d’informations, sert à collecter des données sensibles sur les postes.
- Administration à distance. Des attaquants détournent des outils légitimes de supervision et d’administration à distance, notamment ScreenConnect. La prise de contrôle et le vol d’informations sont des capacités distinctes : reconnaître un logiciel de support n’authentifie pas son opérateur et ne justifie pas son accès au poste.
- Dépendances et outils d’agents. Des versions piégées de paquets peuvent s’exécuter à l’installation. Les extensions d’agents peuvent exécuter du code avec les privilèges de l’utilisateur ; les connexions MCP permettent aux applications IA d’atteindre des outils et données externes. Examinez ce qui s’exécute et les identités utilisables avant de faire confiance à la modification produite.
Ces mécanismes ne nécessitent pas d’IA. Son usage documenté à certaines étapes d’une opération ne démontre pas son implication dans chaque approche, y compris celle reçue par IZZY.
2. Examiner la première exécution avant la revue de code
Le logiciel fourni pour un exercice technique peut utiliser les identifiants du développeur avant qu’une modification existe à approuver.
Avant d’exécuter des fichiers inconnus, établissez leur provenance et la nécessité de les lancer. Examinez scripts d’installation, tâches d’éditeur, extensions et dépendances. Prévoyez un environnement jetable convenu, sans identifiants de production ni sessions de navigation personnelles ; limitez les dossiers montés et les accès réseau. Un conteneur qui atteint les fichiers et identifiants du poste expose encore ces ressources.
La recherche de secrets et l’analyse des dépendances contribuent à cet examen sans certifier la sûreté du projet. La décision porte sur le besoin et les limites de l’exécution prévue. Une approbation ultérieure de pull request n’annule pas les accès accordés pendant la préparation.
Si un code suspect a déjà été exécuté, sollicitez l’équipe informatique ou sécurité chargée de la réponse. Conservez échanges, détails d’installation et journaux. Coordonnez l’investigation et les éventuelles mesures de confinement des identités ou sessions depuis un appareil sain. Changer un mot de passe ne démontre pas la remise en sécurité ; une sauvegarde n’annule pas la copie de données.
3. Revue de sécurité du code : choisir les méthodes selon le risque
Si les contrôles d’accès n’ont pas été vérifiés, y compris dans du code généré par IA, la revue de référence examine le parcours applicatif concerné et ses contrôles. La revue des modifications porte sur un changement délimité et ses effets sur ces contrôles. L’analyse des menaces hiérarchise les données à protéger et les conséquences ; l’analyse des flux suit l’information entre zones de confiance ; la revue de logique métier interroge les actions permises. Une petite modification peut dépendre d’un modèle de droits bien plus large, encore non examiné.
Choisissez le format humain pour faire apparaître ces hypothèses. La revue d’une pull request par un pair convient à un changement délimité dont le contexte est disponible. Une revue guidée ou en binôme aide à reconstruire un parcours. Pour un changement sensible, une inspection formalisée précise préparation, critères et responsables des constats. Aucun format ne remplace les compétences métier et sécurité du relecteur.
| Vérification | Objet de l’examen | Preuves attendues et limites |
|---|---|---|
| Typage, lint et analyse statique de sécurité (SAST) | Incohérences du code et motifs de vulnérabilité détectables sans exécution. | Révision examinée, règles et constats analysés. Un résultat sans alerte ne démontre pas les droits métier. |
| Recherche de secrets | Identifiants reconnaissables dans les fichiers et l’historique convenus. | Emplacements et traitement des constats, sans reproduire les secrets. L’absence d’alerte ne prouve pas leur absence. |
| Analyse des composants logiciels (SCA) | Versions des dépendances comparées aux vulnérabilités connues. | Versions installées, correspondances et suites données. Un paquet non signalé peut rester malveillant. |
| Revue assistée par IA | Défauts possibles, parcours oubliés et hypothèses. | Constats confrontés au code et à un comportement reproductible. La confiance du modèle ne vaut pas validation. |
| Tests d’intégration et d’autorisation | Actions permises et interdites entre composants connectés. | Acteur, ressource, action, résultat attendu et réponse réelle. La couverture dépend des cas choisis. |
| Tests dynamiques de sécurité applicative (DAST) et fuzzing | Comportement de l’application face à des requêtes et entrées variées. | Version, configuration, entrées exercées et constats. Les règles métier exigent des cas explicites. |
| Test d’intrusion sur périmètre convenu | Faiblesses qu’un spécialiste peut combiner dans les limites autorisées. | Cible, contraintes, constats et nouveaux tests. Les résultats restent liés au périmètre et au moment de l’examen. |
Un export qui traverse plusieurs services, une exposition de données sensibles ou des questions d’accès sans réponse peuvent justifier des tests spécialisés distincts. Précisez le doute à lever plutôt que de commander un « contrôle de sécurité » indéfini. Notre guide pour cadrer un pentest applicatif détaille ce qu’il faut convenir avant le test.
4. Export de factures : tester les droits et accepter sur preuves
Prenons un export de factures construit avec l’IA et ajouté à un portail client existant. Dans cet exemple fictif, les vérifications ont lieu sur la préproduction de l’entreprise, avec deux comptes clients synthétiques.
Définir l’acteur, les données et l’action. Le client A peut exporter ses factures, jamais celles de B. Un visiteur non connecté ne peut exporter ni les unes ni les autres. Nommez l’éventuelle exception administrative. La connexion établit l’identité ; le serveur doit appliquer la règle d’accès aux factures à chaque requête.
Choisir la revue autour de cette règle. Commencez par l’autorisation héritée, avec revue de référence et analyse des flux : identité, sélection du client, requête de données, tâche d’export et fichier stocké. Examinez ensuite les modifications de l’export et leurs effets sur ces contrôles. Priorisez les tests entre clients selon la règle convenue d’appartenance des factures.
Tester les accès autorisés et interdits. Testez l’export permis de A, sa tentative d’obtenir les factures de B, une requête non authentifiée et l’accès direct au fichier généré. Si l’expiration d’une session ou le retrait d’un rôle modifie les droits d’export, définissez la politique attendue et testez-la. Un bouton masqué ne renseigne pas sur le serveur ou le point de téléchargement.
Comparez le corps des réponses et les fichiers à la règle d’accès. Un statut de succès ne démontre pas l’autorisation ; un statut d’erreur ne prouve pas l’absence de données clients dans la réponse.
Pour la même vérification sur les requêtes, exports, fichiers et notifications en temps réel, voir Un client peut-il accéder aux données d’un autre ?.
Conserver les preuves de recette. Notez commit et build, configuration utile, périmètre, rôles des comptes, cas de test, réponses réelles et traces applicatives pertinentes. Reliez les constats aux corrections et aux nouveaux tests sur la version corrigée. Signalez les cas non exécutés et les questions ouvertes. Fixez les exigences avant les tests ; OWASP ASVS peut aider à les rendre vérifiables.
5. Vérifier le déploiement et les moyens d’arrêt
La lecture du code ne décrit pas toute la production. Comparez la version livrée à l’environnement d’exécution, aux dépendances installées, aux composants du CMS, aux intégrations et aux paramètres de déploiement réels. Pour une faille connue, établissez si une version concernée est présente et accessible, les conséquences possibles et le correctif ou confinement disponible. Scanners et techniques d’exploitation connues restent des moyens d’attaque.
Un composant vulnérable peut nécessiter une correction ciblée ou une mise à jour. Un remplacement plus large demande sa propre justification ; notre guide de modernisation applicative explique comment comparer les travaux et les preuves de recette.
Nommez les destinataires des alertes de sécurité et les personnes capables de suspendre le fonctionnement concerné. Lorsqu’un agent utilise des identifiants partagés ou lance une tâche dans un autre service, fermer son interface peut laisser ces accès ou cette tâche actifs. Notre article sur l’arrêt d’un outil IA examine cette limite.
Examinons une question d’accès ensemble
Présentez l’application ou l’intégration et la décision à prendre : un export franchit-il la séparation entre clients, un agent peut-il agir hors de sa mission, le code existant permet-il d’accepter une nouvelle version ?
La revue IZZY de sécurité des agents IA et du code examine le code, les connexions agent/MCP, les droits, secrets, dépendances et traces du périmètre convenu. Elle fournit constats étayés, limites et priorités ; corrections et nouveaux tests sont cadrés séparément. Cette revue technique exclut test d’intrusion, protection des postes et réponse d’urgence à incident.