Ga naar inhoud

SBOM & VEX-export

Een SBOM somt op wat er geïnstalleerd is. Een VEX-document zegt, per kwetsbaarheid, of je er effectief door getroffen bent. monsys genereert allebei per host, uit gegevens die de agent al rapporteert — geen extra scanner, geen apart tool.

Dit is precies de combinatie waar de EU Cyber Resilience Act (CRA Annex I §5) en NIS2-auditoren om vragen: de componentenlijst én het exploiteerbaarheids- signaal dat een kale CVE-lijst omzet in een lijst waar je iets mee kan.

Eerder dekte de SBOM alleen applicatie-dependencies. Nu heeft ze drie lagen en representeert ze de hele host:

LaagBronpurl-voorbeeld
Applicatie-dependenciespackage.json, requirements.txt, composer.lock, go.sum, …pkg:npm/lodash@4.17.21
OS-pakkettenlaatste inventory-snapshot (apt/dpkg/rpm/dnf/apk/zypper/pacman)pkg:deb/ubuntu/openssl@3.0.13?distro=ubuntu
Draaiende kernelkernels_runningpkg:deb/ubuntu/linux-kernel@6.8.0-100-generic?arch=x86_64&distro=ubuntu

De component-types kloppen in beide formaten: de kernel is OPERATING-SYSTEM (SPDX primaryPackagePurpose) / operating-system (CycloneDX type), OS-pakketten zijn applicaties/libraries, app-deps zijn libraries.

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

Beide geven één JSON-document terug met een Content-Disposition-bestandsnaam zoals monsys-sbom-<host>-<datum>.spdx.json.

Het VEX-document wordt afgeleid uit de CVE-findings die het dashboard al toont — applicatie (inventory_dependency_cves), OS-pakketten (os_package_cves) en de backport-bewuste kernel-pipeline (kernel_cve_findings) — en gegrond op operator-beslissingen (cve_suppressions) en de distro-/mitigatie-status van de kernel.

monsys is eerlijk als standaard (het human-in-the-loop-principe): een CVE die op een geïnstalleerde versie matcht, wordt gerapporteerd als affected tenzij er positief bewijs van het tegendeel is. We zetten nooit stilzwijgend om naar not_affected.

BewijsOpenVEX-statusCycloneDX-VEX-state
Operator heeft de CVE onderdrukt (risico aanvaard / false positive)not_affected (jouw reden als impact_statement)not_affected
Kernel-fix backported / finding opgelostfixedresolved
Kernel-mitigatie actief (bv. Spectre/Meltdown-control)not_affected (inline_mitigations_already_exist)not_affected (protected_at_runtime)
Geïnstalleerd op kwetsbare versie, geen fix/mitigatieaffected (met een action_statement)exploitable
Kernel-status onbekendunder_investigationin_triage

Elke affected-statement draagt een concrete action_statement (bv. “Upgrade openssl naar 3.0.14 of hoger.”); elke not_affected draagt een justification of impact-statement, zoals de specs vereisen.

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

Open een server → tabblad CVEs → de balk Audit-export. Vier downloads met één klik: SBOM (SPDX / CycloneDX) en VEX (OpenVEX / CycloneDX-VEX).

De maandelijkse Audit Pack bundelt per host per kwetsbaarheid een vex_statement-regel, met exact dezelfde afleiding als de download hierboven — zo komt het ondertekende bewijs overeen met wat je operators op aanvraag kunnen ophalen. Net als de rest van de pack is ze Ed25519-ondertekend en offline verifieerbaar.

Alles wordt binnen de hub gegenereerd uit gegevens die de agent al rapporteert. Het opbouwen van de SBOM/VEX stuurt niets naar derden. (De onderliggende CVE-matching gebruikt OSV.dev met enkel (ecosystem, naam, versie)-triples — zie OS-package CVE-matching.)