The supply-chain incidents that defined the last few years — SolarWinds, the various npm and PyPI compromises, the XZ Utils backdoor that came within weeks of reaching mainstream Linux distributions — are no longer outliers. They are the new normal. For Australian organisations, supply-chain risk has moved from a footnote in security policy to a board-level conversation. SBOMs are a part of the answer, but only a part.
The shape of the risk
Modern software is overwhelmingly assembled rather than written. A typical web application includes hundreds of direct dependencies and thousands of transitive ones. A typical SaaS vendor sits on a stack of other SaaS vendors. A typical infrastructure platform pulls signed binaries from registries you have never audited.
The supply-chain risk surface, accordingly, is everything between “we wrote this” and “our users use it”. Compromise can occur in:
- Open-source dependencies (typo-squatting, malicious commits, abandoned libraries adopted by bad actors).
- Build pipelines (compromised CI runners, leaked signing keys).
- Third-party SaaS dependencies (compromised vendor used as a stepping stone).
- Hardware and firmware (rare in practice, severe in impact).
What an SBOM is
A Software Bill of Materials (SBOM) is a structured inventory of the components inside a piece of software — including version, supplier, and (ideally) licence and known vulnerability information. The two dominant formats are SPDX and CycloneDX. Most modern build systems can produce one as part of the build.
An SBOM is not a vulnerability scan. It is the input that makes vulnerability scanning meaningful. When a new vulnerability is announced (Log4j, the next one), an SBOM lets you answer the question “is this in our environment?” in minutes rather than weeks.
What good supplier diligence looks like
For Australian organisations, supplier diligence in 2026 looks different from the tick-box questionnaires of five years ago. Practical components include:
- SBOM availability. Can the supplier produce an SBOM for the version of their product you are using, in a standard format?
- Vulnerability disclosure. Does the supplier have a published security contact, a vulnerability disclosure policy, and a track record of timely advisories?
- Build provenance. Are releases signed? Is build provenance attested (e.g. SLSA framework)?
- Incident history. Has the supplier had incidents? How were they handled? Transparency about past incidents is a signal of maturity, not a red flag.
- Compliance posture. ISO 27001, SOC 2, IRAP — relevant where the supplier is in scope of your own compliance obligations.
- Concentration risk. Where do the supplier’s own critical dependencies sit? A platform whose entire offering depends on one upstream vendor inherits that vendor’s risk profile.
What we recommend
- Build an inventory of your top 30 software suppliers. SaaS, on-premises, open-source frameworks. Most organisations cannot produce this list, which is itself the first finding.
- Require SBOMs for new procurement. Make it a contractual expectation, not an afterthought.
- Generate SBOMs for your own software. Most modern CI tooling can do this with minimal configuration. Store them where they are useful in an incident.
- Run a tabletop exercise based on a hypothetical compromise of one of your top suppliers. The exercise itself is more valuable than any document it produces.
- Subscribe to the relevant advisories. ASD, the relevant CERT for your sector, and the security advisories of your top suppliers.
Where this is heading
Australian government procurement is increasingly asking suppliers about SBOM and supply-chain attestation. The same trend is visible in critical infrastructure, financial services, and large enterprise. Organisations that selling into those markets will, within a few years, be expected to provide attestations they currently do not produce. Starting now is materially cheaper than starting under deadline.
If you would like a supply-chain risk assessment that produces a prioritised, costed plan, we can help.