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.

CISA 2026 Minimum Elements

Le SBOM est conforme aux 2026 Minimum Elements for a Software Bill of Materials de la CISA. Chaque élément requis est émis :

• Auteur, nom et version de l’outil. SPDX creationInfo.creators porte Tool: monsys.ai-<version> et Organization: GoTrust BV. CycloneDX renseigne metadata.tools (avec la version du hub en cours) et metadata.authors.
• Format de données et version. SPDX 2.3 et CycloneDX 1.5, indiqués dans l’en-tête de chaque format.
• Horodatage et version du SBOM. Horodatage RFC 3339 ; version du SBOM 1.
• Contexte de génération. Déclaré comme after-build (inventaire hôte au runtime) : phase operations dans CycloneDX metadata.lifecycles, repris dans le commentaire SPDX.
• Producteur, nom, version, identifiants, licence, relation de dépendance. Les composants OS et noyau portent le distributeur comme producteur (SPDX supplier, CycloneDX publisher) ; chaque composant a un identifiant purl ; les licences utilisent des IDs SPDX lorsque connues. CycloneDX fournit un graphe dependencies explicite enraciné sur l’hôte.
• Identification explicite des informations inconnues. Les empreintes de fichiers des composants ne sont pas collectées (monsys fait un inventaire hôte de métadonnées seules, sans accès aux artefacts) : le Component Hash est donc enregistré comme unknown plutôt qu’inventé. Le producteur est NOASSERTION là où l’éditeur est réellement inconnu.

Signature de l’auteur

Chaque SBOM est signé en ligne avec la clé Ed25519 du hub, satisfaisant l’élément CISA « SBOM Author Signature ». CycloneDX utilise son bloc signature JSF natif ; SPDX porte la signature dans une annotation au niveau du document. La signature couvre la forme canonique RFC 8785 (JCS) du document sans le porteur de signature, de sorte que quiconque peut la vérifier hors ligne avec la clé publique publiée sur /api/v1/keys (la même clé qui signe l’Audit Pack).

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.)