ISO 27001 et codage sécurisé (A.8.28) : ce que l'auditeur demande quand des agents IA écrivent le code

Que demande la mesure A.8.28 d'ISO 27001 ?

La mesure 8.28 d'ISO/IEC 27001:2022, Secure coding (codage sécurisé), demande à l'organisme d'appliquer des principes de codage sécurisé à son développement logiciel. Elle est apparue avec l'édition 2022. Ses lignes directrices dans ISO/IEC 27002:2022 suivent trois temps, la préparation avant d'écrire, l'écriture, puis la vérification et la maintenance, et s'étendent au code de tiers et aux composants open source.

L'organisme de certification DQS a décrit la nouvelle mesure en janvier 2023, dans un article de son auditeur Markus Jegelka : le cadre « is to be applied holistically both to the company's own program code and to software from third parties and open source sources », autrement dit au code maison comme au code de tiers et à l'open source. L'édition 2022 est la seule qu'un auditeur utilise aujourd'hui : la transition depuis l'édition précédente s'est terminée le 31 octobre 2025, date à laquelle les certificats fondés sur l'ancienne version ont expiré, comme le rappelle l'organisme de certification irlandais NSAI en citant le document obligatoire MD 26 de l'IAF.

Un auditeur lit la 8.28 avec les mesures de développement qui l'entourent, et chacune d'elles devient une question très concrète dès que des agents écrivent le code :

Les intitulés sont ceux de l'annexe A de 2022, en anglais. L'ISO vend le texte de ses normes, si bien que les formulations citées dans ce guide viennent d'organismes de certification et de cabinets de conseil qui les reproduisent.

ISO 27001 dit-elle quelque chose des agents de code IA ?

ISO 27001 ne dit rien des agents de code IA. Son édition 2022 date d'octobre 2022, a reçu un amendement depuis selon le catalogue de l'ISO, et aucune mesure de son annexe A ne porte sur l'IA. Le code qu'un agent écrit dans votre dépôt, avec un compte que vous lui avez donné, est votre code : les mêmes mesures s'y appliquent.

Cette réponse déçoit ceux qui attendent une clause spéciale, et c'est pourtant la plus utile. Les lignes directrices de la 8.28 demandent déjà d'écarter les pratiques non sûres, parmi lesquelles les mots de passe codés en dur et les extraits de code non approuvés, d'après le résumé d'ISO 27002 publié par ISMS.online. Un agent qui recopie un motif trouvé ailleurs dans le dépôt, ou appris pendant son entraînement, produit exactement cela, un extrait de code non approuvé, plus vite qu'un relecteur ne peut le lire ligne à ligne. La mesure a été écrite pour du code de toute provenance, et les agents ne sont qu'une provenance de plus.

Deux autres questions reviennent quand une équipe utilise des agents, et elles sortent toutes deux de la 8.28. Qu'est-ce que l'agent envoie au fournisseur du modèle, et ce fournisseur est-il évalué comme un sous-traitant ? Nos guides sur ce que Claude Code envoie à Anthropic et sur ce que Cursor conserve répondent à la première, outil par outil. Et si l'on vous demande s'il vous faut ISO/IEC 42001, la norme de système de management de l'IA publiée par l'ISO en décembre 2023 pour les organismes qui fournissent ou utilisent des produits ou services fondés sur l'IA, c'est une certification distincte, qu'ISO 27001 n'exige pas.

Quelles preuves l'auditeur demande-t-il quand des agents écrivent le code ?

L'auditeur demande trois sortes de preuves : des documents qui disent comment vous développez de façon sécurisée, une configuration qui montre que vos contrôles sont imposés, et des traces de leur passage sur les modifications de la période auditée. Avec des agents, les documents nomment les agents, et les traces couvrent chaque modification fusionnée, y compris celles qu'aucune personne n'a écrites.

Le cabinet Advisera résume le test de la 8.28 en une phrase sur sa page consacrée à la mesure : l'auditeur vérifie « if principles for secure coding are integrated into the software lifecycle process », c'est-à-dire si ces principes sont intégrés au cycle de développement, et s'il ne les trouve pas, « this is considered a nonconformity », une non-conformité. Les documents eux-mêmes « are not mandatory, but are recommended » : une politique de développement sécurisé pour une PME ou une ETI, une politique de codage sécurisé distincte pour une grande entreprise. En pratique, l'auditeur pose quelques questions et échantillonne des modifications pour vérifier les réponses :

