Software Supply Chain Security Checklist: Build a Practical DevSecOps Control Baseline

Overview

A software supply chain includes every component and process involved in delivering software: developer workstations, source repositories, third-party packages, build systems, deployment credentials, container images, infrastructure definitions, and runtime environments. A weakness in any of these areas can affect the integrity, confidentiality, or availability of the final product.

A useful DevSecOps checklist should answer four questions:

• Can we identify what goes into a release? This includes direct and transitive dependencies, base images, build tools, generated files, and configuration.
• Can we verify how it was built? Build logs, provenance records, source references, and controlled runners help establish what happened during production.
• Can we prevent unauthorized changes? Repository protections, least-privilege credentials, signed artifacts, and policy gates reduce opportunities for tampering.
• Can we respond when a component or credential is compromised? Ownership, revocation procedures, inventory, and incident runbooks make response more deliberate.

Do not attempt to implement every control at once. Start by mapping the path from a code change to a production deployment. Document the systems involved, identify trust boundaries, and assign an owner for each control. For broader CI/CD process review, use this CI/CD pipeline checklist alongside the supply chain controls below.

Checklist by scenario

1. Source code and repository access

• Require individual accounts rather than shared credentials.
• Apply least privilege to repository, organization, and deployment access.
• Protect important branches with required reviews and status checks.
• Restrict who can modify workflow definitions, release configuration, and security policies.
• Enable commit signing or another reviewable method of verifying author intent where it fits the team’s workflow.
• Review inactive users, automation accounts, deploy keys, and access tokens on a defined schedule.
• Record ownership for each repository, critical workflow, and release process.

Repository controls are not a substitute for code review. Reviewers should pay particular attention to changes that alter build scripts, dependency manifests, workflow permissions, container definitions, or infrastructure code.

2. Dependencies and third-party code

• Maintain a machine-readable inventory of direct and transitive dependencies.
• Use dependency scanning to identify known issues, abandoned components, license concerns, and unexpected changes.
• Pin versions or otherwise constrain acceptable dependency resolution in reproducible build paths.
• Separate routine updates from urgent remediation so both can be tracked.
• Define who assesses a finding and who can accept, mitigate, or reject the associated risk.
• Prefer approved package registries or controlled mirrors for critical production builds.

An SBOM is useful only when it is tied to a release and can be searched when a dependency, image, or advisory needs investigation. Treat it as a release record, not merely a file generated at the end of a pipeline. Evaluate CI/CD pipeline challenges if dependency checks are causing unexplained delays or inconsistent results.

3. Build runners and CI/CD workflows

• Use isolated or appropriately constrained runners for untrusted and trusted workloads.
• Limit workflow permissions by default and grant only the access needed for each job.
• Separate build, test, signing, and deployment responsibilities where practical.
• Keep runner images, build tools, actions, plugins, and scripts under change control.
• Prevent secrets from being printed in logs, passed through untrusted pull requests, or stored in source code.
• Retain enough build metadata to connect a release to its source revision, workflow, runner context, and inputs.
• Review external actions, plugins, and reusable workflows before allowing them into sensitive pipelines.

A fast pipeline is not necessarily a trustworthy pipeline. Include security controls in the normal delivery path, but design them so failures provide an actionable reason and an owner rather than a generic blocked status.

4. Artifacts, images, and releases

• Publish artifacts to controlled registries with clear ownership and retention rules.
• Use immutable version identifiers for release artifacts where possible.
• Generate an SBOM for relevant release outputs and retain it with the release record.
• Sign artifacts or container images when consumers need a way to verify origin and integrity.
• Record build provenance, including source revision and the process that produced the artifact.
• Restrict who can publish, replace, promote, or delete production artifacts.
• Make deployment systems verify the expected artifact identity before promotion.

Artifact signing has the greatest practical value when verification is enforced at a meaningful trust boundary. A signature that is generated but never checked may provide useful evidence, but it does not by itself prevent an untrusted artifact from being deployed.

