SBOM and Supply Chain Security Audit

The audit produces a complete software bill of materials (SBOM) for each product assessed. It becomes visible which third-party libraries are embedded in the software; every component is assessed for security vulnerabilities, end-of-life status and licence risks. This creates the factual basis required ahead of audits, procurement and acquisitions.

Typical starting points

ahead of audits, procurement or EMBAG-related evidence work: an SBOM in a standard format provides the machine-readable component record
ahead of M&A due diligence: vulnerabilities, end-of-life components and licence risks are assessed by severity in a risk report
ahead of building permanent supply-chain governance: components, risks and patch or replacement recommendations are documented as a baseline

Outcomes

The audit delivers a robust risk statement: whether a product is fit for audit and procurement, which licence risks endanger your own IP, and how urgently action is needed. As concrete deliverables, the following are produced for each product assessed:

a complete SBOM in a standard format (CycloneDX or SPDX)
a risk report with the vulnerabilities and EOL components by severity
a concrete patch or replacement recommendation for every finding

Scope of work

The audit examines each product from the codebase through to the risk report.

flowchart TD
    accTitle: Flow of the SBOM audit
    accDescr: From codebase and container images an SBOM in CycloneDX or SPDX is generated; vulnerabilities, EOL components and licences are assessed and condensed into a risk report with recommendations.
    A["Codebase and container images"] --> B["Generate SBOM<br/>CycloneDX or SPDX"]
    B --> C["Check vulnerabilities and EOL"]
    B --> D["Assess licences"]
    C --> E["Risk report<br/>by severity, with recommendation"]
    D --> E

Automated inventory (SBOM, CycloneDX/SPDX) Codebases and, if wanted, container images are scanned and standardised SBOMs generated:

CycloneDX or SPDX format
the invisible is made machine-readable and auditable

Vulnerability and malware check Dependencies are cross-referenced against global security databases:

end-of-life components without support are identified
in an incident like Log4j, the SBOM makes it possible to look up which products contain the affected component

Licence risk analysis Copyleft licences such as the GPL are assessed in the context of use; where licence obligations do not fit the business model, suitable alternatives are proposed.

Scope boundaries

The audit creates transparency and prioritises the risks, it does not fix them. Applying patches, replacing components and continuously monitoring the supply chain are not part of the audit; this permanent anchoring is delivered by Security, Compliance and OSPO as a Service. Alongside the supply chain, the Service Delivery Assessment can examine delivery reliability.

Key data

The effort depends on the number of products and the depth of their supply chains:

how many dependencies are inventoried
how many are checked for vulnerabilities and malware
how many are assessed for licence risks

A single application with a manageable stack is audited quickly, a portfolio of many products calls for more depth. What the audit costs in a concrete case depends on exactly these factors. The price range gives the frame for your own portfolio.

Request pricing

Further information

SBOM, the software bill of materials as a standard for supply-chain transparency.
Software Supply Chain Security, securing dependencies rather than just inventorying them.