SOC 2 impose-t-il un test d'intrusion et des scans de vulnérabilités ?

SOC 2 impose-t-il un test d'intrusion ?

SOC 2 n'impose pas de test d'intrusion. Les Trust Services Criteria le citent dans un point d'attention de CC4.1, comme un exemple des évaluations ponctuelles qu'une organisation peut mener pour vérifier que ses contrôles fonctionnent. Le besoin d'un test, et sa fréquence, découlent de votre analyse de risques et des contrôles que vous décrivez dans votre rapport.

C'est l'AICPA qui publie les critères. Leur forme actuelle est celle des Trust Services Criteria de 2017, avec des points d'attention (points of focus) révisés en 2022, dans un document gratuit mais réservé aux titulaires d'un compte AICPA. Les formulations ci-dessous viennent donc de cabinets d'audit qui les reproduisent. Linford & Co, un cabinet d'expertise comptable américain (CPA) qui réalise des audits SOC 2, le dit sans détour : « the simple answer is no », autrement dit la réponse est non. CC4.1 demande à l'organisation de mener des évaluations continues ou ponctuelles pour s'assurer que les composantes du contrôle interne sont présentes et fonctionnent. Son point d'attention cite le test d'intrusion à côté des certifications indépendantes, comme ISO, et de l'audit interne, parmi les types d'évaluation que la direction peut utiliser. L'article de Linford date de juin 2021, avant la révision de 2022.

La révision de 2022 n'en a pas fait une règle. BARR Advisory, un autre cabinet d'audit SOC 2, cite l'AICPA au sujet des points d'attention révisés : ils « do not, in any way, alter the criteria in the 2017 TSC », c'est-à-dire qu'ils ne changent en rien les critères de 2017.

Sur le papier, le test est donc facultatif, et c'est à vous de justifier votre choix. Linford conseille à toute entreprise qui propose ses services par un site web public et interactif d'envisager sérieusement un test d'intrusion, avec une fréquence et un périmètre fixés par une analyse de risques approfondie.

Dans un cas, le choix est déjà fait. Pour le cabinet d'audit TrustNet, la description du système est votre propre présentation de vos systèmes, services et contrôles, que l'auditeur relit. L'opinion de l'auditeur porte ensuite sur la bonne conception de ces contrôles (Type I) et sur leur fonctionnement dans la durée (Type II). Si votre description ou votre politique annonce un test d'intrusion annuel, ce test est devenu l'un de vos contrôles, et l'auditeur vous demandera le rapport.

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

SOC 2 ne nomme pas le scan de vulnérabilités comme exigence. CC7.1 demande des procédures de détection et de surveillance qui repèrent les changements de configuration introduisant de nouvelles vulnérabilités, et votre exposition aux vulnérabilités nouvellement découvertes. Son point d'attention « Conducts Vulnerability Scans » prévoit des scans périodiques et après tout changement important, puis une correction rapide.

Linford & Co reproduit le point d'attention : les scans doivent tourner « on a periodic basis and after any significant change in the environment », périodiquement et après tout changement important de l'environnement, et l'organisation corrige ce qu'ils trouvent dans des délais raisonnables. Son verdict est le même que pour le test d'intrusion, aucune exigence, mais il l'assortit d'un avertissement : « it may be tough for a user organization to accept a clean SOC 2 report », un client aura du mal à accepter un rapport SOC 2 sans réserve qui ne fait aucune référence aux scans.

Le résumé de la révision de 2022 publié par BARR Advisory ne range pas CC7.1 parmi les changements : pour les opérations système, il cite le traitement des informations confidentielles dans CC7.3. Le critère de gestion des changements, CC8.1, a en revanche gagné des points d'attention sur « identification, testing, and implementation of software patches », soit l'identification, le test et le déploiement des correctifs logiciels. Mettre à jour une dépendance vulnérable revient à appliquer un correctif, si bien que le volet correction des scans relève aussi de la gestion des changements.

