How to Secure the Software Delivery Pipeline

What Is CI/CD Supply Chain Security?

In March 2025, attackers altered one popular GitHub Action and exposed secrets in the repositories that trusted it. CI/CD supply chain security protects the build pipeline and every dependency and artifact that flows through it.

CI/CD stands for continuous integration and continuous delivery. CI/CD supply chain security is the set of practices that protect both the automated build, test, and deploy pipeline and every third-party component, dependency, and artifact that flows through it. This guide covers CI/CD supply chain security best practices you can apply step by step.

It helps to separate two ideas that often get merged. CI/CD (pipeline) security means protecting the pipeline itself: the runners, the config, and the identities that run your builds. Software supply chain security means protecting what the pipeline consumes and produces: your open source dependencies, your build artifacts, and the records that prove where they came from.

Both belong to the same problem. The pipeline and the components moving through it are one continuous attack surface, not two separate concerns.

Most pipelines ship with very few security controls turned on by default, so teams have to add them on purpose.

Why does CI/CD supply chain security matter?

The pipeline is high-value because it has reach. A single compromised build step can ship altered code to every downstream user at once. That reach is the real reason this topic gets attention.

The data shows how much of modern risk now flows through third parties. According to Verizon's 2026 breach report, breaches involving a third party now account for 48% of all breaches, with third-party involvement up 60% year over year. That points to scope: the components you did not write are now a large part of your exposure.

Exploited software is also a common way in. Mandiant's M-Trends 2026 reports that exploits were the most common initial infection vector for the sixth consecutive year, at 32% of investigations with an identified vector. The takeaway is where to focus effort, not a reason to panic.

A few well-known incidents show the pattern:

• SolarWinds: attackers modified the build process so a trusted software update carried malicious code.
• Codecov: a tampered build script quietly collected secrets from many downstream projects.
• tj-actions/reviewdog: a popular GitHub Actions workflow was altered to leak credentials from other projects that used it.
• Shai-Hulud: a self-spreading npm worm moved between packages by stealing publish tokens.

One more thread is worth pulling now. Scanners raise a huge number of alerts, but only a narrow slice reflect risk that can be exploited. That gap between volume and real risk shapes the prioritization steps later in this guide.

Where are CI/CD pipelines most vulnerable?

Weak spots line up with pipeline stages: source, build, dependencies, artifacts, and deploy. A useful map is the OWASP Top 10 CI/CD Security Risks, published by the Open Worldwide Application Security Project. It names the common failure modes so you can check each one.

The table below maps a few of those risks to where they hit and what they look like in practice.

One gap most checklists miss is visibility. Teams often have build pipelines and repositories that no one is tracking, sometimes called shadow pipelines or rogue repositories. You cannot protect what you cannot see, so it helps to discover shadow pipelines before you try to harden them.

What are CI/CD supply chain security best practices?

The steps below form a checklist you can work through in order. The first several are table-stakes hygiene that most mature teams already do.

The later steps are where many teams still have gaps: prioritizing by real risk, remediating safely, proving integrity, and handling AI-generated code. Most guides stop at "scan." This one continues through prioritize, remediate, and prove.

How do you secure secrets and credentials in CI/CD?

Never hardcode secrets in code, config, or pipeline files. Store them in a secrets manager or vault, and pull them at run time.

Prefer short-lived, auto-rotating credentials over long-lived tokens. OpenID Connect (OIDC) lets a pipeline request a temporary token for each job instead of holding a standing key. Shorter lifetimes mean a leaked value is useful for less time.

Scan for leaked secrets before commits land and across git history. A secret that was committed once stays in history until you remove it, even if a later commit deletes it.

How do you enforce least privilege in the pipeline?

Give each pipeline identity and service account only the access it needs, and nothing more. Require multi-factor authentication (MFA) for the humans who can change pipelines or approve deploys.

Separate duties for production. The person or system that builds should not be the only check on what ships to production.

Keep an inventory of pipeline identities and update it as people join, move, and leave. Extend this to the source repositories, not just the runner, since repo settings are part of the attack surface. Repository security posture management covers the enforcement layer for repo config, such as branch protection and required checks.

How do you find and harden every build pipeline?

Start by finding every pipeline you have, including the ones no one registered. An accurate inventory is the base for every other control here.

