SOC 2 · ISO 27001

Réussir SOC 2 ou l'ISO 27001 couvre-t-il la divulgation de licences ?

Non. Les certifications de sécurité et la divulgation de licences tierces répondent à des questions différentes, et les deux peuvent être vraies en même temps : vous pouvez détenir un certificat valide tout en devant produire un dossier de licences révisé, au niveau du produit.

Dernière mise à jour : 2 juillet 2026

01Ce que pointe cette page

Les points de défaillance négligés

Ils apparaissent en diligence et en audit : les obligations existent, la preuve manque, et l'artefact attendu par les acheteurs est absent.

Les licences open source sont des obligations légales, pas des préférences
MIT, Apache, GPL, LGPL et les accords de SDK propriétaires imposent des conditions : mention, attribution, copyleft, règles de distribution. Les manquer constitue une violation de licence, pas un écart de style. Les programmes SOC 2 et ISO ne font pas disparaître ces obligations ; ils demandent si vos contrôles les détectent avant la livraison.
ISO 27001 : la propriété intellectuelle est explicite
L'Annexe A 5.32 exige des procédures pour respecter les droits de propriété intellectuelle, y compris les licences logicielles. Les auditeurs attendent des preuves, pas seulement un PDF de politique. Omettre les textes de licence requis là où les licences l'exigent constitue à la fois une violation de propriété intellectuelle et un échec de preuve du SMSI, quand vos contrôles prétendent que les logiciels tiers sont gérés.
SOC 2 : aucun contrôle de page de licences, mais les auditeurs suivent les pistes
Les Trust Services Criteria ne mentionnent pas « publier toutes les licences sur un site web ». Les auditeurs suivent tout de même la conformité juridique et la gestion des changements. Les lacunes systémiques (mentions manquantes, inventaire non révisé, absence de dossier au niveau du produit) apparaissent comme des déficiences de contrôle quand les échantillons ne correspondent pas à la politique.
Le périmètre de la certification n'est pas le périmètre du produit
Un certificat SOC 2 Type II ou ISO couvre votre système et une période, pas automatiquement chaque dépendance de chaque SKU. Les acheteurs posent quand même des questions spécifiques au produit. Votre certification aide ; elle ne remplace pas la divulgation de licences tierces pour le produit sous contrat.
Les dossiers de preuves deviennent obsolètes entre les audits
Les équipes soumettent à la surveillance ISO le même tableur open source que l'année dernière, alors que l'ingénierie a livré douze versions entre-temps. Les auditeurs de surveillance échantillonnent les systèmes en production. Le décalage entre la preuve et la production est un constat majeur classique, et le même décalage fait échouer les renouvellements côté achats.
L'analyse de sécurité n'est pas une révision de licences
Les scanners de vulnérabilités et les outils SBOM identifient les composants et parfois des champs de licence. Ils ne joignent pas le texte intégral des licences, n'approuvent pas le risque de copyleft, et ne publient pas de divulgation prête pour les acheteurs. Assimiler la sortie de l'outillage AppSec à la conformité des licences crée une fausse confiance, à la fois dans les preuves SOC et dans les réponses aux appels d'offres.
Les mauvaises surprises de copyleft touchent aussi les organisations certifiées
De la GPL ou de l'AGPL dans un produit livré sans offre de code source ni revue de conformité est un problème juridique et d'audit, indépendamment de la certification ISO 27001. Une découverte pendant la diligence de l'acheteur, plutôt que lors d'une revue interne, est la voie la plus coûteuse.
Les acheteurs veulent une preuve en plus de votre rapport
Les clients grand compte demandent votre rapport SOC et un dossier de licences tierces pour le produit : inventaire, texte intégral, processus de maintenance. Le trust center couvre la posture de sécurité ; la divulgation de licences couvre les obligations de propriété intellectuelle dans la base de code. Les deux apparaissent dans les revues fournisseurs matures.

SOC 2 et l'ISO 27001 prouvent que vous exploitez un système de sécurité et de management : contrôle d'accès, gestion des changements, traitement des risques, supervision des fournisseurs. Les auditeurs examinent la conception des contrôles et leur efficacité opérationnelle. Aucune des deux certifications n'inventorie par défaut toutes les obligations de licences open source de chaque produit livré.

