SBOM and build-pipeline checklist

Software bill of materials plus the CI controls that make it useful. Inventory what you ship, who can publish, and how fast you can patch a dependency.

An SBOM is a machine-readable inventory of the components in a software product or image: names, versions, suppliers, and often licence and hash. It does not stop a breach by itself. It answers the question you get on day one of a supply-chain incident: are we running that library, and where.

Prefer a generated SBOM over a spreadsheet. SPDX and CycloneDX are the common formats. Produce one at build time from the resolved dependency graph (lockfile, container image, or installer), sign or hash the artefact with the build, and store it next to the release. A static SBOM from six months ago that nobody regenerates is theatre.

Pair the SBOM with a short build-pipeline checklist. Who can push to the registries and package feeds you consume. Are CI tokens scoped and short-lived. Do pull requests require review before publish. Is Dependabot or equivalent opening PRs for known-exploited CVEs, and is there a time-to-patch target for internet-facing and KEV-class issues. Can you rebuild from pinned sources if a maintainer account is hijacked.

Australian context: third-party and open-source compromise is already on the desk (Quest-style vendor path; AFP/TeamPCP-style malicious packages). Essential Eight patching strategies need an inventory to be evidence, not aspiration. If you are under SOCI/CIRMP or selling into government, expect buyers to ask for SBOM or equivalent component lists and for residual-risk language — treat that as procurement hygiene, not a separate religion.

Practical desk: pick one product line, emit CycloneDX or SPDX from CI on every release, fail the build if generation fails, and run a weekly diff of new critical CVEs against that SBOM. Keep the SBOM off the public internet unless you mean to. Link this page to Third-party and supply chain and Essential Eight evidence.