Le point d'attention ne nomme ni outil, ni fréquence, ni périmètre. C'est vous qui décidez ce que couvre « l'environnement » (votre code, ses dépendances, les conteneurs, la configuration cloud, les serveurs), vous l'écrivez dans votre politique, et l'auditeur vous juge ensuite sur ce que vous avez écrit.

Quelle différence entre un scan de vulnérabilités et un test d'intrusion ?

Un scan de vulnérabilités est automatique : un outil compare votre code, vos dépendances ou vos serveurs aux faiblesses connues et liste ce qu'il trouve. Un test d'intrusion est mené par des personnes qui exploitent les faiblesses, avec des outils et leur jugement, pour montrer jusqu'où irait un attaquant. Pour SOC 2, les scans soutiennent CC7.1, le test d'intrusion CC4.1.

Linford & Co trace la frontière au même endroit. Une évaluation des vulnérabilités « is an automated activity », une activité automatisée menée avec un outil, alors qu'un test d'intrusion est réalisé par une ou plusieurs personnes qui exploitent les vulnérabilités et les erreurs de configuration avec des outils automatiques et leurs propres techniques. Pour une équipe qui développe du logiciel, « scan » recouvre plusieurs familles d'outils : l'analyse statique du code (SAST), l'analyse des dépendances (SCA), la détection de secrets, et les contrôles sur les fichiers d'infrastructure et les images de conteneurs.

À quelle fréquence scanner pour SOC 2 ?

Scannez aussi souvent que le prévoit votre politique, et après chaque changement important. SOC 2 ne fixe aucun intervalle : le point d'attention « Conducts Vulnerability Scans » de CC7.1 demande des scans périodiques et après tout changement important de l'environnement. Un scan sur chaque pull request couvre les changements, et un scan planifié couvre tout le reste.

CC7.1 a deux moitiés, et chacune appelle son propre déclencheur. La première vise les changements de configuration qui introduisent des vulnérabilités : vous les attrapez en scannant la modification elle-même, en CI, avant le merge. La seconde vise l'exposition aux vulnérabilités nouvellement découvertes : vous l'attrapez en scannant à intervalle fixe du code que vous n'avez pas retouché, parce que de nouveaux avis de sécurité continuent de tomber sur d'anciennes dépendances. Dans notre scan du 3 novembre, quatre des neuf vulnérabilités critiques de dépendances venaient d'avis publiés entre juillet et septembre 2026. Un scan lancé en juin, sur exactement le même code, n'aurait pas pu les signaler.

Écrivez les deux déclencheurs dans votre politique, avec un délai de correction par niveau de criticité pour ce que trouvent les scans. L'auditeur peut prendre n'importe quel résultat de la période et le comparer à vos délais : choisissez des délais que vous savez tenir.

Quelles preuves un auditeur SOC 2 demande-t-il ?

L'auditeur demande des enregistrements : que les scans ont tourné quand votre politique le prévoyait, ce qu'ils couvraient, ce qu'ils ont trouvé, et ce qu'il est advenu de chaque résultat, corrigé avant son échéance ou accepté comme exception motivée et approuvée. Dans un rapport Type II, l'opinion couvre toute une période, et les enregistrements doivent la couvrir aussi.

Un rapport SOC 2 est un examen réalisé par un expert-comptable américain agréé et indépendant (CPA) selon les normes d'attestation de l'AICPA, pour reprendre les termes du communiqué de l'AICPA lui-même. Pour un Type II, l'opinion du CPA porte sur le fonctionnement de vos contrôles pendant une période donnée. Pour la gestion des vulnérabilités, cela se traduit par une courte liste de questions :

Des scanners open source peuvent-ils produire des preuves SOC 2 ?

Les scanners open source produisent la moitié détection des preuves SOC 2. Le 3 novembre 2026, nous avons lancé Trivy, Gitleaks et Opengrep sur OWASP Juice Shop et obtenu 383 résultats bruts dans quatre fichiers JSON, en 56 secondes. Aucun fichier ne nomme le commit scanné, un responsable, une échéance ou un statut, et l'auditeur échantillonne justement cela.