Les tests méritent une mise en garde à part. Quand l'agent écrit la fonctionnalité et ses tests dans la même session, des tests au vert prouvent seulement que le code fait ce que l'agent a compris. Dans l'étude contrôlée de CybeDefend, au moins un tiers des écarts aux règles que l'agent a laissés dans le code étaient couverts par ses propres tests au vert, si bien que la CI ne les aurait jamais signalés. Un test de sécurité que l'agent n'a pas écrit, un scan ou un contrôle de votre CI, donne son sens à la 8.29.

Un fichier CLAUDE.md ou AGENTS.md prouve-t-il le codage sécurisé ?

Un fichier de règles ne prouve rien : c'est une politique que l'agent lit au début d'une session, et rien dedans n'enregistre si le code l'a suivie. Dans l'étude contrôlée de CybeDefend du 24 août 2026, une section de règles réaliste a laissé autant de règles enfreintes par ticket que l'absence de fichier, 2,27 contre 2,28.

Les équipes qui préparent un audit avec des agents placent souvent leur norme de codage sécurisé dans CLAUDE.md ou AGENTS.md, et c'est un bon endroit pour que l'agent la trouve. La documentation d'Anthropic sur la mémoire en fixe la limite : Claude traite ces fichiers « as context, not enforced configuration », comme du contexte et non comme une configuration imposée, et « there's no guarantee of strict compliance ». Notre étude a mesuré ce que cela donne sur de vrais tickets. Un seul agent, Claude Opus 5, a traité trente tickets de développement dans trois configurations, soit quatre-vingt-dix exécutions notées à l'aveugle sur des grilles scellées. Avec une section de règles tenue à la main, l'agent a appliqué exactement 7 des 55 points de règle évalués, le même score que sans fichier. Avec le corpus complet des règles copié mot pour mot dans le fichier, il est monté à 7 sur 11. Le détail est dans notre article sur la question de savoir si Claude Code suit CLAUDE.md.

Pour un auditeur, c'est toute la différence entre la conception et le fonctionnement. Le fichier montre que vous avez écrit la norme et que vous l'avez donnée à l'agent, ce qui sert pour la 8.25 et la 8.28. Il ne montre rien du code qui en est sorti. Servir chaque règle au moment où l'agent écrit la ligne a fait mieux dans la même étude, 0,28 règle enfreinte par ticket, et c'est ce que fait VibeDefend. Même dans ce cas, l'auditeur n'accepte comme preuve que le contrôle qui a tourné sur la modification et la trace qu'il a laissée.

Comment montrer quel code a été écrit par un agent ?

Votre historique git le montre, si vos agents y laissent une trace. Par défaut, Claude Code ajoute à chaque commit une ligne Co-Authored-By qui nomme le modèle, et un réglage suffit à la retirer. Le 27 octobre 2026, 467 des 494 commits de la branche principale du dépôt de notre propre site, sur les 90 jours précédents, portaient cette ligne.

Nous avons lancé deux commandes sur ce dépôt pour les compter :

git log origin/main --since=2026-07-29 --no-merges --format=%H | wc -l
git log origin/main --since=2026-07-29 --no-merges -i --grep="Co-Authored-By: Claude" --format=%H | wc -l

Ces lignes nomment cinq modèles Claude différents sur la période, l'historique dit donc quel modèle a écrit quelle modification, et les 27 autres commits n'en portent aucune. La référence des réglages explique d'où elle vient : par défaut, Claude Code ajoute Co-Authored-By: <name> <noreply@anthropic.com>, où le nom est celui du modèle utilisé, et mettre attribution à false la fait disparaître. Une trace que chaque développeur peut désactiver reste une convention. Si vous voulez qu'elle compte comme preuve, fixez-la dans les réglages gérés que votre organisation déploie, et vérifiez ce que vos autres agents laissent dans les commits et les pull requests, car chaque outil procède à sa façon.

