SBOM clauses for Australian software buyers

When a software supplier says it can provide an SBOM, the real issue for a buyer is whether that document will help with procurement, security review and ongoing risk management in practice. A promise is not very useful if the SBOM does not match the product your business is buying, cannot be ingested by your tools, or leaves out important dependencies without saying so.

For Australian businesses buying critical software or SaaS, the practical answer is to treat the SBOM as a contract workflow issue. The agreement should say what product or service the SBOM covers, what format you will receive, how updates and corrections are handled, and what happens if information is unknown or withheld. That is especially important where your security team needs version-level visibility to assess newly reported vulnerabilities.

An SBOM can show software components and dependencies, but it is not a certificate that the product is secure. This article explains what an Australian business buying critical software should ask for and how to turn that request into a workable contract term.

Match the SBOM to the software you are buying

An SBOM, or software bill of materials, is an inventory of software components and their dependency relationships: an ingredients list for software. Buyers should ask for a widely used, interoperable, machine-processable format that their tools can ingest and analyse.

For a buyer, that matters because security questions usually arise at version level. If your supplier gives you an SBOM for an old release, or a generic corporate statement about open source usage, it may not help you identify whether the live version of the product includes a relevant component.

Take a payroll platform as an example. If a newly reported issue affects a specific library version, your security team needs to know whether that library appears in the version or build your business is actually running. A stale or high-level SBOM may not answer that.

The 2026 Minimum Elements guidance co-authored by the Australian Cyber Security Centre treats SBOMs as a practical tool for software supply chain transparency and risk management. It encourages organisations to request and generate SBOMs that meet updated minimum elements. Just as importantly, it says the minimum elements do not create new legal requirements. So an SBOM request is a contracting and procurement question, not a blanket rule that every Australian private SaaS vendor must already satisfy.

Your shortlist of negotiation points

Before you accept a supplier's promise to provide an SBOM, pin down these points in the procurement agreement, order form, security schedule or implementation documents.

• Target product or service: identify the exact software product, module or SaaS service covered.
• Version or build: state whether the SBOM relates to the production release, a named build, or another identifiable code delivery.
• Coverage: say what components and dependencies are included, and what is out of scope.
• Format: require a machine-processable format your team can ingest.
• Author: record who generated the SBOM, not just who produced the software.
• Unknowns and withheld items: require these to be identified clearly rather than silently omitted.
• Delivery and access: decide who receives it, how it is shared, and whether you can load it into risk tools.
• Updates and corrections: set a workable trigger for new versions, revised builds and error corrections.
• Follow-up process: name the contact or workflow for questions, gaps and vulnerability-related follow-up.

This is usually better than dropping in a vague clause that says the supplier will provide "an SBOM on request".

Define the product boundary carefully

Most disputes about SBOM usefulness start with scope. The supplier may think it has complied by sending an inventory for a code package, while you expected visibility into the hosted service your staff actually use every day.

Your contract should identify the target software clearly. For SaaS, that may mean the named service, particular modules, customer-specific deployment, or the production environment tied to your subscription. Where the supplier uses linked SBOMs for subcomponents, make sure you can access all linked material needed to understand the inventory.

Coverage also needs careful contract drafting. The 2026 guidance treats coverage broadly and contemplates component and subcomponent visibility, including dependency relationships and transitive dependencies. But SaaS and cloud environments are more complicated, and the guidance says they may require additional elements. That means you should not assume the SBOM will automatically cover every managed service, every supplier to your supplier, or the entire underlying cloud stack.

Instead, ask the supplier to state inclusions and exclusions. For example, does the SBOM cover the application code, bundled libraries, embedded agents, container images, customer-side connectors, or security-relevant configuration files? Does it exclude shared cloud infrastructure operated by a third party? Clear exclusions are often more useful than broad promises.

Make sure the SBOM is deliverable and usable

A PDF summary is rarely enough if your goal is security review, automation or ongoing monitoring. The current guidance emphasises machine-processable data and notes that organisations should accept widely used, interoperable formats rather than insisting on one universal format.

For buyers, that means focusing on outcome. You want a format your team or tools can ingest, compare and store. If your internal process depends on a particular workflow, test that early. There is no point negotiating for an artefact that your procurement, security or IT team cannot actually use.

