Ask a software provider for an SBOM and the first answer is often an easy yes. What arrives next may be a PDF, a spreadsheet or a file generated for last year's release. Direct dependencies are listed. The libraries inside those dependencies are not. Nobody is quite sure who produced the record or what happens when a vulnerable component turns up.
That is why an SBOM request needs an acceptance test. For procurement purposes, the useful deliverable is signed, tied to the release being acquired, machine-readable, clear about gaps and backed by a working vulnerability response process.
The six checks below can be used in requirements, provider evaluation, contract review, implementation acceptance and renewal.
In one sentence: require a signed, release-specific and machine-readable SBOM that covers components and transitive dependencies, identifies missing information, arrives through an agreed delivery path and connects to provider action.
Start with the job the SBOM needs to do
A software bill of materials, or SBOM, is a structured inventory of the components and dependency relationships inside software. The 2026 Minimum Elements for a Software Bill of Materials, co-authored by the Australian Signals Directorate's Australian Cyber Security Centre, describes it as a nested inventory that can support software supply chain risk decisions.
Imagine that a serious vulnerability is found in a common open source library. The product name in the asset register may give no clue that the library is buried three levels down. A current SBOM can show whether the component and version are present, how they relate to the product and which systems warrant investigation.
The word “can” is important. An SBOM is still provider data. It does not prove that the product is secure, that every component was detected or that the provider will fix a problem quickly. It also does not replace secure development evidence, penetration testing, privacy review, resilience testing or broader vendor due diligence.
The procurement task is to make the data usable and the responsibilities clear before the organisation depends on the software.
What changed in the 2026 guidance
The final 2026 guidance updates and replaces the 2021 baseline. It contains 17 data fields and six practices and processes. New fields cover matters such as the SBOM author's digital signature, data format and version, generation context, tool details, SBOM version, component hashes and component licences. Coverage, identifiers, updates, unknown information and machine-processable data were also strengthened.
For Australian organisations, two boundaries are easy to miss.
The guidance does not create a new legal requirement. An SBOM is not automatically mandatory for every Australian software purchase. Sector obligations, government policy, internal standards and the contract still need to be checked for the organisation concerned.
A signature does not certify accuracy or completeness either. It helps the recipient establish who signed the record and whether it changed after signing. Testing whether the component list is complete is a separate exercise.
The six-point SBOM acceptance matrix
Use the matrix below to turn a provider's “yes” into evidence that can be accepted, rejected or made conditional. The depth of testing should reflect the product's criticality and exposure.
| Acceptance area | What to require | What to inspect | Weak evidence |
|---|---|---|---|
| 1. Provenance | Named author, digital signature, generation context, tool name and version | Signature validation, timestamp and a clear link to the target release | An unsigned spreadsheet from an unnamed team |
| 2. Coverage | Target product, direct and transitive dependencies, relationships, identifiers, versions and declared gaps | Coverage statement, dependency graph, PURL or CPE identifiers, and treatment of unknown or withheld data | “Major libraries only” with no exclusions stated |
| 3. Currency | A matching SBOM for each release or update, plus corrected records | Product build, SBOM version, timestamp and refresh trigger | A one-off snapshot older than the supplied release |
| 4. Format | A current, interoperable, machine-readable format | Successful import of SPDX, CycloneDX or another accepted open format | A PDF or spreadsheet as the only deliverable |
| 5. Delivery | Timely access through an agreed file, URL, API or repository | Access test, owner, retention and recovery process | Access offered at the provider's discretion after an incident |
| 6. Response | Monitoring, advisories, notification, exploitability decisions and remediation | Sample advisory or VEX or CSAF mapping, owners and timeframes | “The customer monitors CVEs” with no provider action |
1. Provenance: where did the record come from?
Ask who generated the SBOM, at what point in the lifecycle and with which tool. A source scan before build, a build-time record and analysis of the final binary can produce different component lists.
The 2026 guidance adds an SBOM author signature. During evaluation, get a sample and validate it through the proposed trust path. A populated signature field or a screenshot of a green tick is not the same thing.
For higher-risk software, ask how signing keys are protected, how a compromised key would be handled and how recipients will be told that a signed record has been corrected or replaced.
2. Coverage: what has been left out?
The current minimum elements call for all components that make up the target software, including transitive dependencies, with no minimum depth. A list of the libraries selected directly by the development team is unlikely to meet that test.
Look for component names, versions, dependency relationships and useful identifiers such as Package URL or Common Platform Enumeration where available. Missing information should be marked unknown or withheld. A blank field tells the assessor very little.
Some detail may need controlled access. That can be workable if authorised assessors can obtain the information and the restriction is recorded. If an essential component field is withheld, the guidance says the recipient may consider the SBOM incomplete.
For a critical product, compare a sample against another source, such as a software repository or binary analysis. The result will not prove perfection, but it will show whether the provider's coverage claim deserves confidence.
3. Currency: does it match the release?
An SBOM for version 4.2 says little about version 4.4. Each version or update should have an associated SBOM, and the record should be corrected when an error or new information is found.
Write down the trigger. It may be every production release, every material update or a defined snapshot interval. Record the product version, build identifier, SBOM version and timestamp so operations can match the evidence to the deployed asset.
SaaS needs a deliberate answer because its components may change much more often than a conventional packaged release. An agreed API or snapshot cadence is more useful than “available on request”.
4. Format: can your tools read it?
SPDX and CycloneDX are the two open, machine-processable formats identified as widely used in the 2026 guidance. Procurement does not need to choose a favourite. It does need a current format that the organisation can ingest.
Run a sample import before selection. Check that identifiers and relationships survive the import and that the data can be matched to a security advisory. Avoid deprecated format versions.
A human-readable report may accompany the SBOM. It should not be the sole delivery when the organisation expects automated analysis. PDFs circulate nicely; they do not scale as a component inventory.
5. Delivery: will it be there when needed?
The delivery method might be a file packaged with the software, a version-specific URL, an API or a repository. Access controls can protect sensitive data, but authorised teams still need to load the record into trusted security tooling.
Test that path. Confirm who owns it, how long records remain available and what happens when credentials expire, an API changes or the repository is unavailable. Discovering these details during a vulnerability response is too late.
6. Response: what will the provider do?
Once a component is flagged, the provider still has work to do. Its process should cover monitoring, assessment, customer notification, remediation or mitigation, status updates and escalation.
Vulnerability Exploitability eXchange, known as VEX, and the Common Security Advisory Framework can add machine-readable context about a component's vulnerability status. They may help separate “the component is present” from “the product is exploitable in this configuration”. The statement needs a trusted source, and the decision needs an owner.
Put notification triggers, severity definitions, initial response, remediation timeframes and escalation routes into the evaluation and contract work. Align them with the organisation's vulnerability management and incident response processes.
Use the requirement at every decision gate
Leaving the SBOM question in a late security questionnaire makes it easy to promise and hard to enforce. Put it into the lifecycle.
- Requirements: define the fields, coverage, format, delivery method and acceptance test in the enterprise technology RFP or response schedule.
- Provider response: request a sample for a named product release. A policy statement is not a sample.
- Due diligence: validate the file, record gaps and compare the working process with the written response.
- Contract and acceptance: capture delivery triggers, correction duties, access and response obligations, subject to legal review.
- Implementation: ingest the production SBOM, link it to the asset and assign an operational owner.
- Operation and renewal: check whether the promised records, notifications and corrections arrived when they were meant to.
ASD's Guidelines for procurement and outsourcing place cyber supply chain risk across procurement, design, delivery, operation, maintenance and decommissioning. They also call for provider transparency, evidence and a documented shared-responsibility model. The SBOM belongs inside that wider system, not in a standalone compliance folder.
Brief the contract schedule properly
“The supplier will provide an SBOM” leaves most of the control unwritten. A working brief for procurement, security and legal teams should cover:
- the products, editions, services and environments in scope
- the minimum data fields and permitted current formats
- coverage of transitive dependencies and any linked records
- treatment of unknown, withheld and corrected information
- release, update or snapshot events that trigger a new record
- secure delivery and authorised access
- signature, integrity and validation requirements
- monitoring, advisory and vulnerability notification duties
- use of VEX, CSAF or equivalent status information where relevant
- remediation, mitigation, escalation and update timeframes
- evidence retention, audit support and transition-out access
- responsibility for subcontractors and upstream component providers
This is a requirements checklist, not contract language. Legal advisers should tailor the final terms to the transaction and applicable law.
A renewal example
A business-critical SaaS platform is due for renewal. The provider supplies a CycloneDX file, so the questionnaire is marked complete. On inspection, the file is four months old, refers to an earlier application release and says nothing about transitive dependencies.
The format is usable. The evidence is not yet fit for the renewal decision.
The team asks for a current record or agreed current snapshot, a release match, a coverage statement, declared gaps, a tested delivery path and the provider's vulnerability response procedure. If those items cannot be produced before renewal, the gap is recorded with an owner, a treatment and a decision date. “Received” and “accepted” remain separate fields.
This check can sit inside a broader cybersecurity vendor evaluation framework and the organisation's vendor and supplier risk management process.
Red flags to escalate
Take a closer look when a provider:
- supplies only a PDF, screenshot or manually maintained spreadsheet
- cannot match the SBOM to the release under evaluation
- omits transitive dependencies without describing the gap
- leaves required fields blank rather than marking them unknown or withheld
- blocks authorised delivery into the organisation's security tools
- presents a signature as proof that the component list is complete
- has no process for corrections or new releases
- leaves monitoring and notification entirely to the customer
- promises future capability without a date or reviewable commitment
A gap does not always mean rejection. It may lead to a condition, mitigation, price adjustment or risk acceptance. The decision record should show what was agreed, who owns it and when the evidence is due.
Frequently asked questions
Is an SBOM mandatory in Australia?
The 2026 minimum elements do not make SBOMs mandatory for every Australian software purchase. Check the sector's obligations, government policy, internal standards and the contract that apply to the organisation.
Should we require SPDX or CycloneDX?
Both are widely used, open and machine-processable. Accept a current format that your tools can ingest, and test a sample before the selection is final.
How often should the provider issue one?
Each version or update should have an associated SBOM. Corrected records should follow when an error or new information is found. For frequently changing SaaS, agree on a useful snapshot or API cadence.
Does this apply to SaaS and AI software?
Yes. The minimum elements apply to all software, including SaaS and AI systems. Those systems may need extra information or delivery arrangements to provide useful transparency.
Does a signed SBOM prove completeness?
No. A valid signature supports the claimed origin and integrity of the record. Accuracy, coverage and completeness need separate checks.
Make the file earn its place in the decision
The decisive question is simple: can the organisation use this provider's SBOM to make a release, vulnerability or renewal decision?
Through its Procurement-as-a-Service model, CYBORIUM helps Australian organisations define evidence requirements, assess provider responses and record the risk and commercial reasoning behind cybersecurity, AI and enterprise IT procurement. The client retains decision authority and contracts directly with its selected provider. CYBORIUM does not sell, deliver or operate the technology, and it does not invoice the client for the procurement service. The selected provider pays CYBORIUM a capped fee that is kept separate from the evaluation criteria.
Discuss an evidence-led software procurement
Sources and editorial note
- Australian Signals Directorate, 2026 Minimum Elements for a Software Bill of Materials
- Australian Signals Directorate, Guidelines for procurement and outsourcing
- Australian Signals Directorate and international partners, A Shared Vision of Software Bill of Materials for Cybersecurity
- Australian Signals Directorate, Guidelines for software development
Information and source status reviewed 31 August 2026. This article provides general procurement information and is not legal advice.
Also relevant: network vendor priorities in the telecommunications outlook, and secrets management procurement.
