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:

Laag Bron purl-voorbeeld
Applicatie-dependencies package.json, requirements.txt, composer.lock, go.sum, … pkg:npm/lodash@4.17.21
OS-pakketten laatste inventory-snapshot (apt/dpkg/rpm/dnf/apk/zypper/pacman) pkg:deb/ubuntu/openssl@3.0.13?distro=ubuntu
Draaiende kernel kernels_running pkg: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.

De SBOM voldoet aan CISA’s 2026 Minimum Elements for a Software Bill of Materials. Elk verplicht element wordt geëmitteerd:

  • Auteur, toolnaam en versie. SPDX creationInfo.creators bevat Tool: monsys.ai-<versie> en Organization: GoTrust BV. CycloneDX vult metadata.tools (met de draaiende hub-versie) en metadata.authors.
  • Dataformaat en versie. SPDX 2.3 en CycloneDX 1.5, vermeld in de header van elk formaat.
  • Timestamp en SBOM-versie. RFC 3339-timestamp; SBOM-versie 1.
  • Generatiecontext. Aangeduid als after-build (runtime host-inventaris): CycloneDX metadata.lifecycles fase operations, ook in de SPDX-comment.
  • Producent, naam, versie, identifiers, licentie, afhankelijkheidsrelatie. OS- en kernelcomponenten dragen de distributeur als producent (SPDX supplier, CycloneDX publisher); elk component heeft een purl-identifier; licenties gebruiken SPDX-IDs waar bekend. CycloneDX levert een expliciete dependencies-graaf met de host als wortel.
  • Onbekende informatie expliciet aanduiden. Component-bestandshashes worden niet verzameld (monsys doet metadata-only host-inventaris zonder toegang tot de artefacten), dus Component Hash wordt als unknown geregistreerd in plaats van verzonnen. Producent is NOASSERTION waar de uitgever echt onbekend is.

Elke SBOM wordt inline ondertekend met de Ed25519-sleutel van de hub, wat het CISA-element “SBOM Author Signature” invult. CycloneDX gebruikt zijn eigen JSF signature-blok; SPDX draagt de handtekening in een annotatie op documentniveau. De handtekening dekt de RFC 8785 (JCS) canonieke vorm van het document zonder de handtekeninghouder, zodat iedereen ze offline kan verifiëren tegen de publieke sleutel op /api/v1/keys (dezelfde sleutel die de Audit Pack ondertekent).

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.

Bewijs OpenVEX-status CycloneDX-VEX-state
Operator heeft de CVE onderdrukt (risico aanvaard / false positive) not_affected (jouw reden als impact_statement) not_affected
Kernel-fix backported / finding opgelost fixed resolved
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/mitigatie affected (met een action_statement) exploitable
Kernel-status onbekend under_investigation in_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.)