You should also ask who created the SBOM. The guidance distinguishes the SBOM author from the component producer. Those may be the same entity, but not always. That distinction matters when you are assessing reliability, asking questions or tracing corrections later.

Agree on a practical acceptance and correction process too. The guidance recommends avoiding deprecated format versions for new software, requires access to linked SBOMs relied on for coverage, and recognises that withholding essential component data may make an SBOM incomplete. Your contract can identify who checks those points, how an unusable or materially incomplete delivery is reported, and the agreed correction or escalation path. Negotiate any right to reject or delay acceptance expressly rather than assuming the guidance creates that right.

Another practical point is how missing information is handled. If data is unknown, or deliberately withheld, it should be labelled as such. Silent gaps are much harder to assess than an explicit note that information is unknown or withheld. If some security-related details are redacted, the supplier should have a process for authorised recipients to ask follow-up questions.

Agree on access, recipients and permitted use

Many buyers ask for an SBOM without deciding who inside the business needs it. Legal may negotiate the right, but security or IT operations may be the real users.

Spell out the delivery method and recipient group. For example, will the SBOM be provided with onboarding materials, via a secure portal, through an API, or by named contacts on request? If the supplier uses access controls, those controls should protect the information without blocking authorised internal sharing.

Permitted use matters too. Your contract should let you use the SBOM for internal security, procurement, risk and compliance activities, including ingestion into trusted security tools. If you may need to share it with a managed security provider, insurer, auditor or incident response adviser, deal with that expressly. Otherwise, you may receive the data but be contractually unable to use it in the way your review process requires.

Also consider storage and handling on your side. If your business asks for machine-readable artefacts every release, someone needs to receive, retain and manage them. For a business-critical SaaS product, align the paper commitment with an operational owner and a technical delivery path.

Set an update trigger that matches the software relationship

The right update obligation depends on the product and service model. The current guidance says each software version or update should have an associated SBOM, and that revised SBOMs should be issued when component details change or errors are corrected.

That does not create a universal statutory deadline for private contracts, and SaaS can be especially tricky because releases may happen frequently. A buyer-side contract should therefore set a feasible trigger rather than copying a rigid rule that neither side can operate.

For example, the parties might agree on a new SBOM for major releases, material production updates, or versions deployed to your environment, with revised data where errors or newly identified component details are found. They should also agree on where correction notices go, who can raise issues, and how quickly obvious SBOM errors are handled.

The key is practicality. If the supplier updates the service daily, a manual email attachment process may fail. In that case, a controlled repository or API-based access model may be more realistic.

An SBOM is not a substitute for the rest of the contract

An SBOM can improve transparency, but it does not prove the software is secure, free of vulnerabilities, licence-cleared, or backed by source code escrow. It is a component inventory, not a security certificate.

That distinction matters when negotiating the rest of the deal. A listed component can help identify potential exposure, but whether it creates a contractual issue depends on the promises in the agreement: for example, security warranties, prohibited-component restrictions, remediation obligations or agreed acceptance criteria. You still need separate terms for vulnerability monitoring, incident notification, remediation expectations, security warranties, indemnities where appropriate, and liability allocation.

In practice, an SBOM is one input into risk decisions. It can help your team identify whether a reported issue may affect the software you buy, monitor updates, and ask better questions. But it should sit alongside broader supplier due diligence, technical assurance and well-drafted supplier agreements.

Key Takeaways

• An SBOM clause should be tied to the exact product, module, service, version or build your business will actually use.
• Coverage should be stated clearly, including inclusions, exclusions, dependency visibility and any limits for SaaS or cloud environments.
• Buyers should ask for a machine-processable, usable SBOM format, with the SBOM author identified and unknown or withheld information flagged.
• Access, recipients and permitted internal use should be settled so security and IT teams can receive, store and analyse the SBOM.
• Update and correction triggers need to be operationally realistic, especially for frequently updated SaaS.
• An SBOM improves transparency, but it does not certify security or replace broader contractual protections.

If you are buying critical software or SaaS, Sprintlaw can help you negotiate supplier terms, security schedules, SaaS agreements and practical contract workflows so the SBOM you request is one your business can actually receive and use. Call 1800 730 617 or email team@sprintlaw.com.au.