Export SBOM & VEX

Un SBOM énumère ce qui est installé. Un document VEX indique, pour chaque vulnérabilité, si vous êtes réellement affecté. monsys génère les deux par hôte, à partir de données que l’agent rapporte déjà — sans scanner supplémentaire, sans outil séparé.

C’est exactement la combinaison que réclament le Cyber Resilience Act de l’UE (CRA Annexe I §5) et les auditeurs NIS2 : l’inventaire des composants et le signal d’exploitabilité qui transforme une liste brute de CVE en liste actionnable.

SBOM complet de l’hôte

Auparavant le SBOM ne couvrait que les dépendances applicatives. Il compte désormais trois couches et représente l’hôte entier :

Couche	Source	Exemple purl
Dépendances applicatives	package.json, requirements.txt, composer.lock, go.sum, …	pkg:npm/lodash@4.17.21
Paquets OS	dernier instantané d’inventaire (apt/dpkg/rpm/dnf/apk/zypper/pacman)	pkg:deb/ubuntu/openssl@3.0.13?distro=ubuntu
Noyau en cours d’exécution	kernels_running	pkg:deb/ubuntu/linux-kernel@6.8.0-100-generic?arch=x86_64&distro=ubuntu

Les types de composants sont corrects dans les deux formats : le noyau est OPERATING-SYSTEM (SPDX primaryPackagePurpose) / operating-system (CycloneDX type), les paquets OS sont des applications/bibliothèques, les dépendances applicatives sont des bibliothèques.

Endpoints

GET /api/v1/agents/{id}/sbom?format=spdx-json        # SPDX 2.3 (par défaut)
GET /api/v1/agents/{id}/sbom?format=cyclonedx-json   # CycloneDX 1.5

Les deux renvoient un unique document JSON avec un nom de fichier Content-Disposition du type monsys-sbom-<hôte>-<date>.spdx.json.

VEX

Le document VEX est dérivé des findings CVE que le tableau de bord affiche déjà — applicatif (inventory_dependency_cves), paquets OS (os_package_cves) et le pipeline noyau conscient des backports (kernel_cve_findings) — et fondé sur les décisions de l’opérateur (cve_suppressions) ainsi que sur l’état distro/mitigation du noyau.

Comment un statut est déterminé

monsys est honnête par défaut (le principe human-in-the-loop) : une CVE qui correspond à une version installée est rapportée comme affected sauf preuve positive du contraire. Nous ne rétrogradons jamais silencieusement vers not_affected.

Preuve	Statut OpenVEX	État CycloneDX-VEX
L’opérateur a supprimé la CVE (risque accepté / faux positif)	not_affected (votre raison comme impact_statement)	not_affected
Correctif noyau backporté / finding résolu	fixed	resolved
Mitigation noyau active (p. ex. contrôle Spectre/Meltdown)	not_affected (inline_mitigations_already_exist)	not_affected (protected_at_runtime)
Installé sur une version vulnérable, sans correctif/mitigation	affected (avec un action_statement)	exploitable
État du noyau inconnu	under_investigation	in_triage

Chaque déclaration affected porte un action_statement concret (p. ex. « Mettre à niveau openssl vers 3.0.14 ou supérieur. ») ; chaque not_affected porte une justification ou un impact-statement, comme l’exigent les specs.

Endpoints

GET /api/v1/agents/{id}/vex?format=openvex          # OpenVEX 0.2.0 (par défaut)
GET /api/v1/agents/{id}/vex?format=cyclonedx-vex     # CycloneDX-VEX 1.5

Dans le tableau de bord

Ouvrez un serveur → onglet CVEs → la barre Export d’audit. Quatre téléchargements en un clic : SBOM (SPDX / CycloneDX) et VEX (OpenVEX / CycloneDX-VEX).

Dans l’Audit Pack

L’Audit Pack mensuel regroupe une ligne vex_statement par hôte et par vulnérabilité, avec exactement la même dérivation que le téléchargement ci-dessus — ainsi la preuve signée correspond à ce que vos opérateurs peuvent récupérer à la demande. Comme le reste du pack, elle est signée Ed25519 et vérifiable hors ligne.

Confidentialité & souveraineté

Tout est généré à l’intérieur du hub à partir de données que l’agent rapporte déjà. La construction du SBOM/VEX n’envoie rien à des tiers. (La correspondance CVE sous-jacente utilise OSV.dev avec uniquement des triplets (écosystème, nom, version) — voir Correspondance CVE des paquets OS.)