OS, logiciels, IA : chaque couche de votre SI a ses propres menaces et ses propres outils. Guide pratique pour DSI de PME/ETI — des CVE classiques au SBOM for AI.
La sécurité d’un système d’information ne se gère pas en bloc. Elle se lit par couches. Pourtant, la plupart des PME et ETI abordent le sujet comme un tout indifférencié — un scan de vulnérabilités par-ci, un antivirus par-là — sans jamais avoir une vision structurée de ce qu’elles exposent réellement.
Le problème : chaque couche de votre SI a ses propres menaces, ses propres outils de détection, et son propre niveau de maturité en matière de couverture. Confondre les couches, c’est garantir des angles morts.
Cet article pose le cadre : trois couches, trois approches, trois niveaux de maturité. Et un prérequis commun qui conditionne tout le reste.
CPE identifiers
NVD NIST
Mature
GHSA · OSV
En cours
7 clusters
AVID · NVD AI
Naissant
Pourquoi raisonner par couche ?
Un système d’information ressemble à un millefeuille. En surface, des applications et des interfaces. En dessous, des runtimes, des librairies, des dépendances. Plus bas encore, un système d’exploitation, du firmware, du matériel. Et depuis peu, une nouvelle couche s’est ajoutée au-dessus de tout ça : les composants d’intelligence artificielle — modèles, datasets, pipelines RAG.
Chaque couche a ses propres caractéristiques :
| Couche | Composants | Méthode de détection | Maturité outillage |
|---|---|---|---|
| OS / Infrastructure | OS, firmware, produits installés | Scanner CPE → NVD/CVE | Mature |
| Logicielle | Runtimes, libs, dépendances | SBOM + grype → NVD / GHSA / OSV | En cours de standardisation |
| IA | Modèles, datasets, pipelines | SBOM for AI → AVID, NVD (en cours) | Naissant |
Raisonner par couche, c’est s’assurer que les bons outils couvrent le bon périmètre — et qu’aucune zone n’est laissée sans surveillance.
NVD : un référentiel transversal, pas seulement pour l’OS
C’est un point souvent mal compris : la base NVD (National Vulnerability Database) du NIST publie des CVE pour toutes les couches — OS, librairies, frameworks, applications. Ce qui change entre les couches, ce n’est pas le référentiel, c’est la méthode pour savoir si vous êtes concerné.
Une part croissante des CVE NVD concerne des librairies open source — npm, PyPI, Maven, RubyGems — c’est-à-dire exactement le territoire du SBOM. Log4Shell (CVE-2021-44228) est un CVE NVD… sur une librairie Java. Les vulnérabilités Pillow ou lxml sont des CVE NVD… sur des packages Python.
Pour distinguer un CVE “produit OS” d’un CVE “librairie SBOM”, deux marqueurs fiables existent dans la structure NVD :
- Le CPE type :
cpe:2.3:o:= OS,cpe:2.3:a:= application (librairies incluses) - Le PURL (Package URL) : depuis 2023, NVD enrichit ses CVE avec des identifiants d’écosystème explicites —
pkg:pypi/pillow@11.3.0,pkg:npm/lodash@4.17.20,pkg:maven/.../log4j-core@2.14.1. Si un CVE a un PURL, c’est une librairie, sans ambiguïté.
La base OSV.dev (Google Open Source Vulnerabilities) va encore plus loin : elle ne référence que des vulnérabilités de librairies open source, avec des tags écosystème explicites. C’est la source qu’interroge grype en priorité pour les packages — et la preuve que les CVE librairies sont suffisamment nombreuses pour justifier une base dédiée.
Couche 1 — OS et infrastructure : le territoire des CVE classiques
C’est la couche la plus ancienne et la mieux couverte. Elle regroupe tout ce qui tourne “sous” vos applications : les systèmes d’exploitation (Windows, Linux, macOS), les hyperviseurs, le firmware des équipements réseau, et tous les produits installés au sens commercial du terme — au sens CPE (Common Platform Enumeration).
Comment les vulnérabilités sont-elles identifiées ?
Chaque produit installé est référencé dans la base NVD (National Vulnerability Database) du NIST via son identifiant CPE. Quand une faille est découverte, elle reçoit un identifiant CVE et un score CVSS qui quantifie sa gravité de 0 à 10.
Les outils de cette couche :
- Qualys / Tenable Nessus / OpenVAS : scanners de vulnérabilités qui interrogent la NVD et remontent les CVE détectées sur vos systèmes
- Microsoft WSUS / SCCM : gestion des patchs Windows
- Wazuh / OpenSCAP : conformité et détection en continu
Ce que cette couche ne couvre pas : les librairies tierces embarquées dans vos applications, les dépendances npm ou pip de vos développements internes, et encore moins les modèles d’IA que vous déployez.
Couche 2 — Logiciel et dépendances : le territoire des SBOM
C’est la couche qui a le plus évolué ces trois dernières années. Elle couvre tout ce qui se trouve “dans” vos applications : les runtimes (Node.js, Python, Java), les librairies open source, les frameworks, et surtout les dépendances de dépendances — ce qu’on appelle les dépendances transitives.
C’est ici que résident les risques les plus insidieux. Log4Shell en 2021 a été le révélateur : une vulnérabilité critique dans une librairie Java (log4j) utilisée par des milliers d’applications, souvent sans que les équipes sachent qu’elle était présente.
L’outil central : le SBOM
Un SBOM (Software Bill of Materials) est une liste exhaustive et structurée de tous les composants logiciels d’une application, avec leurs versions et leurs relations de dépendance. Les deux formats standards sont :
- CycloneDX (JSON/XML) — porté par OWASP, très bien supporté par les outils modernes
- SPDX (JSON/tag-value) — standard Linux Foundation, plus orienté conformité légale
La chaîne d’outils :
- syft / cdxgen : génèrent un SBOM à partir d’un répertoire, d’une image Docker ou d’un package
- grype : scanne un SBOM et croise les composants avec NVD, GHSA et OSV.dev — il identifie automatiquement les CVE librairies via les PURL
- Dependency-Track (OWASP) : plateforme web qui ingère vos SBOMs, surveille en continu les nouvelles vulnérabilités et envoie des alertes
- OSV.dev : base Google dédiée aux librairies open source, interrogeable par écosystème (PyPI, npm, Maven, Go, Rust…)
Ce que cette couche ne couvre pas : les modèles d’IA, les datasets d’entraînement, les pipelines RAG — tout ce qui constitue la couche IA de votre SI.
Couche 3 — IA et modèles : le territoire du SBOM for AI
C’est la couche émergente. Et c’est celle qui va poser le plus de défis aux DSI dans les prochaines années. En mai 2026, le G7 Cybersecurity Working Group — réunissant BSI (Allemagne), ANSSI (France), CISA (États-Unis), NCSC (Royaume-Uni) et leurs homologues — a publié le premier référentiel commun : les éléments minimaux d’un SBOM for AI.
Pourquoi l’IA mérite sa propre couche ?
Un système d’IA n’est pas qu’un logiciel. Il embarque des composants qui n’existent pas dans un SBOM classique :
- Des modèles avec leurs poids, leur architecture, leur lineage (de quel modèle parent sont-ils issus ?)
- Des datasets d’entraînement avec leur provenance, leur sensibilité (données PII ?)
- Des pipelines complexes — RAG, agents, embeddings — avec leurs flux de données
- Des dépendances à des APIs externes (OpenAI, Anthropic, Mistral) sur lesquelles vous n’avez pas la main
Les 7 clusters du SBOM for AI (G7, 2026) :
| Cluster | Ce qu’il documente |
|---|---|
| Metadata | Auteur du SBOM, version, format, signature numérique, timestamp |
| System Level Properties | Architecture globale du système IA, flux de données, inputs/outputs |
| Models | Nom, version, hash des poids, architecture, propriétés d’entraînement, licence |
| Datasets Properties | Provenance des données, sensibilité, méthodes de collecte, licence |
| Infrastructure | Dépendances logicielles et matérielles (lien vers HBOM) |
| Security Properties | Contrôles implémentés, conformité, référencement des vulnérabilités connues |
| KPI | Métriques de robustesse, uptime, latence, résistance aux manipulations |
L’outillage est encore naissant : cdxgen commence à supporter les composants IA, Dependency-Track évolue pour ingérer des SBOMs for AI. Le référentiel G7 ne crée pas d’obligation légale — mais il pose les bases de ce qui deviendra probablement une exigence réglementaire (AI Act, NIS2) dans les années qui viennent.
La cartographie des composants : prérequis de tout
Les trois couches ont un point commun absolu : sans inventaire précis, aucun outil ne peut couvrir les angles morts.
C’est la leçon que tirent toutes les organisations après un incident. On découvre après coup qu’un serveur n’était pas scanné, qu’une librairie n’était pas dans le SBOM, qu’un modèle d’IA avait été déployé sans être documenté.
La cartographie n’est pas un projet ponctuel. C’est un processus continu :
- Couche OS : inventaire des assets (CMDB) couplé au scanner de vulnérabilités
- Couche logicielle : SBOM régénéré à chaque build, versionné, envoyé à Dependency-Track
- Couche IA : registre des modèles déployés, des APIs appelées, des sources de données utilisées
Les couches sont interdépendantes : un exemple concret
Le 13 mai 2026, un scan grype sur un environnement de développement standard révèle :
- Pillow 11.3.0 (librairie Python d’image) → 6 CVE dont 3 High (fix : 12.2.0)
- lxml 6.0.2 (parser XML Python) → 1 CVE High (fix : 6.1.0)
- log4j-core 2.25.2 (dans Structurizr CLI via Java) → 4 CVE Medium
Ces vulnérabilités sont dans la couche logicielle. Mais si Pillow est utilisé pour prétraiter des images avant de les envoyer à un modèle de vision, une exploitation de cette CVE peut compromettre l’intégrité des données injectées dans le pipeline IA — et donc potentiellement biaiser ou manipuler les outputs du modèle.
La frontière entre les couches est poreuse. Une faille dans la couche 2 peut remonter jusqu’à la couche 3.
Par où commencer en PME/ETI ?
La bonne nouvelle : vous n’avez pas à tout faire en même temps. La progression logique :
Étape 1 — Couche OS (semaines 1-4)
Déployer un scanner de vulnérabilités open source (Wazuh, OpenVAS) sur vos serveurs. Identifier les CVE critiques non patchées. Mettre en place un process de patch management.
Étape 2 — Couche logicielle (mois 2-3)
Générer un premier SBOM de vos applications critiques avec cdxgen ou syft. Brancher grype pour un premier scan. Déployer Dependency-Track en Docker pour la surveillance continue.
Étape 3 — Couche IA (mois 4+)
Faire l’inventaire de vos usages IA : quels modèles, quelles APIs, quels datasets ? Documenter selon les clusters G7. Surveiller les publications des fournisseurs (OpenAI, Mistral…) sur leurs vulnérabilités connues.
Conclusion
La sécurité d’un SI n’est pas monolithique. Elle se lit en couches — chacune avec ses menaces, ses outils, son niveau de maturité. L’OS est couvert par les CVE classiques depuis des décennies. La couche logicielle est en train de se structurer autour des SBOM. La couche IA vient d’obtenir son premier référentiel international avec le G7 de mai 2026.
Ce qui ne change pas entre les trois couches : la cartographie des composants est le prérequis de tout. Sans inventaire, pas de couverture. Avec un inventaire à jour, les outils font le reste.
La question n’est plus “est-ce que je suis exposé ?” — vous l’êtes. La question est “est-ce que je sais sur quoi ?”