Software Supply Chain Security: What SLSA and SBOM Mean for Your Organisation

Supply chain attacks work because they target the trust relationships that organisations rely on to deliver software efficiently. When you pull a dependency from a package registry, you are trusting that the package is what it claims to be, that it has not been modified in transit, and that the maintainer's account has not been compromised. Each of those assumptions has been violated in significant incidents in recent years. The scale of impact is amplified precisely because the attack vector is a trusted channel.

Two frameworks have emerged as the primary tools for understanding and improving software supply chain security. The Supply-chain Levels for Software Artefacts framework, known as SLSA, focuses on the integrity of the build process itself. Software bills of materials, or SBOM, focus on visibility into what a piece of software is composed of. They address different aspects of the same problem, and most mature software supply chain security programmes eventually need both.

What SLSA Provides

SLSA is a framework that defines levels of assurance about how a software artefact was built. At its core, the question it answers is: can you trust that the software you are deploying was actually built from the source code you think it was, using the build process you think it used, and has not been tampered with in transit? These questions sound basic, but the answers for many organisations are less certain than they assume. Build pipelines that allow arbitrary code execution, artefacts that are not signed, and deployment processes that pull from mutable image tags all represent points where an attacker can substitute a malicious artefact.

The SLSA framework defines four levels of assurance, from basic scripted builds through to fully auditable, hermetic build environments with strong provenance attestation. Most organisations starting from scratch are at level zero: they have a build process but cannot produce verifiable evidence about how a given artefact was produced. Moving to level one, which requires a scripted build process with generated provenance, is achievable for most teams without significant infrastructure investment. Higher levels require more investment and are typically relevant for software that is distributed to others rather than deployed internally.

What an SBOM Provides

A software bill of materials is a structured inventory of the components that make up a piece of software. This includes direct dependencies, transitive dependencies, and any embedded third-party components. The value of an SBOM is operational: when a significant vulnerability is disclosed in a widely-used library, an organisation with current SBOMs can immediately query which of its systems are affected. An organisation without SBOMs has to manually audit each system, which takes time that matters when a vulnerability is being actively exploited.

SBOMs are also increasingly being requested by enterprise customers and required in some regulated procurement contexts. The logic from a customer's perspective is straightforward: if you are delivering software to us, we want to understand what it is made of, particularly any components with known vulnerabilities or unfavourable licensing terms. Generating an SBOM as part of the build process is a relatively low-cost addition if the build pipeline is already well-structured. Generating accurate SBOMs retrospectively for existing systems can be significantly more work.

When Your Organisation Actually Needs to Care

The relevance of SLSA and SBOM frameworks depends on what your organisation builds and who uses it. If you develop software that is distributed to customers or deployed in environments you do not control, supply chain integrity and transparency are directly relevant to your customers' security posture. If you are a pure SaaS business deploying only to your own infrastructure, the risk profile is different but not absent: your own dependency on third-party packages still represents supply chain risk.

Regulatory drivers are also increasing. If your organisation operates in a sector with formal software security requirements, or if you supply software to government customers, SBOM generation and supply chain assurance may become compliance requirements in the near term. Getting ahead of these requirements by building SBOM generation into your pipeline now avoids the scramble of retrofitting it when a customer or regulator requests it under time pressure.

Where to Start

For most organisations, the practical starting point is visibility rather than formal framework implementation. Run a dependency inventory across your key systems. Understand what you are pulling in, whether those packages have known vulnerabilities, and whether your build pipeline has obvious integrity gaps such as unsigned artefacts or unpinned dependency versions. This baseline gives you a picture of current risk without requiring formal SLSA certification or SBOM tooling investment.

From that baseline, prioritise actions by risk. Pinning dependency versions and verifying checksums costs little and removes a meaningful attack vector. Automating dependency vulnerability scanning in your CI pipeline is a similar low-cost, high-value step. SBOM generation and formal SLSA level attainment can follow as your supply chain security programme matures. The goal in the first phase is to understand what you have; the goal in the second phase is to control it.

• Audit your dependency inventory before investing in formal frameworks
• Pin dependency versions and verify checksums as a baseline control
• Add automated dependency vulnerability scanning to the CI pipeline
• Start SBOM generation at build time for new systems before retrofitting existing ones
• Use SLSA levels as a maturity target rather than a compliance exercise

If your organisation is assessing software supply chain risk or responding to customer requests for SBOM or supply chain assurance, we can help you develop a practical approach. Contact us at info@cyberlinx.com.au.