Modern software is assembled as much as it is written. A production release may contain first-party code, open-source packages, container images, build actions, compilers, hosted services and artifacts created by automated pipelines. Each component can save time, but each also introduces a trust decision.
A useful software supply chain security checklist makes those decisions visible. It should help a team answer five questions: What are we using? Who can change it? How was it built? Can we verify what we received? What will we do when a component becomes unsafe?
This guide translates guidance from NIST, CISA, the Open Source Security Foundation and the SLSA project into a practical workflow. It is designed for small and mid-sized product teams that need meaningful controls without pretending they can eliminate all risk.
Key takeaways
• Start with an owner and an inventory; scanners cannot protect components nobody knows are in use.
• Protect source control and build systems separately. A clean repository does not prove that a released artifact was built safely.
• Generate an SBOM for every release, but connect it to vulnerability response and change management.
• Use provenance and signatures to verify where an artifact came from and how it was produced.
• Measure the time from a relevant advisory to a decision—not only the number of alerts generated.
What is the software supply chain?
The software supply chain is the network of people, systems and components involved in producing and delivering software. It begins before a developer writes code and continues after a release reaches users.
It commonly includes:
• source repositories and access controls;
• open-source and commercial dependencies;
• package registries and mirrors;
• development tools, plugins and build actions;
• continuous integration and delivery systems;
• secrets, signing keys and service accounts;
• compilers, builders and container base images;
• artifact repositories and distribution channels;
• update mechanisms and operational monitoring.
A compromise can enter at any layer. An attacker might take over a maintainer account, publish a malicious package, alter a build workflow, steal a signing key or replace an artifact after it is built. Accidental failures matter too: an unpinned dependency, expired certificate or undocumented build process can make a release unreliable without a deliberate attack.
NIST’s Secure Software Development Framework, or SSDF, treats secure development as a set of practices that can be integrated into different development lifecycles. CISA’s software supply-chain guidance addresses developers, suppliers and customers, emphasizing that security responsibilities span the whole relationship.
A checklist should produce evidence
Teams sometimes respond to supply-chain risk by buying another scanner. Scanning is useful, but a dashboard is not a control unless someone owns the findings, understands the scope and can act before risk reaches production.
A stronger checklist connects every control to evidence. Examples include:
• a current repository and dependency inventory;
• branch-protection settings and access-review records;
• approved package sources and exception decisions;
• reproducible build instructions;
• provenance attached to release artifacts;
• a software bill of materials linked to a specific version;
• signature-verification logs;
• a documented response to a relevant vulnerability.
Evidence makes the program testable. It also keeps the team from confusing configuration intentions with the state of a real release.
The TRACE framework
The UrleBird’s TRACE framework organizes supply-chain security into five linked layers:
| Layer | Purpose | Minimum evidence |
|---|---|---|
| T — Track | Know components, repositories, builders and owners | Inventory with owner and criticality |
| R — Restrict | Limit who and what can change source or pipelines | MFA, protected branches, reviewed permissions |
| A — Attest | Record how artifacts were produced | Build provenance and artifact digest |
| C — Check | Verify dependencies, releases and exceptions | Policy results, signatures, vulnerability decisions |
| E — Escalate | Respond when trust changes | Triage owner, deadline, rollback or mitigation record |
The layers are sequential. A team cannot reliably verify an artifact it does not track, and it cannot respond quickly if no owner is responsible for the decision.
. Track assets and assign ownership
Begin with a bounded inventory. Do not try to catalogue the entire company in one exercise. Select one internet-facing product or business-critical service and record:
• repositories that contribute code;
• production dependencies and major development dependencies;
• container base images;
• CI/CD workflows and reusable actions;
• build platforms and runners;
• artifact registries;
• signing and deployment identities;
• runtime environment and update channel;
• named service and security owners.
Add a criticality field. A package used only in local formatting deserves different treatment from a library that processes authentication data. Criticality helps the team prioritize reviews and set response deadlines.
Define the release boundary
Write one sentence that defines what the inventory covers. For example: “Everything required to build, sign, publish and deploy versioned artifacts for the customer API.” A clear boundary prevents gaps between development, platform and operations teams.
Record indirect dependencies
Direct dependencies are only the first layer. Package managers often install many transitive components. Capture the resolved dependency graph or lockfile used for the release, not just the short list in a manifest.
. Restrict dependency intake
Every new component should pass a small, repeatable intake decision. Ask:
1. Is the package from the expected registry and publisher?
2. Is the requested name protected against spelling or namespace confusion?
3. Is the exact version pinned or reproducibly resolved?
4. Is the project maintained, and are security issues handled?
5. Does its license fit the product’s intended use?
6. Does the package request installation scripts, network access or unusual privileges?
7. Is a simpler or already approved component available?
OpenSSF Scorecard can provide automated signals about an open-source project’s practices, such as review behavior, branch protection and risky workflows. Treat the score as evidence for a decision, not a universal pass/fail label. A low score can trigger review; a high score cannot guarantee that a package is safe.
Use controlled sources
Where practical, route packages through an approved registry, repository proxy or internal mirror. This creates a place to enforce policy and retain known versions. Block direct downloads in production builds unless a documented exception explains why they are necessary and how integrity is verified.
Pin with a maintenance plan
Pinning reduces surprise but can freeze vulnerabilities. Pair version pinning with automated update discovery and a review schedule. The goal is controlled change, not permanent immobility.
. Restrict source and pipeline changes
Protect repositories with phishing-resistant MFA where supported, least-privilege access and mandatory review for protected branches. Remove inactive accounts and restrict who can change branch rules, build workflows and release settings.
Pipeline files deserve special treatment because they can execute commands with elevated credentials. Require review from an appropriate owner when a change touches:
• CI/CD configuration;
• dependency or lock files;
• release scripts;
• container definitions;
• permissions or secrets;
• signing and publishing steps.
Avoid long-lived credentials in code or workflow files. Use short-lived workload identities where possible, scope tokens to the smallest necessary permissions and separate build credentials from production deployment credentials.
Isolate builds
A developer laptop is difficult to audit and may contain untracked tools or state. Important releases should run on controlled, ephemeral build infrastructure. Clean runners reduce the chance that one build influences the next and make the process easier to reproduce.
NIST SSDF recommends protecting the components of the development environment and maintaining the integrity of software releases. SLSA expresses related goals through progressively stronger guarantees around provenance and hosted, hardened build platforms.
. Attest how releases were built
Build provenance is verifiable information describing where, when and how an artifact was produced. It can connect a binary or container to its source revision, build process and builder identity.
At minimum, capture:
• artifact name and cryptographic digest;
• source repository and exact commit;
• build workflow or configuration;
• builder identity;
• build timestamp;
• relevant inputs and dependencies;
• the provenance format and signature.
SLSA’s build track provides an adoption path. Build Level 1 establishes that provenance exists. Higher levels add a hosted build platform, signed provenance and stronger isolation. Teams do not need to claim a maturity level immediately. They can begin by generating provenance for one release path and verifying it before deployment.
Sign the artifact, then verify it
Signing is incomplete if consumers never verify the signature. Add verification to the deployment gate and fail safely when the signature, digest or trusted identity does not match. Protect signing identities separately from ordinary build credentials and record key or identity rotation procedures.
. Generate and use an SBOM
A software bill of materials lists components associated with a software product. CISA’s 2026 minimum-elements guidance updates the baseline information and practices expected in an SBOM, including data that supports automated analysis.
Generate the SBOM from the resolved build or final artifact when possible. A manifest-only SBOM may omit transitive components or include packages that never entered the shipped product.
For each release, the SBOM should be:
• associated with an exact product version and artifact digest;
• stored in an accessible, protected location;
• machine-readable using a supported format;
• complete enough for the defined release boundary;
• regenerated when the release changes;
• available to the people responsible for vulnerability response.
Test whether the SBOM is useful
Choose a known component from a recent advisory and ask the team to identify affected products and versions using the SBOM data. Record how long the answer takes. If the team cannot produce a confident result, improve component identifiers, dependency relationships, release mapping or access to the records.
An SBOM is not proof that components are safe. It is a map that makes investigation and communication faster.
. Check releases with risk-based gates
A release gate should combine automated checks with human decisions for exceptions. Possible checks include:
• dependency and container vulnerability scanning;
• secret detection;
• malicious-package or reputation signals;
• license policy;
• artifact signature and provenance verification;
• SBOM generation and validation;
• policy checks on build configuration;
• evidence that required tests passed.
Do not block every release on every finding. Define severity, exploitability, exposure and business-impact criteria. A critical issue in an unreachable development tool may need a different response from a high-severity flaw exposed to the internet.
Every exception should record the affected component, reason, compensating control, owner, approval and expiry date. Exceptions without expiry dates tend to become invisible permanent policy.
. Escalate when trust changes
Prepare for the moment when a dependency, maintainer, registry or build system can no longer be trusted. The response playbook should answer:
• Who receives the alert?
• Which products and versions are affected?
• Can the team disable, patch, replace or isolate the component?
• Is a clean rebuild required?
• Which artifacts or credentials must be revoked?
• How will customers or partners be informed when necessary?
• What evidence will show the incident is contained?
Track time to decision, not just time to alert. The useful metric is the period from receiving a relevant advisory to recording whether the product is affected and what action will follow.
Preserve a clean rebuild path
Document how to rebuild from a trusted source revision using controlled infrastructure. If a pipeline is compromised, merely rerunning it may reproduce the problem. Recovery may require rotating identities, rebuilding the environment, verifying inputs and publishing new signed artifacts.
A 30-day implementation plan
Week 1: map one release
• Select one critical service.
• Define its release boundary.
• Assign service and security owners.
• Inventory repositories, dependencies, builders and registries.
Week 2: close obvious access gaps
• Enforce MFA and protected branches.
• Review administrative and release permissions.
• Protect CI/CD files with mandatory review.
• Remove long-lived or over-scoped secrets where feasible.
Week 3: add release evidence
• Generate an SBOM from the build or artifact.
• Capture artifact digests and source revision.
• Generate provenance on a hosted build platform.
• Add signature and provenance verification to a staging deployment.
Week 4: test response
• Select one real dependency advisory.
• Use the SBOM to identify exposure.
• Record the decision and action.
• Run a clean rebuild and rollback exercise.
• Create the next 60-day backlog from the gaps.
Practical checklist
Use the following as a release review rather than a once-a-year questionnaire.
Track
☐ Product boundary, repositories and owner are recorded.
☐ Direct and transitive dependencies are inventoried.
☐ Builders, registries, base images and release identities are listed.
Restrict
☐ Repository and CI/CD administrators use strong MFA.
☐ Protected branches require review.
☐ Pipeline and dependency-file changes receive appropriate review.
☐ Build and deployment credentials are short-lived and least-privileged where possible.
Attest
☐ The final artifact has a cryptographic digest.
☐ Provenance identifies source, builder and build process.
☐ Important artifacts are signed by an approved identity.
Check
☐ An SBOM is generated for the exact release.
☐ Deployment verifies artifact identity and provenance.
☐ Vulnerability, secret and policy findings have documented decisions.
☐ Exceptions have owners and expiry dates.
Escalate
☐ The advisory and incident owner is known.
☐ Affected versions can be identified quickly.
☐ Revocation, rebuild, rollback and notification steps are documented.
☐ At least one response exercise has been completed.
Frequently asked questions
Is an SBOM enough for software supply chain security?
No. An SBOM improves visibility, but teams also need protected source control, controlled builds, verified artifacts, vulnerability decisions and a response process.
What is the difference between an SBOM and provenance?
An SBOM describes components associated with software. Provenance describes how an artifact was built, including its source and builder. They answer different questions and work best together.
Does SLSA certify that software has no vulnerabilities?
No. SLSA focuses on the integrity of the build and source supply chain. It does not prove that application logic is free of vulnerabilities.
Should every vulnerability block a release?
Not automatically. Apply documented criteria that consider severity, exploitability, exposure and business impact. Record time-limited exceptions and compensating controls.
How often should dependencies be reviewed?
Monitor continuously where practical, review alerts on a defined schedule and reassess critical dependencies when versions, maintainers, ownership or threat information changes.