5. Secrets and deployment environments

• Store secrets in an approved secret manager rather than repository files or unprotected pipeline variables.
• Use short-lived, narrowly scoped credentials where the platform supports them.
• Separate credentials by environment, service, and purpose.
• Rotate credentials after exposure, ownership changes, or material workflow changes.
• Audit privileged deployment actions and administrative changes.
• Apply policy checks to infrastructure and deployment configuration before production changes.
• Define a tested process for revoking credentials and stopping a compromised release.

For Kubernetes-based delivery, include image provenance, admission policies, service account permissions, and namespace boundaries in the review. The Kubernetes troubleshooting decision tree can help distinguish deployment failures from configuration or runtime issues during an investigation.

6. Response and operational readiness

• Keep a current inventory of repositories, pipelines, artifacts, dependencies, and production owners.
• Define escalation paths for compromised credentials, malicious packages, and suspicious releases.
• Document how to quarantine an artifact, pause promotion, revoke access, and rebuild from a known state.
• Record decisions, affected versions, and evidence during an incident.
• Feed lessons from incidents and near misses back into pipeline and platform controls.

Connect this work to an incident response runbook so supply chain events have clear roles and communication steps.

What to double-check

Before declaring the baseline complete, test the controls as an attacker or a rushed operator might encounter them:

• Can a pull request modify a workflow and gain access to production secrets?
• Can a contributor publish or replace a release artifact without an independent review?
• Can the team identify every production deployment’s source revision and build process?
• Does the SBOM describe the artifact that was actually deployed, rather than a later rebuild?
• Are scanner findings assigned, prioritized, and tracked to a decision?
• Can an exposed token be revoked without manually searching multiple systems?
• Do deployment policies verify both who initiated a release and what artifact is being deployed?
• Can a new engineer understand the control owner and exception process from the documentation?

Use a maturity model to sequence improvements. At a foundational level, establish ownership, access control, secret management, dependency visibility, and basic scanning. At an established level, add reproducible builds, SBOM retention, signed artifacts, provenance, stronger runner isolation, and policy enforcement. At an advanced level, continuously verify controls, reduce long-lived credentials, test recovery procedures, and measure exceptions and remediation time. These tiers are a planning aid, not a compliance rating.

Common mistakes

• Scanning without ownership: A tool can identify a concern, but a team must decide what happens next.
• Generating SBOMs without release linkage: An inventory is difficult to use if it cannot be connected to a specific artifact or deployment.
• Signing without verification: Production systems should check the trust information they are expected to rely on.
• Giving pipelines broad permissions: Convenience can turn a compromised job into a path to unrelated systems.
• Trusting pinned versions forever: Pinning improves predictability, but it also requires a managed update process.
• Blocking every finding immediately: Unprioritized gates create workarounds and alert fatigue. Define severity, exceptions, and service-level expectations first.
• Ignoring build infrastructure: Protecting application code while leaving runners, plugins, or registries unmanaged leaves a major gap.
• Skipping recovery exercises: A documented response that has never been tested may fail under pressure.

When to revisit

Review this checklist before seasonal planning cycles, major platform changes, and significant workflow or tool changes. A new source-control model, CI/CD provider, package registry, artifact repository, cloud account, Kubernetes platform, or internal developer platform should trigger a focused review of trust boundaries and permissions.

Revisit the baseline after a security incident, a material dependency event, a change in deployment ownership, or the introduction of a new build framework. Also schedule recurring checks for inactive accounts, privileged tokens, runner images, external workflow components, dependency exceptions, artifact verification, and SBOM availability.

A practical next step is to create a table with five columns: control, owner, evidence, exception, and next review date. Start with the path used by your most important production service. Mark each control as implemented, partial, or missing; assign no more than a small set of improvements for the next cycle; then repeat the review as the delivery system changes. For platform teams, this baseline can become a self-service standard in an internal developer platform roadmap, provided teams can see what the controls do and how to request an exception.