Nous avons utilisé OWASP Juice Shop en version 20.3.0, publiée le 11 octobre 2026. Son README la présente comme « probably the most modern and sophisticated insecure web application », probablement l'application web vulnérable la plus moderne et la plus sophistiquée : les chiffres ci-dessous ne disent donc rien d'une base de code ordinaire, ils montrent la forme de ce que les outils vous remettent. Juice Shop ne fournit pas de lockfile. Pour le scan des dépendances, nous en avons donc généré un le jour même à partir d'une copie de son package.json, avec les scripts d'installation de npm désactivés. Nous avons ensuite lancé quatre commandes :

trivy fs --scanners vuln --format json --output trivy-sca.json sca/
trivy fs --scanners misconfig,secret --format json --output trivy-repo.json juice-shop/
gitleaks dir juice-shop --report-format json --report-path gitleaks.json
opengrep scan --config opengrep-rules/javascript --config opengrep-rules/typescript \
  --config opengrep-rules/terraform --json --output opengrep.json juice-shop/

Résultats de quatre scans open source d'OWASP Juice Shop 20.3.0, lancés le 3 novembre 2026. Nous avons scanné le tag v20.3.0 au commit f189f52, avec les règles communautaires d'Opengrep au commit f1d2b56, les réglages par défaut de Trivy et aucun ajustement. Les quatre exécutions ont pris 56 secondes au total, mise à jour de la base de Trivy comprise :

Chaque outil a trouvé ce pour quoi il a été conçu. Quatre obstacles séparent pourtant ces fichiers d'une preuve SOC 2 :

1. Les doublons. Les cinq secrets trouvés par Trivy figurent parmi les 69 de Gitleaks, au même fichier et à la même ligne. Sur les 54 résultats Terraform d'Opengrep, 17 tombent sur la même ligne qu'un résultat de Trivy, et 34 à trois lignes au plus de l'un d'eux. Sans fusion, un seul problème devient deux tickets et deux échéances.
2. Trois échelles de criticité. Trivy gradue de critical à low, Opengrep de error à info, et Gitleaks ne gradue rien. Une politique qui dit « résultats critiques corrigés sous N jours » a besoin d'une seule échelle : quelqu'un doit donc faire correspondre les deux autres.
3. La couverture. Opengrep a scanné 1 306 fichiers et consigné 32 erreurs d'analyse syntaxique et analyses partielles, dans une section d'erreurs que l'on ne voit qu'en ouvrant le fichier. Un auditeur qui demande si le scan a bien couvert le code a besoin de cette ligne.
4. L'enregistrement lui-même. Les fichiers de Trivy portent un horodatage de création et le chemin scanné. Ceux d'Opengrep n'ont aucun horodatage. En mode répertoire, Gitleaks laisse vides ses champs de commit et de date. Aucun fichier n'a de responsable, d'échéance ni de statut.

Les scanners open source, eux, tiennent bien la route. Nos tests des outils SAST open source vérifiés sur GitHub et de six scanners de secrets open source testés sur un même dépôt piégé montrent que l'on peut couvrir le code et les secrets sans payer de scanner. Le volume est l'autre moitié du travail, et notre article sur ce qui transforme les résultats SAST en bruit explique pourquoi 149 résultats bruts sur le code forment une file de tri, et non 149 vulnérabilités.

Pour transformer ces fichiers en preuve, il vous faut une file de résultats par dépôt, où les résultats de tous les outils sont fusionnés, où chacun reçoit un responsable et une échéance tirés de votre politique, et où son historique reste visible : ouvert, corrigé, accepté comme exception. Les équipes la construisent avec un outil open source de gestion des vulnérabilités comme DefectDojo, avec des tickets, ou avec une plateforme. CybeDefend Open Source se charge de cette partie : il fait tourner les scanners que vous choisissez, n'importe quel outil qui écrit du SARIF, et réunit ce qu'ils trouvent dans une seule file dédoublonnée, gratuitement et sur vos serveurs. Il sort bientôt, et la liste d'attente de CybeDefend Open Source est ouverte.

Qu'est-ce qui change quand des agents IA écrivent le code ?

