The SolarWinds incident of 2020 changed the way the cybersecurity industry perceives software supply chain risk. Attackers took control of the update mechanism for the Orion platform and delivered malicious code to thousands of organisations — without any interaction on the part of the victims. Similarly, the Log4Shell vulnerability (CVE-2021-44228) demonstrated that a critical flaw in a single open source library can affect hundreds of millions of applications worldwide. In both cases, organisations had no idea what their software actually contained.
Software Bill of Materials, abbreviated as SBOM, is the answer to this problem. It is a formal, structured inventory of the components, libraries, and dependencies that make up a piece of software — analogous to the list of ingredients on a food product’s packaging. SBOM is not a theoretical novelty: in May 2021, President Biden signed Executive Order 14028 requiring software vendors supplying the US government to provide an SBOM. A year later, equivalent requirements began appearing in European regulations. Today, SBOM is becoming a sine qua non condition of supply chain security.
What is SBOM (Software Bill of Materials) and why is it becoming a requirement?
SBOM is a formal document describing a complete list of software components: external libraries, transitive dependencies, internal modules, and their metadata — versions, licences, suppliers, cryptographic hashes, and associated vulnerabilities. The National Institute of Standards and Technology (NIST) defines SBOM as “a formal record containing the details and supply chain relationships of various components used in building software”.
The key characteristic of SBOM is the ability to automatically correlate with vulnerability databases such as the National Vulnerability Database (NVD) or OSV (Open Source Vulnerabilities). When a new CVE appears, an organisation with an up-to-date SBOM is able to answer the question within minutes: “Are we using this component, in which version, and in which systems?” Without an SBOM, the answer to that question can take days — or be impossible to obtain.
Why does this matter now? According to the Synopsys Open Source Security and Risk Analysis 2024 report, the vast majority of scanned codebases contain open source components, and 84% contain at least one known vulnerability. The average enterprise application relies on hundreds of external dependencies, many of which are transitive dependencies — invisible without the right tooling.
The growing importance of SBOM stems from several parallel trends. First, the dominance of open source in software development means that internal code constitutes an ever-smaller proportion of the whole — most business logic is implemented through external libraries. Second, the complexity of dependency chains keeps growing: a library imports another library, which imports yet another. Third, the time between vulnerability disclosure and exploitation has dropped sharply — as Threat Intelligence analyses show, it is now measured in days. Organisations that do not know what is in their software cannot respond quickly enough.
SBOM answers three fundamental questions: What do we have installed? Which versions? Does any component have known vulnerabilities? These are seemingly simple questions, but in production environments with hundreds of applications and thousands of microservices they remain unanswered without automation.
📚 Read the complete guide: AI Security: AI in cybersecurity - threats, defense, the future
Which regulations require SBOM — Cyber Resilience Act, NIS2, executive orders?
The most important piece of legislation directly requiring SBOM is Executive Order 14028 (May 2021, USA), which instructed government agencies to demand SBOM from software vendors and tasked NIST with developing minimum requirements. NIST published the document “The Minimum Elements For a Software Bill of Materials” in 2021, specifying required data fields and exchange formats. EO 14028 has a direct impact on European companies selling software to US federal government institutions.
Cyber Resilience Act (CRA) — the EU regulation entering into force in stages from 2027 — does not explicitly require SBOM, but it places on manufacturers the obligation to document components and dependencies, manage vulnerabilities throughout the entire product lifecycle, and notify ENISA of actively exploited vulnerabilities. Article 13 of the CRA imposes an obligation to identify and manage “vulnerabilities in the product with digital elements, including software dependencies” — which in practice means the need to implement SBOM or an equivalent mechanism. Penalties for violating the CRA can reach 15 million euros or 2.5% of global turnover.
NIS2 and SBOM: The NIS2 Directive does not require SBOM directly, but its requirements on supply chain risk management (Art. 21, para. 2, lit. d) and incident response capabilities de facto compel knowledge of software components. ENISA’s NIS2 guidelines identify SBOM as a good practice for vendor risk management.
DORA (Digital Operational Resilience Act) for the financial sector, applicable from January 2025, requires detailed management of third-party ICT risk. Financial institutions subject to DORA must understand the technological risk of their vendors — which is difficult to achieve without SBOM. The European Banking Authority (EBA) in its technical standards for DORA points to the need to monitor vulnerabilities in software supplied by external vendors.
Beyond regulation, SBOM is becoming a contractual requirement. Large corporations and public institutions are increasingly including the obligation to supply an SBOM in software procurement contracts. CISA (Cybersecurity and Infrastructure Security Agency) in the USA has published a guide for software purchasers on how to request and verify SBOM. In Poland, GovTech Polska is working on implementing equivalent requirements in public procurement for software.
The healthcare sector has its own requirements: the FDA in the United States has required SBOM for medical device software since 2023, and equivalent MDR/IVDR requirements are emerging in the European Union. Similar trends are visible in the aviation sector (DO-178C and related standards) and in industrial environments (IEC 62443).
What does SBOM look like in practice — SPDX and CycloneDX formats?
Two formats dominate the SBOM ecosystem: SPDX (Software Package Data Exchange) and CycloneDX. Both are open standards supported by the main market tooling, but they differ in approach and scope of application.
SPDX (ISO/IEC 5962:2021) is a standard developed by the Linux Foundation, originally focused on licence management. Specification version 2.3 defines fields: SPDXID, PackageName, PackageVersion, PackageDownloadLocation, FilesAnalyzed, PackageChecksum, PackageLicenseConcluded, and PackageLicenseDeclared. SPDX supports multiple serialisations: tag-value, JSON, YAML, XML, and RDF. SPDX 3.0, released in 2024, introduces a profile-based model, enabling extension beyond licence management into security, AI, and other domains. SPDX is particularly well-suited to organisations with stringent licence compliance requirements.
CycloneDX (an OWASP project, currently version 1.6) is designed primarily with security in mind. CycloneDX 1.6 defines not only software components but also HBOM (Hardware Bill of Materials), MBOM (Manufacturing BoM), OBOM (Operations BoM), and SaaSBOM for cloud services. CycloneDX introduces the concepts of vulnerability disclosure report (VDR) and vulnerability exploitability exchange (VEX) — allowing manufacturers to communicate which CVEs apply to their product and which do not (and why). The CycloneDX JSON format is more concise than SPDX and more broadly supported by DevSecOps tooling.
SPDX or CycloneDX? For an organisation focused on security and integration with a DevSecOps pipeline: CycloneDX. For an organisation with extensive open source licence requirements or supplying software to US government institutions: SPDX. In practice, many tools support both formats, and CISA recommends that purchasers accept both.
A minimal example SBOM fragment in CycloneDX JSON format for a hypothetical Java application illustrates the structure:
{
"bomFormat": "CycloneDX",
"specVersion": "1.6",
"serialNumber": "urn:uuid:...",
"version": 1,
"metadata": {
"timestamp": "2026-01-15T10:00:00Z",
"component": {
"type": "application",
"name": "example-service",
"version": "2.4.1"
}
},
"components": [
{
"type": "library",
"name": "log4j-core",
"version": "2.17.2",
"purl": "pkg:maven/org.apache.logging.log4j/log4j-core@2.17.2",
"hashes": [
{
"alg": "SHA-256",
"content": "a00a54e3fb8cb83fab38f8714f240ecc13ab..."
}
]
}
]
}The key field is purl (Package URL, specification at github.com/package-url), which serves as a unique identifier for a component independent of the package manager. PURL enables correlation with external vulnerability databases: pkg:maven/org.apache.logging.log4j/log4j-core@2.17.2 unambiguously identifies a specific version of Log4j, which can then be looked up in NVD, OSV, or Sonatype OSS Index.
Both SPDX and CycloneDX support the representation of transitive dependencies, which is critical for a complete view of risk. The dependsOn relationship in SPDX and dependencies in CycloneDX allow for modelling the dependency graph — not just a flat list of components.
How to generate SBOM for your own product — tools and processes?
Generating an SBOM for existing applications can be done at several levels: analysis of manifest files (package.json, pom.xml, requirements.txt), source code analysis, binary analysis, or through introspection of a running system. Each approach has different completeness and accuracy characteristics.
Syft (Anchore) is probably the most popular open source tool for SBOM generation. It supports many package ecosystems, scans Docker/OCI container images, filesystems, and archives. Installation and usage are straightforward:
# Installation
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
# Generate SBOM for a Docker image
syft nginx:latest -o cyclonedx-json=nginx-sbom.json
# Generate SBOM for a project directory
syft dir:./myapp -o spdx-json=myapp-sbom.spdx.json
# Generate SBOM for a binary
syft binary:./myapp-binary -o cyclonedx-json=myapp-binary-sbom.jsonSyft detects packages installed by package managers (npm, pip, maven, gradle, cargo, go modules, and many others), but it does not analyse source code for direct library calls. For source code analysis it is worth complementing Syft with tools such as cdxgen (OWASP) or Trivy (Aqua Security).
cdxgen is particularly valuable for JVM-based projects, because it analyses bytecode and resolves transitive dependencies with greater accuracy than manifest analysis:
# Installation
npm install -g @cyclonedx/cdxgen
# Generate SBOM for a Java/Maven project
cdxgen -t java -o bom.json ./myapp
# Generate SBOM for a multi-language project
cdxgen --multi-project -o bom.json .Trivy (Aqua Security) combines SBOM generation with vulnerability scanning in a single tool:
# Generate SBOM and scan for vulnerabilities simultaneously
trivy image --format cyclonedx --output sbom.json nginx:latest
# Scan for vulnerabilities from an existing SBOM
trivy sbom sbom.jsonSBOM completeness: No tool generates a fully complete SBOM automatically. Dynamically loaded resources, system dependencies not covered by manifests, custom C/C++ code compiled from source — these are typical gaps in automatically generated SBOMs. NTIA (National Telecommunications and Information Administration) defines a “minimum SBOM” as a document containing 7 basic fields for each component: supplier, name, version, other unique identifiers, dependency relationships, SBOM author, and timestamp.
For projects based on Docker containers it is worth generating SBOM at the image layer level, not only at the application level. The docker sbom command (an experimental Docker CLI extension) or Syft with the --source-name option enables SBOM generation that includes system packages from the base image layer (e.g. debian:bookworm-slim).
An important consideration is the timing of SBOM generation. The most valuable SBOM is one generated at the moment of artefact build (build-time SBOM), cryptographically signed, and stored together with the artefact. Sigstore/cosign signatures allow embedding the SBOM as an attestation in an OCI registry, ensuring the integrity and immutability of the document.
How to use SBOM to manage vulnerabilities in open source components?
Having an SBOM is only half the solution — the key value comes from automatic correlation with vulnerability databases and response processes. A vulnerability management architecture based on SBOM consists of several layers.
The first layer is SBOM ingestion and parsing. Tools such as OWASP Dependency-Track (open source, recommended by OWASP) or commercial platforms like Snyk, Mend.io (formerly WhiteSource), or Black Duck import SBOMs and build an internal component database. Dependency-Track supports CycloneDX natively and integrates with multiple threat intelligence sources.
The second layer is correlation with CVE databases. Dependency-Track uses NVD, the GitHub Advisory Database, OSV, and Sonatype OSS Index to identify known vulnerabilities. The key mechanism is VEX (Vulnerability Exploitability eXchange) — a document format (supported by CycloneDX 1.4+) that allows a software manufacturer to communicate the status of a vulnerability: “affected”, “not_affected”, “fixed”, or “under_investigation”. VEX eliminates false positives: a CVE may be officially assigned to a library, but a given product may use that library in a configuration that is not vulnerable (e.g. the vulnerable code path is never invoked).
Log4Shell analysis through the lens of SBOM: CVE-2021-44228 (Log4Shell) affected the log4j-core library in versions 2.0-beta9 through 2.14.1. Organisations with an up-to-date SBOM were able to run a query within hours: “Show me all applications that contain log4j-core in a vulnerable version.” Without SBOM, the same analysis took weeks in many organisations — if it could be carried out with satisfying completeness at all.
The third layer is prioritisation and triage. Not all CVEs require immediate action. The SSVC (Stakeholder-Specific Vulnerability Categorization) framework developed by CISA and Carnegie Mellon University enables remediation decisions based on several criteria: whether a public exploit is available, whether the vulnerability is being actively exploited, whether the component is internet-facing or internal-only, and what the potential impact on the organisation’s mission is. EPSS (Exploit Prediction Scoring System) provides a probabilistic assessment of the likelihood of exploitation within 30 days.
The fourth layer is tracking and remediation workflow. Dependency-Track integrates with ticketing systems (Jira, ServiceNow) and sends notifications to the appropriate teams. It is important to map each component to an application and each application to a responsible team — without this information, vulnerability notifications fall into a void.
The fifth layer is metrics and SLAs. Mature organisations define vulnerability management metrics: Mean Time to Remediate (MTTR) by severity, percentage of components with critical vulnerabilities, “age” of unresolved vulnerabilities, and SBOM coverage (what percentage of applications have an up-to-date SBOM). Without measuring progress it is hard to demonstrate security improvement.
How to require SBOM from software vendors?
Demanding SBOM from vendors requires incorporating this requirement at the contracting stage, but also understanding what can realistically be enforced. Not all organisations are equally advanced in SBOM maturity — and overly stringent requirements may limit the number of qualifying vendors.
The basic contractual requirement should cover: SBOM format (CycloneDX 1.4+ or SPDX 2.3+), delivery timing (with every new release and every security update), level of completeness (direct and transitive components to a defined depth), integrity verification mechanism (cryptographic signature), and the time to deliver an updated SBOM after a CVE is disclosed (e.g. 5 business days for critical vulnerabilities).
CISA has published the “Software Acquisition and Practices” (SWAP) document with specific language to be incorporated into software procurement contracts. Key clauses relate to: the obligation to provide SBOM in machine-readable form, updating SBOM with every change in components, supplying VEX for significant CVEs, and notification within 72 hours of critical vulnerabilities in the delivered software.
Practical approach for smaller vendors: Organisations commissioning software from small companies or from firms building custom software can require SBOM as part of the technical project documentation. It is worth specifying a concrete tool (e.g. Syft or cdxgen) and output format, in order to lower the implementation barrier for the vendor.
Verifying an SBOM after delivery is just as important as the initial request. Mature organisations verify: SBOM completeness (comparison with binary analysis), currency (generation timestamp close to the release), integrity (signature verification), and component coverage relative to known dependencies (e.g. by comparing with an independent Trivy scan). Tools such as bomctl (OpenSSF) help manage SBOMs from multiple vendors.
It is also worth considering requesting VEX alongside the SBOM — especially for high-criticality software. VEX documents the status of each vulnerability referenced by the SBOM: whether it is vulnerable, fixed, not applicable, and why. Without VEX the organisation must independently analyse every CVE from NVD, which generates significant operational costs.
How to integrate SBOM with the CI/CD pipeline?
Integrating SBOM with the CI/CD (Continuous Integration / Continuous Deployment) pipeline is the moment of transition from reactive to proactive supply chain security management. The goal is “shift-left security” — detecting problems as early as possible in the development cycle.
A typical workflow for a containerised project in GitHub Actions looks as follows:
# .github/workflows/sbom.yml
name: SBOM Generation and Security Scan
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
sbom:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build Docker image
run: docker build -t myapp:${{ github.sha }} .
- name: Generate SBOM with Syft
uses: anchore/sbom-action@v0
with:
image: myapp:${{ github.sha }}
format: cyclonedx-json
output-file: sbom.cdx.json
- name: Scan SBOM for vulnerabilities with Grype
uses: anchore/scan-action@v3
with:
sbom: sbom.cdx.json
fail-build: true
severity-cutoff: critical
- name: Sign and attest SBOM with Cosign
uses: sigstore/cosign-installer@v3
...
- name: Upload SBOM as artifact
uses: actions/upload-artifact@v4
with:
name: sbom
path: sbom.cdx.json
- name: Upload SBOM to Dependency-Track
run: |
curl -X PUT https://dependency-track.company.internal/api/v1/bom \
-H "X-Api-Key: ${{ secrets.DT_API_KEY }}" \
-F "autoCreate=true" \
-F "projectName=myapp" \
-F "projectVersion=${{ github.sha }}" \
-F "bom=@sbom.cdx.json"Key design decisions when integrating SBOM with CI/CD are: when to block the pipeline (fail-build), which severity thresholds to apply (typically Critical or High+Critical for the main branch), and how to handle false positives and exceptions.
Policy as Code is an approach in which SBOM acceptance rules are defined declaratively. OPA (Open Policy Agent) with the Rego language enables writing policies such as “reject the build if the SBOM contains components with CVSS >= 9.0 and a publicly available exploit” or “reject if the SBOM contains GPL-3.0 licences in a commercial project”. Grype natively supports integration with OPA.
The challenge of transitive dependencies in CI/CD: Full analysis of transitive dependencies can significantly extend pipeline runtime. A practical compromise is to generate a “shallow SBOM” (direct dependencies + 1 level of transitives) on every PR, and a full SBOM (all transitive layers) when merging to main or when creating a release.
Supply Chain Levels for Software Artifacts (SLSA) defines maturity levels for the provenance of software artefacts. SBOM as a build attestation is part of the requirements for SLSA Level 2 and 3. Tekton Chains (Kubernetes-native) and GitHub Actions Artifact Attestations automate the creation and verification of SLSA provenance, including SBOM.
In GitOps environments (ArgoCD, Flux) it is worth configuring SBOM verification policies at deployment time: before pulling an image into the production environment, the cosign signature and SBOM attestation are verified, and the SBOM is then analysed against currently known vulnerabilities. This provides an additional “security gate” independent of the one in CI.
What challenges do organisations encounter when implementing SBOM?
Implementing SBOM in an organisation is not just a matter of choosing a tool. It is a change in processes, culture, and responsibilities that touches many teams simultaneously. Organisations implementing SBOM regularly encounter several categories of challenges.
Completeness and accuracy is the first challenge. Automatically generated SBOMs often miss components loaded dynamically (e.g. via Java reflection), resources fetched at runtime, compiled native code without standard package metadata, and system dependencies not present in application manifests. Verifying SBOM completeness by comparing it against an independent binary analysis (e.g. via Trivy or commercial SCA scanners) is labour-intensive but necessary for critical applications.
Scale and maintenance is the next challenge. An organisation with hundreds of applications generates thousands of SBOMs, which quickly become outdated. Every rebuild, every dependency update, every patch causes the SBOM to change. Without automation in CI/CD, keeping SBOMs up to date becomes impossible to sustain. But even with automation: who is responsible for ensuring the SBOM is generated? Who is accountable for remediating vulnerabilities discovered through SBOM analysis? Without clear ownership, SBOM tooling generates artefacts that nobody uses.
False positives lead to alert fatigue. SBOM analysis tools can generate dozens or hundreds of alerts per day, many of which concern vulnerabilities that are not exploitable in the given context. Without VEX and triage mechanisms, alerts stop being taken seriously. Building triage processes and maintaining a list of accepted exceptions (with justification and an expiry date for each exception) is necessary but operationally demanding work.
The legacy challenge: Older applications — particularly those built without modern package managers or containing manually copied libraries (“vendor” or “lib” directories) — are the hardest case for automatic SBOM generation. Binary analysis tools (e.g. Fossology, Black Duck Binary Analysis) can help, but they require significant resources and expertise.
Managing SBOMs from external vendors creates its own set of problems. Vendors deliver SBOMs in different formats, different specification versions, and with varying levels of completeness. Normalising, validating, and importing SBOMs from external vendors requires dedicated tooling (e.g. bomctl, Dependency-Track). Many organisations are not prepared to ingest and analyse hundreds of SBOMs from their vendor base.
Legal aspects and trade secrets are an often underestimated challenge. An SBOM reveals the internal architecture of software and the list of components used — information that some vendors treat as a trade secret. In the context of commercial products it is worth considering “SBOM without disclosure” mechanisms (e.g. providing access only in an escrow environment or through a security gateway), although this reduces the operational utility of the document.
Organisational challenges are often more serious than technical ones: who funds the SBOM platform (security or engineering?), how to measure the success of the SBOM programme, how to translate findings into priorities for development teams. Without executive support, SBOM programmes often end up as pilots that never leave the security department.
What does SBOM management maturity look like?
An SBOM management maturity model allows organisations to assess their current level of advancement and plan the direction of programme development. The following model is based on the work of NTIA, CISA, and the OWASP CycloneDX Maturity Model.
| Level | Practices | Tools | Governance | Metrics |
|---|---|---|---|---|
| 0 — No awareness | No SBOM. Components unknown or documented manually in Excel. | No SCA tools. Vulnerabilities detected ad hoc. | No policy. Responsibility for components undefined. | No metrics. |
| 1 — Pilot | SBOM generated for selected applications manually or in CI/CD for selected projects. Coverage <30% of portfolio. | Syft / Trivy / cdxgen deployed per project. Dependency-Track or Snyk in pilot. | Policy in development. Programme owner designated. | Number of applications with SBOM. Number of CVEs identified. |
| 2 — Standardisation | SBOM generated automatically for all new applications in CI/CD. Format and tools unified. Coverage >60% of portfolio. First SBOM requirements from vendors. | Dependency-Track or commercial platform (Snyk/Mend). Integration with ticketing (Jira). Fail-build policies for criticals. | SBOM policy approved. Roles and responsibilities defined. Formal triage process. | MTTR per severity. SBOM coverage (%). Number of false positives. |
| 3 — Managed | SBOM for 100% of portfolio, including legacy applications. SBOM signed and attested (Sigstore/cosign). VEX generated for products. SBOM required in vendor contracts. | SLSA Level 2+. OPA / policy-as-code. Automated verification of vendor SBOMs. Integration with CMDB. | Remediation SLAs defined contractually. Quarterly SBOM audit. Exception programme with expiry dates. | SLA compliance (%). MTTR vs SLA. VEX coverage. Component portfolio risk (trend). |
| 4 — Optimising | Continuous SBOM validation at runtime (Kubernetes admission controller). Proactive monitoring for new CVEs. Automatic rebase to secure component versions (Renovate/Dependabot). SBOM as an element of threat modelling. | Supply chain risk scoring (e.g. OpenSSF Scorecard). Automated PRs with updates. Runtime SBOM (eBPF-based). | SBOM requirements in procurement harmonised with regulations (CRA, DORA). Mature vendor risk management programme. | Time-to-awareness for new CVEs (target: <1h). Component portfolio age. Vendor SBOM compliance rate. |
The maturity model helps avoid the “all or nothing” trap. Organisations often begin at level 1 for a handful of critical applications, validate processes and tools, and then scale the programme. Moving from level 0 to level 2 typically takes 6–12 months for an average organisation — with adequate resource commitment.
How does nFlo help organisations implement SBOM management?
nFlo works with more than 200 clients and has delivered over 500 cybersecurity projects, which has given us a perspective on different maturity models and different approaches to SBOM implementations. 98% of nFlo’s clients remain with us long-term — because we know that security is a programme, not a one-off project.
nFlo’s engagement in SBOM projects begins with a thorough assessment of the current state. Together with the organisation we identify key applications and systems, map existing software development processes, assess DevOps/DevSecOps maturity, and determine the baseline level according to the maturity model described above. This stage — often underestimated — prevents the deployment of tools that the organisation is not ready to maintain.
We then assist with selecting and implementing tools appropriate to the organisation’s scale and maturity. For open source environments we recommend Dependency-Track as the central platform, Syft or cdxgen for generation, and an appropriate vulnerability scanning tool (Grype, Trivy). For organisations that need vendor support and advanced SBOM capabilities for large portfolios — we assist in evaluating commercial platforms (Snyk, Mend.io, Black Duck, Sonatype Nexus IQ). Tool selection is always preceded by a requirements assessment — we do not promote specific vendors.
Response speed as a standard: nFlo response times are written into the contract and differentiated by ticket priority. When implementing a SBOM programme this means that when a critical vulnerability such as Log4Shell appears, our team immediately supports clients in running queries against their SBOM platforms and implementing remediation — without waiting until the next business day.
A key element of our support is integrating SBOM with existing DevSecOps processes. We configure CI/CD pipelines, define “fail-build” policies, assist in implementing Policy as Code, and ensure that SBOM generation is an invisible part of the development cycle for developers — not an additional obligation. Developers write code, SBOM is generated automatically, and alerts reach the appropriate people.
We also assist organisations with the process and governance aspects: we develop SBOM policies, define remediation SLAs, design vulnerability triage processes, and train teams in the use of SBOM platforms. The risk reduction we achieve together with our clients comes from precisely this combination of tools, processes, and competencies — and it is reported per engagement, against the state before the SBOM programme.
For organisations subject to regulation (NIS2, DORA, CRA) we prepare compliance documentation that incorporates the role of SBOM as an element of supply chain risk management. We also help organisations prepare for audits — both internal and external.
Do you want to assess the current level of SBOM management maturity in your organisation, or implement an SBOM programme compliant with CRA and DORA requirements? Contact us — our experts will support you from the initial assessment through to a fully operational programme.
FAQ
Does SBOM replace vulnerability scanning (SAST, SCA, DAST)?
No. SBOM is a document that inventories components, while vulnerability scanning is a process of analysing them for security issues. SCA (Software Composition Analysis) tools typically generate SBOM as a by-product of scanning. SAST (source code analysis) and DAST (dynamic testing) detect different classes of problems — logic errors, configuration vulnerabilities — than SBOM analysis does. SBOM is the foundation on which a broader vulnerability management programme is built.
How often should SBOM be updated?
SBOM should be generated with every build and every change in dependencies. The minimum requirement is an update with every release. In environments with continuous deployment (CD), SBOM should accompany every deployment artefact. “Triggering” is also important: the appearance of a new CVE for a component present in the SBOM should automatically initiate a triage process — even if the SBOM itself has not changed.
Is SBOM mandatory in Poland?
There is no direct statutory requirement yet, but the Cyber Resilience Act (from 2027) will cover software manufacturers selling into the EU market, including Polish ones. NIS2 (implemented in Polish law as the act on the national cybersecurity system) requires supply chain risk management from important and essential entities — which in practice means the need for SBOM or equivalent mechanisms. Organisations subject to DORA (banks, insurers, investment firms) have equivalent requirements from January 2025.
What are the costs of implementing an SBOM programme?
Implementation costs depend on the scale of the organisation and the chosen approach. Open source tools (Syft, Dependency-Track, Grype) are free of charge, but require engineering resources for deployment and maintenance. Commercial platforms (Snyk, Mend.io, Black Duck) offer SBOM as part of a broader SCA package — costs are typically calculated per developer or per application. The total cost of ownership (TCO) of implementing SBOM depends on the number of applications and includes tools and labour — with a significantly lower risk of an incident like Log4Shell, whose remediation costs run into the millions.
How to handle SBOM for third-party applications for which we do not have the source code?
For binary applications from external vendors, SBOM should be required as part of the contract (see the section on requiring SBOM from vendors). If a vendor does not supply an SBOM, binary analysis can be performed using tools such as Black Duck Binary Analysis or Trivy (for containers), which scan binaries without source code. The results of binary analysis are less complete than a source-based SBOM, but significantly better than having no visibility at all.
Related concepts
Explore the key terms associated with this article in our cybersecurity glossary:
- Cybersecurity — Cybersecurity is a set of techniques, processes, and practices for protecting IT systems and data from unauthorised access.
- DevSecOps — DevSecOps is the integration of security practices at every stage of the software development lifecycle.
- Vulnerability (CVE) — CVE (Common Vulnerabilities and Exposures) is the standard identifier for publicly known security vulnerabilities.
- Zero-day — A zero-day is a vulnerability unknown to the software vendor, with no available patch at the time of discovery.
- IT supply chain — The IT supply chain encompasses all vendors, tools, and processes involved in creating and maintaining information systems.
Learn more
Explore related articles in our knowledge base:
- DevSecOps in practice: how to build security into the software development lifecycle
- Vulnerability management: from scanning to remediation
- Cyber Resilience Act — what does it mean for software manufacturers in the EU?
- NIS2 and supply chain risk management
- Open source security: how to safely use open source components
Check our services
Do you need cybersecurity support? See:
- Security audits - comprehensive security posture assessment
- DevSecOps Consulting - integrating security with development processes
- SOC as a Service - round-the-clock security monitoring
- Vulnerability management - systematic identification and remediation of vulnerabilities
Sources
- NTIA: The Minimum Elements For a Software Bill of Materials (SBOM) (2021)
- CISA: Software Bill of Materials (SBOM) Resources — CISA SBOM hub with tools and guides
- NIST SP 800-161r1: Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations (2022)
- OWASP CycloneDX: CycloneDX Specification 1.6 — official format specification
- Linux Foundation: SPDX Specification 2.3 — ISO/IEC 5962:2021 specification
- EU: Cyber Resilience Act — Regulation (EU) 2024/2847
- Synopsys: Open Source Security and Risk Analysis Report 2024
- OpenSSF: SLSA Supply Chain Levels for Software Artifacts — framework for software artefact provenance
- CISA: Stakeholder-Specific Vulnerability Categorization (SSVC) — vulnerability prioritisation framework
Related topics
See also:
