SBOM as a response tool: why NIS2 requires more than just a list
In modern conditions, software supply chain security has become a critical issue for operators of critical infrastructure. According to the ENISA Threat Landscape 2025 report, 4,875 incidents were analyzed between July 1, 2024, and June 30, 2025, with 53.7% of affected organizations belonging to the category of essential entities. This transforms the Software Bill of Materials (SBOM) from a formal NIS2 requirement into an operational response tool.
The trap of static compliance
SBOM is often viewed as a static report for auditors. However, in enterprise systems, the share of third-party code often exceeds значна частина. Static lists become obsolete instantly, which complicates vulnerability control. The Cisco Cybersecurity Readiness Index 2025 emphasizes the importance of holistic security approaches, where real-time transparency of all dependencies is the key to infrastructure resilience.
Architectural transparency and integration
Effective risk management requires embedding security into the architecture. As noted in the Microsoft Azure Well-Architected principles, modeling solutions at the start is significantly cheaper than fixing issues after implementation. Similar to the FinOps methodology, where resource costs are attributed to specific business processes, the SBOM must be integrated into the system's domain model. This allows for the precise identification of those responsible for each component.
From CI/CD to runtime: integration of control
Automating CVE scanning in the CI/CD pipeline is a necessary step, but it must be complemented by a domain model that maps vulnerabilities to specific business nodes. When system components are identified and linked to business processes, the time required to detect a vulnerability is reduced from weeks to hours.
Platform approach: the role of UnityBase
For complex enterprise systems, it is advisable to use platforms where security is part of the architectural core. The UnityBase platform, developed by the Intecracy Group alliance, allows for the implementation of governance through a domain metadata mechanism. This ensures a unified security model where all data, APIs, and system behavior are clearly identified. Using UnityBase helps organizations ensure NIS2 compliance by automating audits and tracking changes in components in real time. For systems with increased security requirements or high loads, it is recommended to use the Enterprise or Defence editions of the platform.
| Maturity level | SBOM management characteristics |
|---|---|
| Level 1 (Ad-hoc) | SBOM is created only upon an auditor's request. |
| Level 2 (Reactive) | Automatic generation at release without real-time monitoring. |
| Level 3 (Integrated) | SBOM is integrated into CI/CD; vulnerabilities are mapped to components. |
| Level 4 (Architectural) | Part of the domain model; security, audit, and access are automated at the platform level. |
FAQ
How can SBOM updates be automated?
Integrate Software Composition Analysis (SCA) tools directly into the CI/CD pipeline so that the SBOM updates automatically with every build.
What are the minimum SBOM requirements set by NIS2?
NIS2 requires supply chain transparency through up-to-date component inventory lists and vulnerability monitoring.
How can vulnerabilities be linked to business processes?
Use a domain model to map components to business functions, which allows for prioritizing fixes based on service criticality.