L'auteur dit à l'auditeur quelles modifications regarder, alors que le contrôle tient dans les barrières par lesquelles passe chaque modification. Notre article sur la revue des pull requests écrites par un agent IA explique pourquoi un compte machine dédié avec des commits signés vaut mieux qu'une étiquette qu'un contributeur peut oublier.

SOC 2 demande-t-il la même chose ?

SOC 2 demande à peu près la même chose, à travers deux critères. CC8.1 exige que les changements logiciels soient autorisés, conçus, développés, documentés, testés, approuvés et mis en œuvre. CC7.1 exige une détection des nouvelles vulnérabilités, avec les scans parmi ses points d'attention. Un rapport Type II vérifie ensuite que ces contrôles ont fonctionné sur une période.

Les Trust Services Criteria de l'AICPA sont derrière une connexion sur le site de l'AICPA, nous citons donc le texte tel que le reproduit la documentation de Wazuh. CC8.1 : « The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives. » CC7.1 : « To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities. » Parmi les points d'attention qui les accompagnent, CC8.1 compte « Tests System Changes » et « Approves System Changes », et CC7.1 compte « Conducts Vulnerability Scans ».

La différence avec ISO 27001 tient à la forme du résultat. L'ISO certifie un système de management, avec les mesures de l'annexe A que vous avez retenues dans votre déclaration d'applicabilité. SOC 2 est un rapport d'attestation. Selon le cabinet d'audit TrustNet, « A licensed CPA gives an opinion on whether your controls are properly designed (Type I) and, if applicable, effectively operating over time (Type II) » : un expert-comptable agréé américain se prononce sur la conception des contrôles en Type I, et sur leur fonctionnement dans la durée en Type II. Avec des agents, une période Type II suppose des traces pour chaque modification sur plusieurs mois, et l'auditeur les échantillonne comme le ferait un auditeur ISO. Une équipe prête pour l'un est presque prête pour l'autre.

Que faut-il avoir prêt avant l'audit ?

Ayez une politique de développement sécurisé qui nomme vos agents, une norme de codage sécurisé, un scan sur chaque modification derrière une barrière qui refuse les vulnérabilités critiques, un registre des exceptions avec approbateur et date d'expiration, des pull requests testées et approuvées, et un rapport qui couvre la période auditée, le tout à jour le jour où l'auditeur échantillonne.

1. La politique nomme les agents. Quels agents, quels comptes, quels dépôts, et ce que l'agent n'a pas le droit de faire seul, comme fusionner ou déployer.
2. La norme est courte et contrôlable. Elle liste ce que vous interdisez et renvoie au contrôle qui détecte chaque point. Une règle qu'aucun contrôle ne détecte ne peut être tenue que par un relecteur.
3. Chaque modification passe le même scan. Code, dépendances, secrets et fichiers d'infrastructure, sur chaque pull request, qu'une personne ou un agent l'ait ouverte.
4. La barrière décide, et garde la trace. Une vulnérabilité critique bloque le merge ; un risque plus faible déclenche un avertissement et passe. Chaque exception est limitée à un périmètre, datée, justifiée et approuvée nommément.
5. L'approbation et les tests restent attachés à la modification. La pull request porte l'approbation, le passage en CI et le résultat du scan, si bien qu'une modification échantillonnée s'explique d'elle-même.
6. Le rapport couvre la période. Un document que l'auditeur peut lire, construit à partir des scans et non recopié d'un tableur.

Ticket avec exigencesL'agent écrit la modificationScan de la modificationLa barrière bloque ou avertitApprouvée et testéeDans le rapport

Les points 3, 4 et 6 sont ce que produit la plateforme AppSec de CybeDefend. Elle analyse chaque dépôt pour les failles du code (SAST), les dépendances (SCA), les secrets, l'infrastructure as code, les conteneurs et les pipelines CI/CD. Une politique de sécurité écrite sous forme de code bloque le merge sur une vulnérabilité critique et avertit pour un risque plus faible, dans toute l'organisation, ses équipes et leurs projets, et une exception est limitée à un chemin, datée, justifiée et approuvée nommément, chacune laissant une ligne d'audit. Les rapports de sécurité rattachent les résultats à l'OWASP Top 10 et au CWE Top 25, par organisation, équipe ou projet, exportés en PDF pour l'auditeur, en HTML, ou en JSON pour un outil de GRC. Si vous préparez ISO 27001 ou SOC 2 avec une équipe qui code avec des agents, nous pouvons le passer en revue avec vous. Pour une vue d'ensemble de ce qui change quand des agents écrivent le code, commencez par notre guide de la sécurité des agents de code IA.

