Software supply chain security checklist: SBOM, SLSA, signing, curation and runner hardening

Securing your software supply chain means controlling four things: what goes into your software (dependencies), how it is built (pipelines and runners), how you prove what you shipped (SBOMs, provenance and signatures), and how fast you can respond when something upstream is compromised. This checklist breaks those into concrete steps you can assign to owners and tick off. It is tool-neutral where possible, with notes on where GitLab and JFrog features fit.

Work through it in order. The early sections give the most protection for the least effort.

1. Know what you ship: SBOMs

A software bill of materials (SBOM) is the ingredient list for an application. It is the single most useful artefact when a new vulnerability is announced, because it lets you answer “are we affected?” in minutes rather than days.

• Generate an SBOM for every application at build time, not after release.
• Use a standard format. CycloneDX and SPDX are the common choices.
• Store the SBOM with the build artefact and keep it for the life of the release.
• Include transitive dependencies, not just the ones in your manifest.
• Benchmark your SBOM content against CISA’s 2025 minimum elements. CISA published these as draft, voluntary guidance in August 2025, building on the 2021 NTIA minimum elements.
• Decide who receives SBOMs: your own security team, customers who ask, or both.

Tool notes. GitLab’s dependency scanning (Ultimate) can generate CycloneDX SBOMs per directory and scan them, including transitive dependencies. JFrog Xray generates SBOMs covering direct and indirect dependencies for artefacts stored in Artifactory.

2. Control what comes in: curation and dependency scanning

Most supply chain attacks arrive through a dependency, not your own code.

• Route all package downloads through a single internal repository manager (for example JFrog Artifactory or Sonatype Nexus Repository) instead of letting builds reach public registries directly.
• Block or quarantine packages that fail policy before developers can use them.
• Hold brand-new package versions for a short period so the community can flag poisoned releases.
• Scan dependencies for known vulnerabilities and licence issues on every merge request.
• Assess the health of critical open-source projects you depend on. OpenSSF Scorecard provides security scores for GitHub and GitLab repositories.
• Pin versions and commit lockfiles.

Tool notes. JFrog Curation blocks risky packages at the point of request and can serve the highest compliant version automatically. It supports policies on severity, licence and package age, including an immaturity policy that holds new versions for 14 days. Xray continuously scans repositories, builds and container images, including Docker image layers. In GitLab, dependency scanning is an Ultimate feature. See our JFrog Xray page and supply chain security service.

3. Keep secrets out of code

• Turn on secret detection in every pipeline.
• Block secrets at push time where your platform supports it. GitLab’s secret push protection (Ultimate) blocks keys and API tokens from being pushed.
• Use short-lived credentials and OIDC federation from CI to cloud providers instead of long-lived keys in CI variables.
• Store remaining secrets in a vault, scoped to protected branches and environments.
• Rotate any secret that has ever been committed, even if the commit was deleted.

4. Harden your build platform and runners

Your CI runners can read source code, secrets and signing material. Treat them as production systems. GitLab’s runner security guidance is a good baseline:

• Avoid Docker privileged mode. A privileged job can gain root on the host.
• Use the shell executor only for trusted builds, because jobs run with the runner user’s permissions.
• Prefer ephemeral runners, so each job gets a clean environment. With autoscaling, limit each VM to one build.
• Dedicate separate runners to privileged or deployment jobs and restrict them to protected branches.
• Place runners in their own network segment, block inbound SSH from the internet and filter access to cloud metadata endpoints.
• On shared runners, set the image pull policy to always rather than if-not-present.
• Patch runner hosts like any other server and remove stale SSH keys and credentials.

5. Prove how it was built: SLSA provenance

SLSA (Supply-chain Levels for Software Artifacts) defines a build track with increasing guarantees:

From the SLSA v1.2 specification (checked 13 October 2026).

• Set a target level per application. L2 is a sensible first goal.
• Generate provenance automatically. GitLab documents that GitLab Runner can produce a SLSA Level 2 compliant provenance statement for build artefacts.
• Verify provenance before deployment, not just generate it.
• Plan for L3 only where risk justifies it, because it needs isolated, hardened builders.

6. Sign what you release

• Sign container images and release artefacts.
• Verify signatures at deployment, for example with an admission controller in Kubernetes.
• Prefer keyless signing with short-lived certificates where available, so there is no long-lived signing key to steal.

Tool notes. On GitLab.com, GitLab documents Sigstore keyless signing with Cosign for container images and build artefacts using CI ID tokens. Self-Managed instances need a self-hosted Sigstore setup for the same approach.

7. Enforce, do not just report

Scanners that produce reports nobody reads add little protection.

• Make security scans mandatory through policy, not optional per project.
• Require security approval when a merge request introduces a high-severity finding.
• Track mean time to remediate by severity, and review it monthly.
• Give developers fixes, not just findings: upgrade paths, compliant versions, clear ownership.

Tool notes. GitLab Ultimate’s security policies (scan execution and merge request approval policies) turn scanning into a control. Our comparison of GitLab Premium vs Ultimate explains what each tier includes.

8. Be ready for the next incident

When a widely used package is compromised, speed matters more than perfection.

• Write a one-page playbook: who decides, who searches, who communicates.
• Be able to search all SBOMs and your repository manager for a package and version within an hour.
• Know how to block a package version centrally in your repository manager.
• Have a process to revoke and rotate CI tokens, deploy keys and cloud credentials quickly.
• Rehearse once a year with a tabletop exercise based on a real past incident.
• Record what you learned and update this checklist.

Where to start

If you can only do three things this quarter: route dependencies through a repository manager, generate SBOMs on every build, and harden your runners. Those three cover most of the practical risk and none requires a premium tier.

When you are ready to compare repository managers, read our Artifactory vs Nexus comparison. For help putting this checklist into practice, see our DevSecOps services.

Spreeze is an authorised GitLab partner (Open track) and a JFrog partner. We can assess your current pipeline against this checklist and quote any licences needed in USD or ZAR (your choice). Request a quote.

GITLAB is a trademark of GitLab Inc. JFrog and Artifactory are trademarks of JFrog Ltd. Other names are trademarks of their respective owners.