Harden where builds run. Use ephemeral runners, which are fresh, short-lived build environments that are destroyed after each job, so nothing carries over between builds. Isolate them from production networks.

Treat pipeline configuration as code. Pipeline-as-code files should get the same review, testing, and approval rigor you apply to application code.

How do you control and pin dependencies?

Govern the third-party and open source components you pull in. Most modern applications are mostly open source, so this is where much of the risk lives.

Pin your dependencies with lockfiles so every build uses the exact same versions. Pin third-party GitHub Actions to a specific commit SHA, not a moving tag, so the code you reviewed is the code that runs. Pull packages from trusted or private registries rather than fetching whatever is newest.

Pinning is still uneven in practice. Datadog's 2026 DevSecOps research found that 71% of organizations never pin the hash for any of their GitHub Actions, and only 4% pin the hash for all marketplace actions. Pinning by hash is a straightforward best practice that closes that gap.

Watch how deep your dependency tree goes. Endor Labs research finds that 95% of open source vulnerabilities are transitive, meaning they live in the dependencies of your dependencies rather than the packages you chose directly. A simple dependency graph is not enough; you need to see the full tree.

Which scans should run in the pipeline?

Layer the scan types so each covers a different risk, and run them in pull requests so problems surface early. "Shift left" simply means running these checks while code is still in a pull request, not after release, so fixes are cheaper.

• SCA (software composition analysis): finds known vulnerabilities in your open source dependencies.
• SAST (static application security testing): analyzes your first-party source code for security bugs.
• DAST (dynamic application security testing): tests a running application for issues you can only see at run time.
• IaC (infrastructure as code) scanning: checks config files for insecure cloud and infrastructure settings.

Gate builds on the results that matter. Scanning creates volume; the next step turns that volume into signal.

How do you prioritize pipeline findings?

Scanning surfaces far more findings than any team can fix, and most are never exploited. J.P. Morgan's Patchmageddon analysis reports that only 1.5–2.0% of reported vulnerabilities are exploited each year. Chasing every raw CVE number wastes effort on findings that pose no real risk.

Combine several signals to rank what to fix first. There are five ways to prioritize vulnerabilities worth knowing:

• CVSS (Common Vulnerability Scoring System): a base severity score for a vulnerability.
• EPSS (Exploit Prediction Scoring System): the estimated probability a vulnerability will be exploited soon.
• KEV (Known Exploited Vulnerabilities): a public list, maintained by CISA, of flaws already exploited in the wild.
• SSVC (Stakeholder-Specific Vulnerability Categorization): a decision model that turns those inputs into an action.
• Reachability analysis: checks whether the vulnerable function is executed in your app.

Reachability is the strongest filter. Endor Labs research finds that 90.5% of vulnerabilities are unreachable at the function level, meaning the risky code never runs in your application. When you prioritize by reachable risk, you focus on the small set that matters and cut the noise that causes alert fatigue. Lower noise is a security control, not just a convenience, because real issues are easier to spot when the queue is short.

How do you remediate without breaking the build?

Finding a real issue is only half the job. Teams often stall on two questions: which upgrade fixes it without breaking the build, and what to do when there is no clean upgrade.

Use upgrade impact analysis to pick the minimal safe version. It shows what changed between versions so you can choose the smallest change that resolves the issue.

When a full upgrade is not feasible, you can apply backported patches that fix the vulnerable code without changing the version you depend on. This matters because a patch being available does not mean it gets applied, and stalled upgrades leave known issues open.

How do you prove artifact integrity?

Produce a software bill of materials (SBOM) as a build artifact. An SBOM is a complete list of the components in your software, usually in the CycloneDX or SPDX format.

Pair it with a VEX (Vulnerability Exploitability eXchange) document. A VEX records which listed vulnerabilities are exploitable in your product, so consumers do not chase issues that do not apply.

Sign your artifacts and generate provenance. Provenance is a verifiable record of where an artifact came from and how it was built. Tools like Sigstore and cosign handle signing, in-toto records build steps, and SLSA (Supply-chain Levels for Software Artifacts) defines how strong that record is. This is operational, not just paperwork: when the next malicious-package wave hits, an accurate SBOM lets you find affected builds in minutes. For the full workflow, see this guide to implementing software supply chain security.

