SBOM Software Bill of Materials: Sovereign Compliance Under NIS-2 and CRA

A software bill of materials (SBOM) is a machine-readable inventory of every software component, library and dependency that makes up a given application or system, including the version, licence, supplier and known vulnerability status of each element. For European regulated organisations evaluating sovereign alternatives to Big Tech infrastructure, the SBOM has moved from a developer-facing hygiene practice to a hard compliance obligation, anchored simultaneously in the EU Cyber Resilience Act, the NIS-2 Directive and DORA.

Why Sovereign Open-Source Stacks Make SBOMs Both More Achievable and More Urgent

Deploying open-source-based platforms such as Nextcloud, Matrix or Mistral gives organisations something that proprietary SaaS cannot offer: full access to the dependency graph. With Microsoft 365 or Google Workspace, the internal component inventory is a trade secret. With open-source stacks, the entire dependency tree is inspectable, and SBOM generation tools such as Syft, Trivy or OWASP Dependency-Track can produce complete inventories automatically at build time.

The urgency arises from the same openness. Because every library in a Nextcloud installation, every Python package in a Mistral inference stack and every Go module in a Matrix Synapse deployment is publicly documented, adversaries can cross-reference a disclosed CVE against publicly known dependency patterns faster than ever before. The Synopsys Open Source Security and Risk Analysis 2024 report found that 84% of commercial codebases contained at least one open-source vulnerability. Sovereign deployments are not exempt from that statistic; they simply have the tooling available to do something about it that proprietary SaaS users do not.

What the ENISA Implementation Guide and CISA 2025 Minimum Elements Change

The ENISA SBOM Landscape Analysis and Implementation Guide, published in December 2025, establishes a tiered maturity model for SBOM implementation across EU critical sectors. It distinguishes between a basic tier (SBOM generated at release, stored by supplier), an intermediate tier (SBOM delivered to the procuring organisation and ingested into its vulnerability management tooling) and an advanced tier (continuous SBOM generation, VEX integration and automated SIEM correlation). For entities subject to NIS-2 or DORA, ENISA positions the intermediate tier as the minimum operationally justified level.

As ENISA states in that guide: “An SBOM is a key building block in software security and software supply chain risk management. Without it, organisations are effectively flying blind when a new vulnerability is disclosed.”

The CISA 2025 update to its Minimum Elements for an SBOM guidance reinforces this by adding explicit expectations around VEX status integration and by clarifying that dependency-graph depth must cover transitive dependencies, not only direct ones. CISA notes: “Minimum elements for an SBOM are a starting point, not a ceiling. Organisations in critical sectors should treat VEX status data and dependency-graph depth as operational necessities, not optional enhancements.”

ENISA’s Threat Landscape 2024 found that supply-chain attacks grew by 30% year-on-year, with the software supply chain identified as a top-three threat vector for critical infrastructure. This trajectory directly motivates the regulatory escalation visible in both the ENISA guide and the CISA update.

Choosing Between CycloneDX, SPDX and SWID for Sovereign Pipelines

Three formats dominate the SBOM landscape, and the choice has practical consequences for sovereign environments.

For the core sovereign stack, CycloneDX in JSON format is the recommended default for SIEM ingestion because all major open-source vulnerability platforms, including Dependency-Track and Grype, support it natively. SPDX is worth generating in parallel, particularly since EU Cyber Resilience Act Article 13 compliance will require licence provenance data that CycloneDX alone does not always capture in sufficient detail. SWID is relevant only where the organisation also manages a software asset register for hardware-bound applications.

SBOM Data in Incident Forensics Under NIS-2 Article 23 and DORA Article 19

NIS-2 Article 23 requires entities to notify their competent authority of a significant incident within 24 hours of detection. DORA Article 19 requires financial entities to log ICT incidents in sufficient detail to support root-cause analysis. In both cases, the speed and accuracy of that analysis depends on knowing which component version was running at the time of the incident and whether a known vulnerability in that component was a contributing factor.

IBM’s Cost of a Data Breach Report 2024 reported a global average of 194 days to identify a breach. SBOM-backed forensics reduces that window materially: when a CVE is published, a query against a current SBOM returns within seconds which deployments contain the affected package version. Without an SBOM, the same determination requires manual code review, vendor confirmation or external scanning, each of which can add days to the detection timeline.

For sovereign Nextcloud or Mistral deployments, this is operationally concrete. When a vulnerability in a Python cryptography library is disclosed, the SBOM query identifies exactly which inference endpoint is affected, which data categories were processed through it and which NIS-2 reporting thresholds apply. That is root-cause analysis of the kind Article 19 demands, completed in hours rather than weeks.

