How should organisations handle supplier software when SBOMs are incomplete or absent?

Why incomplete SBOMs should be treated as an assurance problem

An SBOM is only useful if it can be consumed, compared and acted on. When a supplier cannot provide one, or provides a partial one, the issue is not just missing documentation, it is missing assurance about what is actually in the software, how dependencies are inherited, and whether your vulnerability checks can be trusted.

That matters because the operational risk sits in the blind spots: untracked components, stale dependency data, opaque transitive libraries, and no reliable way to confirm whether a disclosed vulnerability affects the delivered package. In practice, an incomplete SBOM weakens both triage and accountability.

Where supplier software is part of a broader software supply chain, AI Supply Chain Security and AI-BOM Guide is useful as a parallel reference point for what machine-readable component evidence should let a consumer verify.

What organisations should ask for instead of accepting gaps

The right response is to move from “send something” to “send something usable.” That usually means a machine-readable artefact that your tooling can ingest, stable component naming, version data, and enough dependency detail to support matching against your vulnerability, inventory and exception workflows. A PDF SBOM, or a file that cannot be parsed reliably, does not close the assurance gap.

If the supplier cannot provide that level of evidence immediately, treat the gap as conditional acceptance only. Continue review, but require a clear remediation commitment, defined delivery date, and evidence of how the supplier will maintain completeness over time for each release or build stream.

For supply-chain governance and ecosystem hygiene, supplier expectations should align with open-source and upstream security practice, including the guidance published by OpenSSF.

In parallel, retain contract language that makes the evidence obligation operational, not aspirational: the supplier should be required to provide consumable artefacts, notify on material component changes, and support recurrence checks when the software is updated or repackaged.

How to compensate while the supplier closes the gap

Until the supplier can provide usable artefacts, reduce the trust you place in the package and raise your own verification bar. That can include tighter dependency monitoring, stronger allowlisting, additional scanning at intake and update time, targeted review of high-risk components, and explicit contractual conditions tied to continued use.

The key judgment is proportionality. If the software is low criticality and isolated, you may accept a temporary gap with monitoring. If it reaches sensitive environments, is widely deployed, or updates frequently, the same gap should trigger stronger controls, narrower deployment scope, or a decision to delay onboarding.

What good looks like is not perfect completeness on day one. It is a supplier who can produce artefacts your controls can consume, explain how they are generated, and keep them aligned to released versions so that your dependency checks and exception handling remain reliable over time.

Risk and Threat Considerations

Incomplete SBOMs create exposure because they hide transitive dependencies, stale components and repackaging changes that may carry known vulnerabilities or malicious code. They also make it harder to tell whether a supplier response is credible when an issue is disclosed, which increases dwell time for unsafe software in production.

Failure mechanism: The control fails when teams treat the absence of a consumable SBOM as a minor administrative defect, then rely on incomplete inventory data to make vulnerability, patching and deployment decisions.

Impact: Hidden components can remain deployed, patch prioritisation becomes unreliable, and organisations may miss both exploitability and blast-radius signals for a supplier-delivered product.

Practitioner Guidance

What to prioritise: Decide whether the software can be accepted with a temporary assurance exception. If the component is externally facing, business-critical, or frequently updated, make machine-readable evidence a gating item rather than a post-procurement nice-to-have.

What to verify: Check that the artefact is actually consumable by your tooling, maps cleanly to the delivered build, and contains enough version and dependency detail to support vulnerability matching. If it cannot be ingested, it is not yet operationally useful.

Decision rule: If the supplier can only provide partial or manual artefacts, accept the software only with compensating monitoring and a dated remediation commitment. If they cannot show a credible path to usable evidence, treat that as a supplier assurance failure, not a documentation delay.

Practitioner takeaway: The question is not whether the supplier has “an SBOM,” but whether you can use it to make safer deployment and response decisions; if you cannot, the residual risk is still real.

Related resources from NHI Mgmt Group

• How should organisations use SBOMs to improve software supply chain governance?
• Why does outdated software increase legal and operational risk for organisations that handle regulated data?
• What should organisations do when they need to continue operating after a critical supplier or software provider is compromised?
• Should organisations prioritise SLSA over SBOMs for software trust?