Audit de code source et SBOM : cartographier les composants open source de vos logiciels

Qu’est-ce qu’un audit de code source ?

Un audit de code source établit la composition réelle d’un logiciel, puis en tire les conséquences juridiques et opérationnelles. On identifie chaque composant tiers, sa version, son origine et sa licence, et on vérifie que l’usage qui en est fait respecte les obligations attachées.

L’exercice n’a rien de théorique : une application moderne embarque couramment plusieurs centaines de composants open source, dont la majorité arrive par transitivité, sans décision explicite de l’équipe.

Chez inno³, l’audit de code est un travail juridique et technique : licences, obligations déclenchées, vulnérabilités connues, fiabilité de l’inventaire. Il s’appuie sur des scanners, mais le livrable reste une analyse humaine.

Ce qu’un audit de code source n’est pas

Un audit de sécurité du code source, au sens revue applicative ou test d’intrusion, cherche les failles de votre propre code : injections, défauts d’authentification, secrets en clair. Un audit de conformité open source regarde ailleurs : ce que vous avez intégré sans l’écrire, les licences qui s’y attachent, les vulnérabilités publiées sur ces composants tiers. Aucun test d’intrusion ne produit de cartographie de licences ni de SBOM.

Ce que couvre un audit de code

Licences et compatibilités

Chaque composant arrive avec une licence, parfois plusieurs, parfois aucune. Il faut identifier la licence effective, repérer les incohérences (un en-tête de fichier qui contredit le fichier de licence du dépôt, une double licence jamais tranchée) puis vérifier la compatibilité de l’ensemble. Le point sensible reste la cohabitation entre licences à réciprocité forte et code propriétaire.

Obligations déclenchées par le mode de distribution

Les obligations d’une licence open source se déclenchent pour l’essentiel à la distribution, pas à l’usage interne. Logiciel embarqué, application en ligne, image de conteneur publiée, micrologiciel : le mode de mise à disposition change tout. L’audit établit qui distribue quoi, et en déduit les mentions, textes de licence et sources à fournir aux clientes et clients.

Composants tiers vulnérables

L’inventaire est rapproché des bases de vulnérabilités publiques, ce qui donne la liste des composants tiers vulnérables réellement présents, avec leur criticité et la version qui corrige. Une dépendance oubliée reste une vulnérabilité invisible : décembre 2021 et la question « est-ce que Log4Shell est chez nous ? » l’ont rappelé.

Qualité de l’inventaire

L’audit de qualité de code, au sens dette technique, relève d’une autre démarche. On mesure ici la qualité de l’inventaire : part des licences identifiées avec certitude, volume de code non attribué, écart entre dépendances déclarées et livrable réel. Ce taux détermine la fiabilité du SBOM.

Audit ponctuel ou audit continu

Un audit open source ponctuel photographie un produit à un instant donné. Il convient à une opération précise : cession, levée de fonds, ouverture d’un code, exigence contractuelle. Il vieillit au rythme des mises à jour de dépendances.

Un audit continu s’intègre à la chaîne de construction : chaque compilation régénère l’inventaire, les écarts à la politique interne remontent comme des anomalies, la curation se fait au fil de l’eau. C’est le mode qu’appelle un produit maintenu dans la durée.

La plupart des organisations commencent par un audit ponctuel sur un produit représentatif, puis industrialisent. Cette bascule relève de notre accompagnement Transparence de la chaîne logicielle, prolongé par une gouvernance open source.

Le SBOM, nomenclature logicielle de vos produits

Qu’est-ce que le SBOM ?

Un SBOM (software bill of materials, nomenclature logicielle) est la liste structurée et lisible par machine des composants qui constituent un logiciel : nom, version, projet d’origine, licence, identifiant, empreinte, relations. C’est la nomenclature d’un produit manufacturé transposée au logiciel : de quelles pièces il est fait, et d’où elles viennent.

Formats et identifiants

Deux formats se partagent la production réelle : SPDX, porté par la Linux Foundation, très détaillé côté licences, et CycloneDX, porté par l’OWASP, très utilisé côté sécurité. Les mêmes outils produisent l’un et l’autre.

Le champ qui décide de l’utilité du document n’est pourtant pas le format, c’est l’identifiant. Un nom de composant n’est pas comparable par une machine : libtiff et tiff désignent le même projet. Le package URL lève cette ambiguïté, et il ne s’obtient auprès d’aucun registre : il se calcule.

Pourquoi il faut le maintenir

Un SBOM produit une fois puis rangé dans un dossier perd sa valeur au premier changement de version. Il n’a d’intérêt que régénéré à chaque livraison, de façon à répondre en quelques minutes le jour d’une alerte : ce composant est-il chez nous, dans quelles versions, dans quels produits livrés ? Voir Produire et maintenir une SBOM.

Ce que le Cyber Resilience Act en exige

Le règlement (UE) 2024/2847, dit Cyber Resilience Act, demande aux fabricants de produits comportant des éléments numériques d’identifier et de documenter les vulnérabilités et les composants de leurs produits, notamment en établissant une nomenclature logicielle lisible par machine, couvrant au moins les dépendances de niveau supérieur. Ce seuil est un plancher : l’intérêt d’une nomenclature est de pouvoir conclure qu’un composant n’est pas chez vous, et cette déduction suppose un inventaire complet.