Les acheteurs considèrent la certification comme un prérequis, puis demandent séparément une divulgation de licences tierces (texte intégral, attribution, inventaire à l'échelle du produit). Réussir SOC 2 ne répond pas à la question « quels composants GPL se trouvent dans le build sous licence que nous avons acheté ».

Qu'exige réellement l'ISO 27001 sur les licences open source ?

L'ISO/IEC 27001:2022 exige que vous exploitiez des procédures garantissant le respect des droits de propriété intellectuelle, y compris les conditions des licences logicielles, au titre du contrôle 5.32 de l'Annexe A. Elle ne prescrit pas de page de licences publique, mais un auditeur peut demander la preuve que les conditions des licences tierces de ce que vous livrez sont réellement respectées.

Un document de contrôle affirmant « nous respectons les licences open source » sans preuve (inventaire révisé, texte intégral, alignement sur les versions) est un constat d'audit en puissance. Surtout quand un test d'échantillonnage trouve des paquets en production absents de toute liste.

Une politique pour les licences acceptables et les processus d'approbation.
Une preuve que les produits livrés respectent les conditions des licences tierces.
Des enregistrements de révision, pas seulement la sortie d'une analyse de découverte.
Un alignement entre ce que revendique le SMSI et ce que livre l'ingénierie.
Le traitement des changements de licence lors des mises à jour de dépendances.

Que recherchent en pratique les auditeurs SOC 2 sur la conformité des licences ?

Les auditeurs SOC 2 n'exigent pas de page de licences publique ; ils vérifient si vos contrôles au titre des Trust Services Criteria de l'AICPA pour la conformité juridique, la gestion des fournisseurs et le contrôle des changements détectent réellement les obligations de licences tierces. Une hygiène open source négligée y apparaît comme une preuve fragile face à des critères que vous prétendez déjà respecter.

Les auditeurs échantillonnent les systèmes. Ils demandent comment vous savez que les logiciels tiers sont correctement sous licence. « Nous exécutons npm audit » n'est pas une réponse. Un badge de certification sur votre site web sans inventaire au niveau du produit n'en est pas une non plus.

Contrôle	Ce qu'attendent les auditeurs	La preuve qui le satisfait
ISO 27001 A 5.32	Des procédures garantissant la conformité en matière de propriété intellectuelle et de licences logicielles	Un inventaire révisé avec texte intégral des licences par produit livré
SOC 2 CC2.2	Gouvernance et supervision des obligations de conformité	Des journaux de révision montrant qui a approuvé quels composants, et quand
SOC 2 CC8.1	Les changements de dépendances passent par la gestion des changements	Des enregistrements de dérive reliant les changements de lockfile à une nouvelle révision
SOC 2 CC9.2	Le risque des logiciels tiers et fournisseurs est géré	Un dossier de divulgation à l'échelle du produit, à jour à la version

Les constats apparaissent quand une politique existe mais que la preuve opérationnelle fait défaut.

Pourquoi les certifications et la diligence des acheteurs divergent

Le périmètre de la certification, c'est l'environnement de contrôle : souvent un trust center, une période, une limite de système. Le périmètre de la diligence acheteur, c'est le produit qu'il achète (ce SKU, cette version, ces obligations aujourd'hui).

Votre rapport SOC 2 couvre la façon dont vous gérez le changement. Leur équipe juridique demande le texte de la licence MIT de libfoo 2.4.1 dans le programme d'installation qu'ils déploient. Des questions différentes ; toutes deux appellent des réponses honnêtes.

Pourquoi l'inventaire devient-il obsolète dans les organisations certifiées ?

L'inventaire devient obsolète parce que la certification est périodique, alors que les dépendances changent en continu. Le rapport Open Source Security and Risk Analysis de Black Duck a trouvé du code open source dans 96 % des bases de code auditées, et que la plupart contenaient des composants avec des conflits de licence ou sans licence identifiable, si bien qu'un seul dossier de preuves annuel ne peut pas suivre ce que chaque version livre réellement.

Les entreprises certifiées fusionnent des mises à jour de dépendances entre les cycles d'audit. Les développeurs ajoutent des paquets sans mettre à jour le tableur du dossier de preuves ISO de l'année dernière. Le certificat est valide ; l'inventaire est obsolète.

La conformité opérationnelle des licences signifie réimport à chaque version, nouvelle révision, republication. La même boucle de maintenance qu'exigent le CRA et les achats, à l'intérieur d'un SMSI qui prétend déjà que vous gérez le risque tiers.

Une preuve que les auditeurs et les acheteurs acceptent tous les deux

Un inventaire tiers révisé, rattaché aux tags de version. Le texte intégral des licences conservé avec chaque composant approuvé. Un instantané de publication ou d'export avec date et approbateur. Une détection de dérive quand les lockfiles changent. Une divulgation publique ou destinée aux clients quand les contrats l'exigent.

Le format varie (URL, export PDF, lot JSON). La preuve, c'est le dossier révisé et le processus, pas le type de fichier.

Import depuis les lockfiles ou les SBOM à chaque version.
Révision humaine avant approbation, en particulier pour le copyleft.
Journal d'audit : qui a approuvé quoi, et quand.
Exports joints aux preuves ISO ou aux demandes des auditeurs SOC.
Relancé à chaque changement de dépendances, pas seulement une fois par an.

Schémas d'échec courants dans les audits et les transactions

Une politique sans inventaire. Un inventaire sans texte intégral. Un texte intégral collecté une fois et jamais mis à jour. Une analyse de sécurité confondue avec une révision de licences. Un trust center qui mentionne la confidentialité et la sécurité, mais reste silencieux sur l'open source. De la GPL en production découverte par l'analyse de l'acheteur, pas par la vôtre.

Chaque schéma crée des constats ISO, des exceptions SOC, ou des retards de transactions. La solution est une infrastructure opérationnelle pour les obligations de licence, en parallèle des programmes de certification (sans les remplacer).

Comment les équipes relient les contrôles au travail sur les licences

Reliez le contrôle 5.32 et les critères de gestion des changements SOC à des étapes concrètes : import, révision, publication, contrôle de dérive. Nommez des responsables en ingénierie et en conformité. Joignez les exports de divulgation aux dossiers de preuves du SMSI. Échantillonnez les produits pendant l'audit interne comme le feront les auditeurs externes.

La certification prouve la maturité du processus. Les dossiers de licences au niveau du produit prouvent que vous respectez les obligations du logiciel que vous vendez. Les acheteurs et les tests d'échantillonnage ISO attendent de plus en plus les deux ensemble.

Sources

Comment SourceTrust soutient les preuves adossées à la certification

Les certifications prouvent que vous avez un système de management. Les dossiers de licences au niveau du produit prouvent ce qui a été livré : révisé, avec le texte intégral, mis à jour quand les dépendances changent.

SourceTrust importe les fichiers de paquets et les SBOM, exige une révision avant publication, et produit un dossier de divulgation maintenu par produit, plus des exports pour les dossiers de preuves ISO et les questionnaires des acheteurs. Les contrôles de dérive alignent les dossiers de licences sur les mêmes changements de dépendances que vos contrôles de gestion des changements suivent déjà pour SOC 2.

Voir comment fonctionne la plateforme

Importez depuis les dépôts, les manifestes et les SBOM. Chaque ligne est une licence à satisfaire
Des verrous de révision et de publication. Une preuve que les auditeurs peuvent échantillonner face à la production
Un dossier de divulgation par produit. Ce que demandent les acheteurs au-delà du rapport SOC
Des alertes de dérive quand les dépendances ou les licences changent entre deux cycles d'audit

SourceTrust est une infrastructure de conformité, pas un conseil juridique, et ne remplace pas votre cabinet d'audit ISO ou SOC. Il vous aide à opérationnaliser vos obligations de licence ; votre juriste et vos auditeurs restent les autorités sur la conception de vos contrôles.