SBOM + SLSA: Minimal Supply-Chain Security for Small Teams

How small teams can implement meaningful supply-chain security. Covers generating SBOMs, reaching SLSA Level 2, dependency scanning, and provenance verification.

May 3, 2026·Security Application Security

sbomslsasupply-chainsecuritydependencies

Software supply chain security has moved from conference talks to regulatory requirements. Government mandates, enterprise procurement policies, and customer security questionnaires increasingly ask for SBOMs (Software Bill of Materials) and build provenance. For large organisations with dedicated security teams, implementing these is straightforward. For small teams—five to twenty engineers—the challenge is finding the minimal viable implementation that satisfies requirements without consuming all your engineering bandwidth.

This article covers what SBOMs and SLSA actually require, which tools to use, how to integrate them into CI, and what you can safely defer when resources are limited. It is written for engineering leads and senior developers at small teams.

The security hub covers broader security resources, and the application security path provides structured learning. For related security practices, see the OWASP Top 10 checklist, Secure by Design sprint plan, and passkeys implementation guide.

What is an SBOM

A Software Bill of Materials is a machine-readable inventory of every component in your software: direct dependencies, transitive dependencies, their versions, and their licenses. Think of it as a nutritional label for software.

Formats

SPDX: ISO standard, widely accepted, verbose
CycloneDX: OWASP-backed, developer-friendly, lighter weight

For most teams, CycloneDX is the pragmatic choice. It is easier to generate, easier to consume, and accepted by most policies that require an SBOM.

What goes in an SBOM

Package name and version for every dependency
License identifier
Package URL (purl) for unambiguous identification
Relationship between components (direct vs transitive)
Hash values for integrity verification

What does not need to be in a minimal SBOM

Source code
Configuration files
Internal documentation
Build scripts (unless they are distributed as part of the software)

What is SLSA

SLSA (Supply-chain Levels for Software Artifacts) is a framework for build integrity. It defines levels of assurance about how your software was built:

SLSA Level 1: documentation of the build process (build provenance)
SLSA Level 2: hosted build service with authenticated provenance
SLSA Level 3: hardened build platform with isolation between builds

For small teams, SLSA Level 1 is the realistic target. Level 2 is achievable with GitHub Actions or similar CI platforms. Level 3 requires dedicated infrastructure that is typically beyond small-team budgets.

Minimal implementation for small teams

Step 1: generate an SBOM in CI (1 hour setup)

Add an SBOM generation step to your CI pipeline. Most ecosystems have mature tooling:

Node.js: @cyclonedx/cyclonedx-npm generates a CycloneDX SBOM from package-lock.json
Python: cyclonedx-bom generates from requirements.txt or Pipfile.lock
Go: cyclonedx-gomod generates from go.sum
Container images: syft scans container images and generates SBOMs in multiple formats

Run the generator as a CI step and store the output as a build artifact.

Step 2: attach the SBOM to your release (30 minutes setup)

When you publish a release (GitHub release, container registry push, package registry publish), attach the SBOM as an artifact. This makes it available to consumers without extra requests.

Step 3: generate build provenance (1 hour setup)

For SLSA Level 1, document:

What source code was used (commit SHA)
What build commands were run
What the output artifacts are
When the build was executed

For GitHub Actions, the slsa-framework/slsa-github-generator action automates provenance generation for common build types.

Step 4: scan the SBOM for vulnerabilities (30 minutes setup)

Use a vulnerability scanner that consumes your SBOM:

grype scans SBOMs against vulnerability databases
osv-scanner queries the OSV database
GitHub Dependabot processes SBOMs natively

Add the scan to CI and fail the build on critical/high vulnerabilities.

What to skip when resources are limited

Skip: custom SBOM formats

Do not build a custom SBOM generator. Use an off-the-shelf tool that outputs CycloneDX or SPDX.

Skip: SLSA Level 3

Level 3 requires hermetic builds, isolated build workers, and non-falsifiable provenance. This is important for operating systems and critical infrastructure but overkill for most application-level software.

Skip: vulnerability management platforms

A full vulnerability management platform (Dependency-Track, Snyk, etc.) is valuable but not required for a minimal implementation. Start with CI-integrated scanning and add a platform when you outgrow it.

Skip: signed SBOMs (initially)

Signing SBOMs with Sigstore or similar is good practice but adds complexity. Start with unsigned SBOMs and add signing when your process is stable.

Common mistakes

Mistake: generating the SBOM from the source code instead of the lock file. The lock file captures the exact versions installed, including transitive dependencies. The manifest file (package.json, requirements.txt) only lists direct dependencies and version ranges.

Mistake: not updating the SBOM on every build. An SBOM is only useful if it matches the shipped artifact. Generate it as part of the build, not as a manual step.

Mistake: treating SBOM generation as a one-time compliance task. The value of an SBOM comes from continuous generation, scanning, and monitoring. A static SBOM from six months ago is useless for vulnerability response.

Mistake: ignoring container base image dependencies. If you ship containers, the base image contains an operating system's worth of packages. Scan the full image, not just your application dependencies.

Trade-offs

SBOM generation adds CI time (usually 30–120 seconds). This is negligible compared to the value of knowing what you shipped.
Vulnerability scanning produces noise. Not every CVE in a transitive dependency is exploitable in your context. Invest time in triage and allowlisting rather than chasing every alert.
SLSA compliance requires CI platform trust. You are trusting your CI platform (GitHub, GitLab, etc.) to produce honest provenance. For most teams, this is a reasonable assumption.