Les exigences de forme (format, champs, granularité) sont renvoyées à des actes d’exécution de la Commission, non adoptés à ce jour. Les spécifications nationales, comme la directive technique TR-03183 du BSI allemand, ne sont donc pas contraignantes en droit de l’Union, même si elles circulent dans les cahiers des charges.

Le règlement organise par ailleurs le signalement des vulnérabilités activement exploitées et des incidents graves : notification initiale sous 24 heures, rapport sous 72 heures, rapport final sous 14 jours, via la plateforme unique de signalement pilotée par l’ENISA. Sans inventaire fiable, ces délais ne sont pas tenables.

L’article 24 introduit enfin la notion d’open source steward, régime allégé pour les structures qui soutiennent des logiciels open source sans les commercialiser. Il ne dispense pas le fabricant qui les intègre dans un produit commercial de ses propres obligations. Détail dans notre analyse Cyber Resilience Act et open source.

Les situations qui déclenchent une demande d’audit

Audit de code source côté éditeur, avant cession ou levée de fonds

Une revue technique d’acquisition regarde systématiquement la composition open source du produit : une licence à réciprocité forte mal placée peut affecter la valeur de ce qui est cédé. Un audit mené par l’éditeur avant l’ouverture des discussions traite les points sensibles en amont, plutôt qu’en négociation.

Audit de code d’une application web

Une application web additionne trois couches : dépendances serveur (npm, PyPI, Maven, Composer), bibliothèques front livrées au navigateur, image de conteneur et sa distribution de base. Chacune a son gestionnaire de paquets et ses angles morts. Un audit qui ne lit que le back-end manque la plus grande partie du code distribué.

Audit de code Bootstrap et bibliothèques front

Les projets qui embarquent Bootstrap, jQuery ou un cadriciel JavaScript posent une question précise : ce qui est déclaré dans le gestionnaire de paquets correspond-il au paquet réellement livré ? Fichiers minifiés, thèmes recopiés à la main, polices et jeux d’icônes échappent souvent à l’inventaire automatique, avec des conditions distinctes de celles de la bibliothèque qui les accompagne.

Audit avant ouverture d’un code

Publier un code sous licence libre suppose de savoir ce qu’il contient. L’audit vérifie que l’organisation détient les droits sur ce qu’elle publie, que les composants intégrés sont compatibles avec la licence de sortie, et qu’aucun secret ni donnée personnelle ne traîne dans l’historique.

Comment inno³ conduit un audit de code source

• Cadrage. Quel produit, quelle version, quels dépôts, quel mode de distribution. Cette dernière question détermine les obligations à vérifier.
• Analyse automatisée. ScanCode Toolkit pour la détection de licences au niveau du fichier, OSS Review Toolkit pour les dépendances et la génération du SBOM, Fossology pour la revue de fragments. Aucun outil d’audit de code source ne rend un résultat directement exploitable : ils remontent des candidats.
• Curation. Le cœur du travail : chaque licence incertaine est tranchée, chaque composant non attribué est documenté. Hermine, notre logiciel libre de conformité, conserve ces décisions d’un audit à l’autre.
• Analyse juridique. L’inventaire curé est confronté à l’architecture réelle et au mode de distribution, pour établir obligations déclenchées et points de non-conformité.
• Restitution. Cartographie des composants et de leurs licences, analyse des compatibilités, liste des composants tiers vulnérables, plan d’actions hiérarchisé, SBOM exploitable au format retenu.

La durée dépend moins du volume de code que de la part de code non attribué à traiter en curation. Elle est estimée au cadrage. Quand la question porte sur un parc applicatif entier plutôt que sur un produit, elle relève de nos études.

La formation : construire votre propre chaîne d’audit

Cette journée s’adresse aux équipes qui veulent internaliser la démarche. Chaque concept est appliqué sur des projets réels, avec les outils open source.

Objectifs

• Choisir les bons outils d’audit de code source selon vos besoins
• Générer et analyser un SBOM pour obtenir une vision claire de la composition de vos logiciels
• Traduire les résultats techniques en analyse juridique : architecture logicielle et obligations des licences
• Intégrer l’audit dans votre cycle de développement pour une conformité continue

Programme

Questions fréquentes

Qu’est-ce qu’un SBOM, en une phrase ?

La liste structurée et lisible par machine des composants qui constituent un logiciel, avec version, origine, licence et identifiant.

Audit de code ou audit de sécurité du code source ?

Deux démarches distinctes. L’audit de sécurité applicatif cherche les failles de votre propre code. L’audit de conformité open source cartographie ce que vous avez intégré : licences, obligations, composants tiers vulnérables. Elles ne se remplacent pas.

Quel outil d’audit de code source choisir ?

ScanCode Toolkit détecte les licences au niveau du fichier, OSS Review Toolkit résout les dépendances et génère le SBOM, Fossology sert à la revue de fragments, Hermine porte la curation. Tous sont libres et complémentaires.

Combien de temps prend un audit de code source ?

La variable déterminante n’est pas le volume de code, c’est la part de code non attribué. Un produit bien outillé se traite vite, un historique accumulé sans discipline de dépendances demande beaucoup plus. Le cadrage sert à estimer cette charge.

Existe-t-il une certification du code source ?

Pas de label universel qui certifierait un code source. Existent en revanche des attestations produites à l’issue d’un audit, des schémas de certification de sécurité portant sur des produits et des processus, et, avec le CRA, une évaluation de conformité menant au marquage CE.

Ils ont suivi cette formation

EnedisINRIAOrangeConduentPreligens