Questions fréquentes

Peut-on utiliser des agents de code IA sous ISO 27001 ?

Oui. Rien dans ISO/IEC 27001:2022 ne les interdit, et aucune mesure de son annexe A ne porte sur l'IA. Le code qu'un agent écrit dans votre dépôt est votre code, les mesures 8.25 à 8.29 et 8.32 s'y appliquent donc comme au code tapé par un développeur. Votre politique doit dire quels agents sont autorisés et comment leurs modifications sont contrôlées.

La mesure 8.28 de l'annexe A est-elle obligatoire ?

Pour une entreprise qui développe du logiciel, en pratique oui. ISO 27001 permet d'exclure une mesure de l'annexe A, mais la clause 6.1.3 d) impose de justifier l'exclusion dans la déclaration d'applicabilité, et exclure le codage sécurisé quand on écrit du code se défend mal. Un auditeur qui ne trouve aucun principe de codage sécurisé dans votre processus de développement relève une non-conformité.

Faut-il une politique de codage sécurisé pour ISO 27001 ?

ISO 27001 ne la rend pas obligatoire, mais l'auditeur s'attend à trouver vos principes de codage quelque part, avec la façon dont vous les contrôlez : dans une politique de développement sécurisé pour une PME ou une ETI, dans une politique de codage sécurisé distincte pour une grande entreprise. Elle s'applique à vos développeurs comme à vos agents.

Un CLAUDE.md ou un AGENTS.md suffit-il pour un audit ISO 27001 ?

Non. Il montre que vous avez donné votre norme à l'agent, pas que le code la respecte. Anthropic écrit que Claude traite ces fichiers comme du contexte et non comme une configuration imposée, et dans l'étude de CybeDefend du 24 août 2026, un fichier de règles réaliste a laissé 2,27 règles enfreintes par ticket, contre 2,28 sans fichier. L'auditeur veut les traces des contrôles lancés sur chaque modification.

Faut-il une relecture humaine de chaque modification écrite par un agent ?

L'auditeur attend que chaque modification soit approuvée avant la mise en production : l'approbation des changements est un point d'attention de CC8.1 pour SOC 2, et la mesure 8.32 d'ISO 27001 couvre la gestion des changements. C'est votre politique qui fixe la façon d'approuver les modifications des agents, et l'auditeur vérifie que les pull requests échantillonnées correspondent à ce qu'elle dit.

Faut-il ISO 42001 pour utiliser des agents de code IA ?

Non. ISO/IEC 42001:2023 est une norme distincte, consacrée au système de management de l'IA et conçue par l'ISO pour les organismes qui fournissent ou utilisent des produits ou services fondés sur l'IA. ISO 27001 ne l'exige pas, et votre auditeur 27001 évalue votre usage des agents à travers les mesures de la 27001.

SOC 2 impose-t-il des scans de vulnérabilités ?

Le critère CC7.1 demande une détection et une surveillance qui identifient les nouvelles vulnérabilités, et « Conducts Vulnerability Scans » figure parmi ses points d'attention. Les critères ne nomment aucun outil. L'auditeur teste les contrôles que vous avez décrits, et dans un rapport Type II, il les teste sur toute la période.

Comment prouver quel code a été écrit par un agent IA ?

Appuyez-vous sur ce que vos agents écrivent dans git. Par défaut, Claude Code ajoute à chaque commit une ligne Co-Authored-By qui nomme le modèle, et le réglage attribution peut la retirer : verrouillez-la dans les réglages gérés. Un compte machine dédié avec des commits signés est plus solide. L'auteur indique à l'auditeur le périmètre, et les contrôles sur chaque modification font la preuve.