Contractual Clauses for SBOM Procurement from MSPs and Toolchain Providers

NIS-2 Article 21 explicitly requires covered entities to apply security measures across the supply chain, which the European Commission’s implementing guidance interprets to include software suppliers and managed service providers. The following clauses represent the minimum that sovereign procurement officers should include in contracts.

First, a delivery obligation: the supplier must provide a machine-readable SBOM in CycloneDX 1.5 or SPDX 2.3 format at every software release, including minor and patch releases, delivered to the procuring organisation within five business days of publication.

Second, a VEX obligation: within a defined SLA, typically 72 hours for actively exploited CVEs and ten business days for others, the supplier must issue a VEX statement for any vulnerability disclosed in a component present in the delivered SBOM, stating whether the vulnerability is exploitable in the supplied configuration.

Third, a transitive dependency obligation: the SBOM must include transitive dependencies to at least three dependency levels, covering the full scope required by CISA 2025 minimum elements.

Fourth, a data sovereignty clause: the SBOM and all associated VEX data must be stored in infrastructure under the procuring organisation’s control and must not be transmitted to or processed by systems under non-EU jurisdiction without explicit written consent.

Using VEX to Reduce Patch Workload in Restricted and Air-Gapped Deployments

A Vulnerability Exploitability eXchange (VEX) document is a structured statement, most commonly embedded in or linked from a CycloneDX SBOM, that classifies a CVE’s exploitability in a specific deployment context. The four standard VEX status values are: not affected, affected, fixed and under investigation. For sovereign environments operating in restricted or air-gapped configurations, VEX is operationally critical.

Consider a sovereign deployment of a Mistral-based private AI that includes a version of OpenSSL affected by a newly published CVE. If the deployment does not expose any network interface that reaches the vulnerable code path, the supplier or the internal security team can issue a VEX statement with status “not affected” and a justification code such as “vulnerable code not in execution path.” This allows the patch to be scheduled in the next planned maintenance window rather than treated as an emergency change, without sacrificing audit traceability. The VEX statement itself becomes evidence in any NIS-2 compliance review that the vulnerability was assessed, not ignored.

In air-gapped deployments where automatic patch advisory feeds from vendors are not available, maintaining a local VEX database fed by periodic offline synchronisation allows the security team to operate the vulnerability triage cycle independently of external connectivity. This is a design requirement for sovereign environments handling classified or legally privileged data, and it is a use case that neither proprietary SaaS nor generic cloud vulnerability scanning services can replicate.

FAQ

Does the EU Cyber Resilience Act require every organisation to produce an SBOM, or only software manufacturers?

Article 13 of the CRA places the primary SBOM obligation on manufacturers of products with digital elements sold in the EU market. However, organisations that procure, deploy or integrate such products inherit a practical obligation by needing to verify and ingest supplier SBOMs. Regulated operators under NIS-2 must additionally document their supply-chain risk under Article 21, which in practice means requiring SBOMs contractually from all software vendors.

Which SBOM format should a CISO choose for a sovereign Nextcloud or Matrix deployment?

CycloneDX is generally preferred for security-focused workflows because it natively supports VEX documents, vulnerability metadata and service dependency graphs. SPDX is better suited when licence compliance and provenance tracking are the primary concern. Most sovereign SIEM platforms can ingest both, so generating both at build time is practical and covers all downstream requirements.

How quickly must an organisation use SBOM data after a new CVE is disclosed under NIS-2 Article 23?

NIS-2 Article 23 requires significant incidents to be reported within 24 hours of detection. An accurate SBOM allows security teams to identify affected component versions within minutes of a CVE publication. This directly affects whether an organisation can demonstrate timely detection, which is a factor competent authorities consider when assessing incident handling.

What is a VEX document and how does it help in an air-gapped sovereign environment?

A VEX document is a machine-readable statement declaring whether a specific vulnerability is actually exploitable in the deployed configuration. In air-gapped environments where patch feeds may not arrive in real time, VEX documents allow accurate triage of the vulnerability backlog and permit deferral of patches for components confirmed as not affected, without waiting for external confirmation.

Can an organisation use SBOM data produced by an MSP if it hosts its own sovereign stack?

Yes, but the contractual terms must be explicit. Procurement contracts should require the MSP to deliver a machine-readable SBOM at each software release, to provide updated VEX statements within a defined SLA after a new CVE is disclosed, and to grant the procuring organisation the right to ingest and store that SBOM data in its own SIEM. Accepting a verbal assurance that software is patched is not sufficient under NIS-2 Article 21 or DORA Article 19.