A secure DevSecOps pipeline does two jobs at once. It runs automated security checks on the code it builds, and it protects itself, because the system that builds and ships your software holds powerful credentials and has a direct path to production. Most teams do the first job and neglect the second. This guide covers both, in the order we'd work through them with a client.
TL;DR
- Treat the pipeline as a production system. NIST SP 800-204D maps CI/CD security measures to the Secure Software Development Framework (SSDF).
- Apply least privilege everywhere: deny by default, short-lived credentials, ephemeral runners, no privileged containers.
- Pin third-party actions and dependencies by commit hash, and review workflow YAML like application code.
- Sign artifacts and record provenance, so you can prove who built what, and how.
- Shifting left does not remove the security team. It changes their job to threat modelling, governance and guardrails.
Table of Contents
- What pipeline security actually covers
- Shift left, and what it does not mean
- A stage-by-stage view of the pipeline
- Lock down the pipeline itself
- Secrets: keep them out of the pipeline where you can
- Sign what you build and keep the provenance
- Put the supply chain on the same page as the pipeline
- Where scans fit without slowing developers down
- A 30-60-90 day plan
- Our perspective
- How Nexus can help
- FAQ
- Sources
What pipeline security actually covers
People use "DevSecOps pipeline" for two different things, and mixing them up causes gaps.
- Security in the pipeline: the scans and gates that check your code, dependencies, images and infrastructure definitions as they move toward release.
- Security of the pipeline: the protection of the build servers, runners, secrets, configuration files and permissions that make the first part possible.
The OWASP DevSecOps Guideline puts the second point plainly: the pipeline that builds and ships your software is itself a high-value target, because it holds credentials, executes code from many sources and touches production. The OWASP CI/CD Security Cheat Sheet adds that CI/CD increases an organization's attack surface, and that people, processes and technology can each be an avenue of attack.
NIST researchers make a similar point in the announcement for SP 800-204D: the integrity of the software supply chain matters as much as the application code. A single poisoned build can reach every downstream consumer. If your security spend goes entirely into scanning application code while Jenkins or your GitHub Actions setup is loosely configured, the money is protecting the wrong door.
Shift left, and what it does not mean
"Shift left" means moving security checks earlier in the lifecycle, to where a fix costs a developer minutes instead of an incident team days. In practice that means:
- Secrets detection and linting in the editor or at pre-commit.
- Static analysis (SAST) and dependency checks (SCA) on every pull request.
- Infrastructure-as-code scanning before anything is applied.
- Dynamic testing (DAST) against a staging build.
OWASP's guidance on catching vulnerabilities early lists security linters in the CI/CD pipeline as one way to flag insecure patterns and give developers actionable feedback during code review.
The common misreading is that developers now own security and the security team can step back. The OWASP DevSecOps Guideline overview calls this out as a misconception. Developers share responsibility, but skilled security professionals stay essential for threat modelling, governance and setting the guardrails that keep automated pipelines safe. For a wider look at where these checks sit in the whole process, see our guide to the secure software development lifecycle.
A stage-by-stage view of the pipeline
The table below shows where each control belongs. Not every team needs everything on day one, so start with the rows marked as foundations.
| Stage | Control | What it catches | Priority |
|---|---|---|---|
| Source | Branch protection, mandatory reviews, signed commits | Unreviewed or impersonated changes | Foundation |
| Source | Secrets scanning | Keys and tokens committed to repos | Foundation |
| Build | SAST and linting | Insecure code patterns | Foundation |
| Build | SCA and dependency pinning | Vulnerable or hijacked packages | Foundation |
| Build | Ephemeral, isolated runners | Attacker persistence between jobs | Foundation |
| Package | SBOM, signing, provenance | Tampered or unknown artifacts | Next |
| Test | DAST, container image scanning | Runtime and image weaknesses | Next |
| Deploy | Policy checks, scoped deploy identities | Misconfiguration, over-privileged releases | Next |
| Operate | Monitoring and incident response | Whatever slipped through | Always |
The last row matters. Pipeline controls reduce risk, they do not remove it. What you see in production feeds back into the pipeline, which is where security operations comes in.
Lock down the pipeline itself
Least privilege, deny by default
The OWASP CI/CD cheat sheet advises giving CI pipelines only the minimum resources and authorizations their function needs, with a deny-by-default stance toward pipeline identities and permissions. Concretely:
- Give each pipeline its own identity instead of a shared service account.
- Scope tokens to one repository and one task, and set the default workflow token to read-only.
- Use short-lived credentials issued at run time rather than long-lived keys stored in settings.
- Avoid privileged containers (the
--privilegedflag) in build jobs. - Use TLS 1.2 or greater between your source control platform and your CI/CD platform.
If your pipelines deploy to AWS, the deploy role is usually where least privilege slips first. Our AWS IAM checklist for DevOps and security teams walks through it.
Ephemeral runners
A runner that survives between jobs is a place for an attacker to hide. The OWASP DevSecOps Guideline recommends isolated runners that start clean and are destroyed after every job. Self-hosted runners that are reused across repositories, especially for public or forked pull requests, deserve the closest look.
Treat workflow files as code
Many teams treat CI/CD configuration files as static documents. They are executable code. The OWASP GitHub Actions Security Cheat Sheet focuses on preventing attacker-controlled code execution in workflows, and its advice fits any CI system:
- Protect workflow files with branch protection and require review from the security team, or a named code owner, on every change.
- Lint them for injection risks, such as untrusted input like a pull request title being interpolated straight into a shell command.
- Never run untrusted code from forks in a context that has access to secrets.
Pin what you depend on
Tags are mutable. If your workflow calls a third-party action by a tag such as v1, whoever controls that repository can move the tag to new code. The OWASP pipeline guidance recommends pinning dependencies and external actions by commit hash instead. It is a small change with a large effect, and automated update tools can keep pinned hashes current so the habit does not create a maintenance burden. Review the update before merging, since the point of pinning is to make changes deliberate.
The GitHub documentation on securing your build system frames the risk the same way: an attacker who can modify the build process can exploit everything the build produces.
Secrets: keep them out of the pipeline where you can
Secrets in pipelines fail in predictable ways: committed to a repo, printed in logs, stored for years in a CI variable, or shared across projects. Three habits fix most of it.
- Scan for them early. Run secrets detection at pre-commit and again on every pull request, so a leaked key is caught before it reaches shared history.
- Prefer identity over stored keys. Where your cloud provider and CI platform support federated identity (OIDC), the job proves who it is and receives a short-lived credential. There is nothing long-lived to steal.
- Rotate and scope. Anything that must be stored gets an owner, an expiry and the narrowest permission that works.
Our overview of cloud secrets management covers the storage options in more detail.
Sign what you build and keep the provenance
A software bill of materials (SBOM) tells you what is in an artifact. Signing and provenance show who built it and how, and that it has not been altered since. The OWASP guideline points to incidents such as SolarWinds, where attackers compromised the build process, as the reason this matters.
Keyless signing with Sigstore Cosign is where many teams are heading. Instead of guarding a long-lived private key, the CI job uses an OIDC token to show that a specific, verified pipeline run produced the artifact. That removes the risk of a leaked signing key. The matching step is verification: deploy only artifacts whose signature and provenance check out, otherwise the signature is decoration.
You do not need to reach the highest assurance level in a quarter. Start by signing release artifacts and generating provenance automatically, then raise the bar on build isolation as your risk calls for it.
Put the supply chain on the same page as the pipeline
NIST SP 800-204D, released on 12 February 2024, covers integrating software supply chain security into DevSecOps CI/CD pipelines for cloud-native applications. It points to automated checks such as SAST, DAST and SCA, together with granular access controls, and ties them to SSDF practices. That makes it a useful reference when a customer, auditor or regulator asks how your pipeline supports secure development.
The CISA Open Source Software Security Roadmap describes the malicious compromise of open source components as a category of risk that leads to downstream compromises, for example through a hijacked developer account. If you want the broader business view, read what supply chain cybersecurity is and where to start.
Where scans fit without slowing developers down
A pipeline that takes an hour and produces 400 findings will be bypassed. A workable pattern:
- On every pull request: fast checks only, such as secrets scanning, linting, dependency checks and a focused SAST ruleset. Aim for feedback in minutes.
- On merge to main: the fuller SAST run, container image scans and infrastructure-as-code checks.
- Nightly or pre-release: DAST, deeper dependency analysis and policy verification.
- Gates: block on a short list you have agreed on, for example exposed secrets and critical, exploitable findings. Report everything else without blocking, and review it on a schedule.
Tune the rules with the people who will live with them. A finding that is routinely dismissed teaches developers to ignore the tool. Track a few measures that show whether the pipeline is helping: time from finding to fix, how many builds are blocked and why, and how often the same class of issue returns.
A 30-60-90 day plan
First 30 days: close the obvious gaps
- Inventory pipelines, runners, service accounts and stored secrets.
- Turn on secrets scanning and branch protection for the repositories that matter most.
- Set default workflow tokens to read-only.
Days 31 to 60: harden the build
- Move to ephemeral runners and remove privileged containers.
- Pin third-party actions and dependencies by hash.
- Add SAST and SCA on pull requests, with a short blocking list.
Days 61 to 90: prove integrity
- Generate SBOMs, sign release artifacts and record provenance.
- Verify signatures at deploy time.
- Add deploy policy checks and connect pipeline alerts to your monitoring and incident response process.
The plan works for a five-person startup or a regulated enterprise. Only the size of each step changes.
Our perspective
The pattern we see most often is fragmentation. Application scanning sits with one vendor, cloud configuration with another, monitoring with a third, and compliance evidence is assembled by hand before an audit. Each piece may be fine. The gaps between them are where pipeline incidents live: a deploy role nobody owns, an alert that never reaches the person who can act, a scan result that never becomes a ticket.
Our view is that pipeline security works best when it is connected to the rest of your security and IT operations: cloud infrastructure management, real-time threat detection, incident response and compliance. A pipeline alert should reach the same team that watches production, and a control you build for engineering should double as evidence for frameworks like SOC 2, HIPAA, PCI-DSS or ISO 27001.
We also agree with the OWASP point about people. Automation does not replace experienced practitioners. It lets them spend time on threat modelling, guardrail design and reviewing the changes that matter, instead of triaging noise. Whatever you build or buy, ask who owns each control, who gets the alert at 2 a.m., and how fast they can act.
— Nick - Sr. Executive
How Nexus can help
If your team lacks the time or in-house specialists to run all of this, we cover cybersecurity, cloud solutions, managed IT services, compliance and risk, and data protection under one agreement with a single point of accountability, including 24/7 threat detection and incident response. You can see the full range on our services page, or start from the Nexus home page to talk to our team about your pipeline. We don't publish prices for these services.
For related reading, our guides on cloud-native security tools and enterprise cloud security governance are good next steps.
FAQ
What is the difference between DevOps and DevSecOps pipelines?
A DevOps pipeline automates building, testing and releasing software. A DevSecOps pipeline adds automated security checks and policy enforcement at each of those stages, and it also secures the pipeline's own runners, secrets and configuration. The goal is that security becomes a routine part of delivery instead of a late review.
Does shifting left mean developers handle all security?
No. Developers take on more of the day-to-day fixing, but the OWASP DevSecOps Guideline notes that skilled security professionals stay essential for threat modelling, governance and setting guardrails. Shifting left moves checks earlier. It does not remove the need for specialists.
Which CI/CD security controls should we implement first?
Start with the ones that close the biggest gaps cheaply: secrets scanning, branch protection with required reviews, read-only default tokens and pinning third-party actions by commit hash. Then add ephemeral runners and SAST and SCA on pull requests. Signing and provenance come next once the basics are stable.
Why pin actions by commit hash instead of version tag?
Tags can be moved, so a tag that pointed at safe code yesterday can point at malicious code today. A commit hash is fixed, which makes any change to a dependency a deliberate decision. OWASP's pipeline guidance recommends it for external actions and dependencies.
Sources
- NIST publishes SP 800-204D (CSRC)
- OWASP CI/CD Security Cheat Sheet
- OWASP GitHub Actions Security Cheat Sheet
- OWASP DevSecOps Guideline: CI/CD Pipeline Security
- OWASP DevSecOps Guideline: Overview
- OWASP DevSecOps Guideline: Artifact Signing and Provenance
- OWASP: Proactive Security, Catching Vulnerabilities Early in SDLC
- GitHub Docs: Best practices for securing your build system
- Sigstore Cosign on GitHub
- CISA Open Source Software Security Roadmap