How do you handle AI-generated code in the pipeline?

AI coding assistants now write a large share of code and suggest dependencies. Some of those suggestions are risky, and some point to packages that do not exist. According to our State of Dependency Management report, 80% of AI-suggested dependencies contain risks.

Add two controls. Verify that every AI-suggested dependency exists in a real registry and is safe before it gets merged.

Route AI-authored changes through the same gates as human code. That means the same scanning, reachability checks, and remediation steps, with no exceptions for machine-written code.

How do you monitor and threat-model the pipeline?

Build telemetry and logging into every stage so unusual behavior is detectable. If a build suddenly reaches a new network or a new identity runs a job, you want a record of it.

Write an incident-response plan for the pipeline itself. Decide in advance how to rotate credentials, rebuild from a known-good state, and verify artifacts.

Threat-model the pipeline on a regular schedule. Walking through each stage and asking "what could go wrong here" is a cheap way to find blind spots.

Which frameworks apply to CI/CD supply chain security?

Several public frameworks describe what good looks like, and many teams are expected to align to them. The table below maps the main ones to your pipeline.

NIST is the U.S. National Institute of Standards and Technology, and CISA is the U.S. Cybersecurity and Infrastructure Security Agency. Use these as a coverage checklist, not a substitute for the hands-on controls above.

How does Endor Labs secure the CI/CD supply chain?

Endor Labs maps directly to the harder steps in this guide, and the framing is developer impact first: less noise, fewer interruptions, and faster fixes.

Endor Labs uses full stack reachability to verify which findings are reachable and exploitable across code, dependencies, and containers. Full stack reachability cuts up to 92% of the noise, so developers spend time on the small set of issues that can run in the application rather than a long queue of CVEs.

For remediation, Endor Labs shows safe upgrade paths with upgrade impact analysis, and Endor Patches applies backported fixes in a single pull request when a full upgrade is not an option. That keeps fixes moving on the team's own timeline.

Endor Labs also generates accurate SBOMs and VEX that annotate which components are non-reachable or non-exploitable, tying provenance back to real risk.

Frequently Asked Questions

What is the difference between CI/CD security and software supply chain security?

CI/CD security protects the pipeline itself, such as runners, config, and identities, while software supply chain security protects what the pipeline consumes and produces, such as dependencies and build artifacts. They overlap and are best treated as one continuous attack surface.

What are the OWASP Top 10 CI/CD security risks?

They are a published list of the most common pipeline weaknesses, including insufficient flow control, poisoned pipeline execution, dependency chain abuse, and poor credential hygiene. Teams use the list as a checklist to review each pipeline stage.

How do I decide which pipeline vulnerabilities to fix first?

Rank findings by combining severity (CVSS), exploit likelihood (EPSS), known exploitation (KEV), and a decision model (SSVC) with reachability analysis. Reachability is the strongest filter, since a vulnerability whose code never runs is far lower risk.

What is an SBOM, and how is it different from provenance?

An SBOM is a list of the components inside a piece of software, while provenance is a verifiable record of where an artifact came from and how it was built. One tells you what is inside; the other proves how it was made.

What are the SLSA build levels?

SLSA defines increasing levels of build integrity, from basic provenance at the lowest level to fully verified, tamper-resistant builds at the highest. Higher levels require stronger evidence that an artifact was built as claimed.

How does AI-generated code change CI/CD supply chain risk?

AI assistants can suggest dependencies that are risky or that do not exist in any real registry, which adds a new source of bad components. The fix is to verify AI-suggested dependencies before merge and route AI-authored code through the same security gates as human code.

Where should you start?

The progression is the point. See the whole pipeline, harden the basics, scan everything, then prioritize by reachable risk, remediate safely, and prove integrity with SBOMs and provenance.

You can start this week with a short sequence:

1. Inventory: list every pipeline and repository, including the ones no one registered.
2. Harden the basics: move secrets into a vault, tighten access, and pin dependencies and actions by hash.
3. Turn volume into signal: add scanning, then gate on reachable, exploitable risk instead of raw CVE counts.
4. Remediate and prove: apply safe upgrades or backported patches, and produce SBOMs with provenance.

The throughline is signal over noise: fix what can be exploited, and prove the rest. To see how full stack reachability and evidence-based remediation work on your own pipelines, book a demo.