SBOM and Software Supply Chain Assessment

Modern applications and connected products often depend on many direct and transitive components. A single outdated or poorly documented dependency can create security, operational or compliance concerns.

A reliable SBOM helps answer important questions:

• Which third-party components and versions are in use?
• Are any components affected by known vulnerabilities?
• Are unsupported or end-of-life packages present?
• Is sufficient supplier evidence available?
• Which open-source licences apply?
• Which findings require urgent remediation?

A well-managed SBOM supports product security, vulnerability management, supplier assurance, procurement, technical documentation and customer due diligence.

The assessment is suitable for organisations that develop, integrate, purchase or distribute software and digital products, including software developers, SaaS providers, connected-product manufacturers, firmware developers, DevSecOps teams, compliance functions and procurement teams.

The scope can cover software, firmware, web platforms, APIs, mobile applications, embedded devices, containers and connected products.

What the Assessment Covers

1. Define the Product Boundary

Identify the product, release, firmware version, build, container image or software package represented by the SBOM. Clarify which connected software elements are included.

2. Include Direct and Transitive Dependencies

Direct dependencies are selected by developers. Transitive dependencies are introduced through other components. Both can create vulnerabilities, licence obligations and maintenance risks.

3. Validate SBOM Data Quality

Review component names, versions, suppliers, identifiers and dependency relationships. Record missing, inconsistent or unverifiable information as a quality issue.

4. Use Recognised Formats

Machine-readable formats such as SPDX and CycloneDX make SBOMs easier to exchange, compare and process. Select the format and detail level according to the product and intended workflow.

5. Assess Vulnerabilities in Context

A vulnerability match does not always prove that a product is exploitable. Consider the affected version, configuration, component function, exposure and supplier information. Separate confirmed risks from potential matches and non-exploitable cases.

6. Review Component Support

Unsupported, abandoned or end-of-life dependencies may not receive security updates and can be difficult to replace during an incident.

7. Examine Supplier Evidence

Relevant evidence may include supplier SBOMs, security advisories, patch policies, support periods and vulnerability statements. Missing information should be recorded as a supplier assurance gap.

8. Review Open-Source Licence Risks

Identify declared licences, missing licence information and potentially conflicting terms. The assessment can flag areas requiring legal review but does not replace legal advice.

9. Prioritise Corrective Actions

Remediation should consider severity, exposure, exploitability, component criticality, available fixes, supplier responsiveness and replacement difficulty.

10. Maintain the SBOM

Update the SBOM when releases, builds, firmware, container images or dependencies change. Integrate ownership, storage and review into development and product-security processes.

ComplyMarket applies a structured, risk-based process:

1. Define the product and software scope.
2. Collect SBOMs, manifests and supplier evidence.
3. Create or consolidate the component inventory.
4. Validate SBOM structure and data quality.
5. Review vulnerabilities, versions and support status.
6. Assess supplier evidence and licence concerns.
7. Classify findings by technical and business risk.
8. Prepare practical remediation recommendations.

Deliverables may include a component inventory, created or validated SBOM, quality and vulnerability findings, outdated dependency register, supplier evidence gap analysis, licence-risk overview, remediation roadmap, management summary and governance recommendations.

Does an SBOM prove that software is secure?

No. An SBOM improves transparency but should be combined with secure development, vulnerability assessment, supplier assurance and testing.

How often should an SBOM be updated?

Review it whenever a relevant release, build, firmware package, container image or dependency set changes.

How ComplyMarket Supports Your Organisation

ComplyMarket combines cybersecurity assessment, product compliance knowledge, supplier-data management and technical documentation support. This helps organisations connect software component findings with product risk, supplier evidence and compliance needs.

ComplyMarket can support SBOM creation and review, software composition analysis, vulnerability matching, outdated dependency identification, supplier evidence assessment, open-source licence-risk screening, remediation prioritisation and SBOM governance.

The result is a practical assessment that helps technical, security, procurement and compliance teams understand their software supply chain, address significant risks and maintain stronger evidence.