Supply Chain Security for Australian SMBs: Contract Clauses, SBOMs, and Vendor Questions That Stop Third-Party Breaches

Why your software supply chain is the weakest door

The ACSC's recent advisories make one point repeatedly: attackers love the supply chain. ClickFix is hitting Australian infrastructure through compromised WordPress sites. China-nexus actors are hiding inside networks of compromised devices. Russian GRU operators are targeting Western logistics and technology companies. A single trusted third-party component can turn a vendor relationship into a breach vector.

For an SMB, the problem is not malice. It is opacity. You install a plugin, sign up for a SaaS tool, or pull an npm package because it solves a problem. You rarely ask what is inside it, who built it, or how it was signed. That opacity is what attackers exploit.

Four evidence pieces every SMB should demand

If a vendor cannot explain how their software is built, do not put your data in it. Start asking for four documents: SBOM, VEX, SLSA attestation, and signed provenance.

SBOM: the ingredient list

A Software Bill of Materials is a machine-readable list of every library, dependency, and component inside a product. Think of it as the nutrition label on the side of a food tin. If a new CVE drops in Log4j, OpenSSL, or a random JavaScript package, an SBOM lets you answer one question in minutes: are we exposed?

Australian organisations should ask for SBOMs in JSON or SPDX/CycloneDX format from any vendor that ships software. If a vendor says they do not have one, that is a signal. They may not know what is inside their own product.

VEX: does this CVE actually matter?

Vulnerability scanners love to scream. A Vulnerability Exploitability Exchange document tells you whether a reported CVE is actually exploitable in the product you are running. It saves you from patching every false alarm and helps you focus on the few issues that matter. Demand VEX files alongside SBOMs, especially for critical SaaS agents and on-premise appliances.

SLSA: proof the build was not tampered with

The Supply Chain Levels for Software Artifacts framework rates build integrity from Level 1 to Level 4. Level 1 means the build is scripted. Level 4 means every step runs on hardened infrastructure, hermetically sealed, with verifiable provenance. Most SMBs do not need Level 4 from every vendor, but you should demand at least Level 2 or 3 for anything that touches customer data or financial systems.

Sigstore and code signing: know where the binary came from

Code signing proves a package came from the publisher it claims to came from. Sigstore is a free, open standard for signing and verifying software artifacts without managing long-lived keys. Ask your vendors whether their containers, packages, and binaries are signed, and whether your team can verify those signatures before deployment.

Package registry hygiene: npm, PyPI, and Docker Hub

Open-source registries are not app stores. Anyone can publish, names can be typosquatted, and abandoned packages get hijacked. Reduce the risk with three habits.

First, pin versions in lock files. Do not let npm install, pip install, or docker pull grab the latest tag automatically. A locked version is a known version. Second, scan dependencies before merge. Tools like Snyk, OSV, Trivy, or Grype turn SBOMs into action lists. Third, restrict internal pulls. Run a private registry mirror, approve packages centrally, and block direct installs from public indexes except for emergencies.

For Docker specifically, prefer minimal base images, verify image digests, and never run latest in production. A signed image from a trusted publisher is better than a popular one with a million pulls.

SaaS vendor attestation and contract clauses

A terms-of-service checkbox is not a security contract. Australian SMBs should add four clauses to any SaaS agreement that handles sensitive data.

1. Security disclosure obligation. The vendor must notify you within 24 hours of any breach, vulnerability, or supply-chain incident that could affect your data.

2. Right to audit. You or your nominated assessor can review the vendor's security controls, penetration test results, and third-party risk reports annually.

3. Data residency and sub-processors. The vendor must list every sub-processor, their location, and the data they touch. No surprise AWS region or offshore support desk.

4. Exit and data return. On termination, you get your data back in a standard format within a fixed window, and the vendor certifies deletion.

Add a kill clause. If the vendor cannot produce an SBOM, a recent penetration test, or evidence of signed builds within 30 days of request, you can terminate without penalty.

Supply chain security checklist

Use this before onboarding any new software vendor or renewing an existing contract.

• Request an SBOM in CycloneDX or SPDX format.
• Request a VEX document for known CVEs.
• Confirm SLSA build level 2 or higher for critical components.
• Verify that binaries, containers, and packages are signed.
• Pin all dependency versions and use lock files.
• Run dependency vulnerability scans in CI/CD.
• Maintain an approved vendor and package list.
• Review SaaS contracts for breach notification, audit rights, and data residency clauses.
• Verify sub-processor list and geographic location.
• Test your incident response plan for a third-party breach scenario.

Vendor security questionnaire: 10 must-ask questions

Send this to every SaaS or software vendor before you sign.

1. Can you provide a current SBOM for the product or service?
2. Do you publish VEX statements or triage guidance for vulnerabilities in your components?
3. What SLSA level do your release builds meet, and can you share the attestation?
4. Are your containers, binaries, and packages signed? Which signing infrastructure do you use?
5. How do you manage dependencies from public registries like npm, PyPI, or Docker Hub?
6. What is your process for responding to a new critical CVE in a third-party library?
7. How quickly do you notify customers of a security incident or supply-chain compromise?
8. Can you list all sub-processors, their locations, and the data they access?
9. When did you last complete an independent penetration test or security audit?
10. What evidence can you provide that your build and release pipeline has not been tampered with?

If a vendor dodges more than two of these, treat it as a red flag. You are not asking for perfection. You are asking for evidence.

FAQ

Conclusion

Supply chain risk is a policy problem, not just a technology problem. The controls that protect Australian SMBs are simple: ask for SBOMs, demand VEX triage, verify build integrity with SLSA and sigstore, lock down package registries, and write security obligations into contracts. Start with the checklist and the 10-question vendor questionnaire. They cost nothing and expose the vendors that take security seriously versus the ones that hope you will not ask.

Visit consult.lil.business for a free cybersecurity assessment.

References

1. ACSC Supply Chain Security Guidance
2. NIST SP 800-161 Rev. 1: Cybersecurity Supply Chain Risk Management Practices
3. SLSA Framework Levels
4. sigstore: software signing for the open source ecosystem
5. CISA Software Bill of Materials

Verifier warning: verifier could not run (PluginLlmTrustError).