Les critères SOC 2 restent les mêmes quand des agents IA écrivent le code, mais les changements importants se multiplient : le scan de CC7.1 doit tourner sur chaque modification, pas seulement à intervalle fixe. Les critères 2027 proposés par l'AICPA ajoutent des points d'attention sur l'IA, qui ne s'imposeraient qu'aux missions commençant le 31 décembre 2027 ou après.

La part du code écrit par des agents peut être importante. Le 3 novembre 2026, 482 des 509 commits fusionnés sur la branche principale du dépôt de notre propre site au cours des 90 jours précédents portaient une ligne de co-auteur Claude Code. À ce rythme, trois choses bougent pour SOC 2 :

• Le scan se charge de la lecture ligne à ligne. Une barrière de merge qui scanne chaque pull request est le contrôle qui tourne sur chaque changement, ce que demandent CC7.1 et CC8.1. Notre article sur les contrôles de sécurité d'une pull request écrite par un agent IA détaille cette barrière.
• Les dépendances arrivent avec les fonctionnalités. Un agent qui ajoute un paquet ajoute une entrée que le scan planifié devra surveiller, et chaque mise à jour qu'il fait est un correctif au sens de CC8.1.
• Des tests au vert prouvent moins. Un agent écrit souvent une fonctionnalité et ses tests dans la même session. Ses tests vérifient ce qu'il voulait construire : une règle qu'il a oubliée dans le code peut manquer aussi dans les tests, et la CI reste au vert. Un scanner lancé depuis la CI est un contrôle que l'agent n'a pas écrit.

Les critères eux-mêmes évoluent. Le 28 octobre 2026, l'AICPA a soumis à consultation publique un projet (exposure draft) de nouveaux Trust Services Criteria SOC 2. Son communiqué annonce de nouveaux points d'attention sur « AI governance, model monitoring, prompt manipulation, data poisoning », c'est-à-dire la gouvernance de l'IA, la surveillance des modèles, la manipulation des prompts et l'empoisonnement des données, ainsi que sur la transparence des contenus générés par l'IA, la gestion des données d'entraînement et la prise de décision automatisée. La consultation est ouverte jusqu'au 15 janvier 2027. En cas d'approbation, les nouveaux critères s'appliqueraient aux missions commençant le 31 décembre 2027 ou après, avec une adoption anticipée autorisée. Le communiqué ne dit pas si ces points d'attention concernent les agents de code, et le projet lui-même demande un compte AICPA : nous ne l'avons donc pas lu. Tant que les nouveaux critères ne sont ni définitifs ni en vigueur, votre audit s'appuie sur les critères de 2017 avec les points d'attention de 2022.

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

Ayez une politique écrite de gestion des vulnérabilités, des scans qui tournent à intervalle fixe et sur chaque modification, un enregistrement par résultat avec un responsable, une échéance et son issue, des exceptions approuvées, et un rapport de test d'intrusion si votre analyse de risques en prévoit un, le tout couvrant l'ensemble de la période d'audit.

1. La politique dit quoi, quand et en combien de temps. Le périmètre des scans, le calendrier, les déclencheurs, un délai par niveau de criticité, et qui peut approuver une exception.
2. Chaque modification est scannée. Code, dépendances, secrets et fichiers d'infrastructure sur chaque pull request, qu'une personne ou un agent l'ait ouverte, derrière une barrière qui refuse un résultat critique.
3. Le calendrier attrape les nouveaux avis. Un scan nocturne ou hebdomadaire de la branche principale et des images que vous faites tourner, pour les vulnérabilités publiées après l'écriture du code.
4. Un résultat, un enregistrement. Fusionné entre les outils, sur une seule échelle de criticité, avec un responsable, une échéance, un statut et son historique.
5. Les exceptions sont écrites. Le périmètre, la raison, l'approbateur et la date d'expiration.
6. Le test d'intrusion est planifié. Un périmètre tiré de votre analyse de risques, le rapport conservé, les constats graves corrigés puis vérifiés à nouveau.
7. Le rapport couvre la période. Un seul document construit à partir des enregistrements, et non un tableur assemblé la semaine qui précède l'arrivée de l'auditeur.

Scan de chaque modificationUn enregistrement par résultatResponsable et échéanceCorrigé, ou exception approuvéeDans le rapport de la période

Les points 2, 5 et 7 sont ce que fait 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 laisse passer un risque plus faible avec un avertissement, 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 ou en JSON pour un outil de GRC. Nous faisons le même exercice de notre côté : l'audit SOC 2 Type II de CybeDefend est en cours. Si vous préparez le vôtre avec une équipe qui code avec des agents, nous pouvons le passer en revue avec vous.

Questions fréquentes

Faut-il un test d'intrusion pour un SOC 2 Type 2 ?

Non. Les rapports Type I et Type II reposent sur les mêmes critères, et aucun d'eux n'impose de test d'intrusion. Un Type II vérifie que vos contrôles ont fonctionné sur une période : si votre politique prévoit un test d'intrusion annuel, l'auditeur vérifie qu'il a bien eu lieu pendant la période et que ses constats ont été traités.

À quelle fréquence faut-il faire un pentest pour SOC 2 ?

Les critères ne fixent aucun intervalle. Ce sont votre analyse de risques et votre politique qui le fixent, et l'auditeur vérifie que vous avez respecté ce que vous avez écrit. Un changement important dans ce que votre système expose, comme une nouvelle API publique ou un nouveau produit, est une bonne raison de tester à nouveau avant la prochaine date prévue.

Un scan de vulnérabilités suffit-il pour SOC 2 ?

Pour CC7.1, un programme de scans est ce que les auditeurs s'attendent à voir, avec la trace du traitement de chaque résultat. Un scan ne remplace pas l'évaluation de vos contrôles au titre de CC4.1, qui peut prendre la forme d'un test d'intrusion, d'un audit interne ou d'une certification indépendante.

Le SAST est-il obligatoire pour SOC 2 ?

Aucun critère ne nomme le SAST. Le point d'attention de CC7.1 couvre les vulnérabilités et les erreurs de configuration de votre environnement, et CC8.1 demande que les changements logiciels soient testés et approuvés avant leur mise en œuvre. Si vous développez du logiciel, scanner le code et ses dépendances sur chaque modification est la façon la plus simple de montrer les deux.

Les scanners open source suffisent-ils pour un audit SOC 2 ?

Oui. Les critères ne nomment aucun outil, et l'auditeur vérifie que les scans ont tourné comme le prévoit votre politique et que les résultats ont été traités. Les scanners open source font l'affaire si vous conservez autour d'eux un enregistrement complet : les dates, le commit scanné, les résultats fusionnés entre outils, les responsables, les échéances et l'issue de chaque résultat.

Que dit le critère CC7.1 de SOC 2 ?

CC7.1 est le critère commun consacré à la détection et à la surveillance. Il demande à l'organisation d'utiliser des procédures qui identifient les changements de configuration introduisant de nouvelles vulnérabilités, ainsi que son exposition aux vulnérabilités nouvellement découvertes. L'un de ses points d'attention consiste à mener des scans de vulnérabilités périodiquement et après les changements importants.

Que dit le critère CC4.1 de SOC 2 ?

CC4.1 est le critère commun consacré aux activités de pilotage (monitoring activities). Il demande à l'organisation de mener des évaluations continues ou ponctuelles pour confirmer que les composantes du contrôle interne sont présentes et fonctionnent. Son point d'attention cite le test d'intrusion, les certifications indépendantes comme ISO, et l'audit interne comme exemples de ces évaluations.

Que changent les futurs critères SOC 2 de 2027 ?

L'AICPA a publié le 28 octobre 2026 un projet soumis à consultation qui restructure une partie des critères et ajoute des points d'attention sur l'IA, dont la gouvernance de l'IA, la manipulation des prompts, l'empoisonnement des données et la transparence des contenus générés par l'IA. La consultation se termine le 15 janvier 2027. En cas d'approbation, les critères s'imposeraient aux missions commençant le 31 décembre 2027 ou après, avec une adoption anticipée autorisée.