What Is DevSecOps? A Practical Guide to Securing CI/CD and the Software Supply Chain

Quick summary

DevSecOps is the practice of integrating security into the whole software development lifecycle: design, coding, review, build, testing, release, deployment and operations. Instead of waiting until the end to run security checks, DevSecOps puts security controls into the pipeline so issues are found earlier and fixed faster.

The OWASP DevSecOps Guideline says the ideal goal is to detect security issues, whether design issues or application vulnerabilities, as fast as possible; it lists initial pipeline steps such as secrets scanning, SAST, SCA, IAST, DAST, IaC scanning, infrastructure scanning and compliance checks.¹ NIST SP 800-218, the Secure Software Development Framework, defines high-level secure development practices that can be integrated into any SDLC to reduce vulnerabilities, reduce impact and address root causes.²

In simple terms: DevSecOps means every commit, pull request, build and deployment should pass appropriate security checks.

What problem does DevSecOps solve?

Traditional security often happens late:

Finish code → finish tests → prepare release → security review → major issue found → deadline slips

This creates late fixes, release friction, secrets in repositories, vulnerable dependencies, insecure container images, infrastructure misconfigurations, unsigned artifacts and unclear production traceability.

DevSecOps changes the flow:

Secure design → secure coding → early scanning → controlled build
→ signed artifacts → policy-based deployment → runtime monitoring

What DevSecOps is not

Good DevSecOps balances risk reduction with developer usability.

Security layers in CI/CD

What NIST SSDF says

NIST SP 800-218 says SSDF is a set of secure software development practices that can be integrated into any SDLC implementation.²

Small teams do not need to implement everything on day one, but SSDF is a useful roadmap.

What OWASP DevSecOps recommends

OWASP DevSecOps Guideline focuses on secure pipelines. It lists initial controls such as secrets scanning, SAST, SCA, IAST, DAST, IaC scanning, infrastructure scanning and compliance checks.¹

Practical order:

secrets scanning → dependency scanning → basic SAST → container/IaC scanning
→ SBOM/signing → DAST → runtime monitoring

SAST, SCA, DAST and IAST

SAST analyzes source code or bytecode without running the application. It is useful for detecting injection patterns, unsafe API use, weak validation and insecure coding patterns.

SCA checks dependencies, package versions, CVEs and licenses. It should run on pull requests and on a schedule because new CVEs appear after merge.

DAST tests a running application from the outside. It is useful for runtime auth/config issues, missing security headers, exposed endpoints, XSS/SQLi, CORS, TLS and session problems.

IAST observes the running application during tests. It provides richer runtime context but requires deeper integration.

Secrets scanning should come first

Leaked secrets are common and dangerous. One leaked cloud key may allow data access, resource creation or deployment.

Scan for API keys, cloud access keys, private keys, database URLs, JWT secrets, OAuth client secrets, webhook secrets, npm/PyPI/Docker tokens and SSH keys.

Implementation:

pre-commit hook
  ↓
pull request scan
  ↓
protected branch gate
  ↓
scheduled full-repo scan
  ↓
secret rotation playbook

Tools include Gitleaks, TruffleHog, GitHub secret scanning or internal scanners.³ If a real secret is found, deleting the commit is not enough. Revoke and rotate the secret.

Dependency security and lockfiles

Modern software depends heavily on third-party packages. DevSecOps must manage lockfiles, package registries, dependency updates, CVE triage, licenses, provenance, typosquatting and abandoned packages.

Checklist:

• use lockfiles;
• avoid unreviewed automatic upgrades for production dependencies;
• use Dependabot, Renovate or similar automation;
• scan dependencies on PRs;
• fail pipeline on exploitable critical CVEs unless an exception exists;
• generate SBOMs;
• track direct and transitive dependencies;
• use private registry/cache where needed.

What is SBOM?

SBOM means Software Bill of Materials: a list of software components inside an artifact or product. Common formats include CycloneDX and SPDX.⁴⁵

Pipeline example:

Build image
  ↓
Generate SBOM
  ↓
Scan SBOM
  ↓
Attach SBOM to release
  ↓
Store in artifact registry

SBOMs help with CVE response, license audits, compliance and dependency traceability.

Software supply chain security and SLSA

DevSecOps must protect the software supply chain: source, dependencies, build systems, artifacts, registries and deployments.

SLSA stands for Supply-chain Levels for Software Artifacts. The SLSA site describes it as a security framework, checklist of standards and controls to prevent tampering, improve integrity and secure packages and infrastructure.⁶

SLSA helps answer:

• was this artifact built from the expected source?
• was the build isolated and trustworthy?
• was provenance generated automatically?
• who can change the build pipeline?
• was the artifact modified after build?

Practical target:

Clear source commit
  ↓
Trusted build runner
  ↓
Provenance generated
  ↓
Artifact signed
  ↓
Verified before deployment

Artifact signing and provenance

Recommended controls:

• sign container images;
• sign binaries/packages;
• generate provenance;
• verify signatures before deployment;
• do not deploy unsigned images;
• avoid mutable latest tags in production;
• pin by digest.

Sigstore provides an ecosystem for artifact signing, and Cosign is commonly used for signing container images and artifacts.⁷⁸

Policy logic:

IF image.signature.valid == true
AND image.provenance.builder == "trusted-ci"
AND image.source.repo == "org/app"
AND image.source.branch == "main"
THEN allow deploy
ELSE block

OIDC instead of long-lived cloud keys

CI/CD should avoid storing long-lived cloud access keys whenever possible. Many CI platforms support OIDC federation, where the workflow exchanges its identity for a short-lived cloud token.

GitHub describes OIDC in GitHub Actions as a way for workflows to request short-lived access tokens directly from cloud providers instead of storing long-lived credentials as GitHub secrets.⁹

Model:

GitHub Actions workflow
  ↓ OIDC token with repo/branch/environment claims
Cloud IAM trust policy
  ↓
Short-lived cloud token
  ↓
Deploy

IaC scanning

Infrastructure as Code is also code. Scan Terraform, Kubernetes manifests, Helm charts, Dockerfiles, CI workflows, cloud resource policies, security groups and IAM policies.

Common issues include public buckets, security groups open to 0.0.0.0/0, privileged containers, plaintext secrets, IAM wildcard *, Kubernetes pods running as root, missing resource limits and vulnerable base images. Tools include Trivy, Checkov, tfsec, kube-linter, kube-score and cloud-native scanners.¹⁰

CI/CD runner security

Build runners are high-value targets. If an attacker controls a runner, they may steal secrets, modify artifacts or inject malicious code.

Checklist:

• use ephemeral runners where possible;
• separate trusted and untrusted PR runners;
• do not expose secrets to forked pull requests;
• reduce default token permissions;
• pin third-party actions by SHA when strictness is needed;
• avoid production builds on untrusted shared runners;
• clean workspaces after builds;
• restrict network egress;
• enforce branch protection;
• require review for workflow changes.

Policy gates: when should the pipeline fail?

Policy should be risk-based and context-aware.

Example DevSecOps pipeline

Developer commit
  ↓
pre-commit: secrets + lint
  ↓
Pull Request
  ↓
SAST + SCA + IaC scan + unit tests
  ↓
Code review + security review when needed
  ↓
Merge to main
  ↓
Build in trusted runner
  ↓
Generate SBOM
  ↓
Sign artifact + generate provenance
  ↓
Container scan
  ↓
Deploy staging
  ↓
DAST + smoke test
  ↓
Policy gate
  ↓
Deploy production
  ↓
Runtime monitoring + vulnerability response

Basic GitHub Actions example

name: security-ci

on:
  pull_request:
  push:
    branches: [main]

permissions:
  contents: read
  security-events: write
  id-token: write

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Secret scan
        uses: gitleaks/gitleaks-action@v2

      - name: SAST with Semgrep
        uses: semgrep/semgrep-action@v1
        with:
          config: p/owasp-top-ten

      - name: Filesystem and dependency scan with Trivy
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: fs
          scan-ref: .
          severity: CRITICAL,HIGH
          exit-code: "1"

For production, pin actions more strictly, use minimum permissions and split jobs by context.

DevSecOps for Kubernetes

If you deploy to Kubernetes, add image scanning, signature verification, admission controllers, Pod Security Standards, minimal RBAC, NetworkPolicy, secret management, resource limits, runtime detection and audit logs.

Deployment policy example:

Allow deployment only if:
- image is signed;
- provenance is valid;
- SBOM exists;
- no unapproved critical CVEs exist;
- namespace has NetworkPolicy;
- workload is not privileged;
- service account is not default;
- resource limits are configured.

DevSecOps for AI coding agents

AI coding agents can edit code, run commands, read logs, create PRs, update dependencies and sometimes deploy. DevSecOps must extend to AI-assisted workflows.

Checklist:

• do not put secrets in prompts;
• run agents in sandboxes or low-privilege users;
• use tool allowlists;
• log every tool call;
• require human review for agent-generated PRs;
• do not auto-merge agent code;
• do not let agents modify CI/CD workflows without review;
• do not let agents rotate or deploy production secrets;
• run SAST/SCA/IaC scanning on agent-generated code;
• require human approval for dangerous commands.

30/60/90-day roadmap

Days 1–30: foundations

• Enable branch protection.
• Require PR review.
• Enable MFA for Git hosting.
• Add secrets scanning.
• Add basic dependency scanning.
• Add baseline SAST.
• Define severity policy.
• Create a secret rotation playbook.
• Enable audit logs for Git and CI/CD.

Days 31–60: build and artifact security

• Separate trusted and untrusted runners.
• Reduce CI token permissions.
• Use OIDC instead of long-lived cloud keys.
• Standardize container builds.
• Generate SBOMs.
• Scan container images.
• Sign images with Sigstore/Cosign.
• Store artifacts by digest.
• Stop deploying latest.

Days 61–90: policy and runtime

• Verify signatures before deployment.
• Add deploy gates based on CVE/severity.
• Require IaC scanning.
• Add Kubernetes admission policy if using K8s.
• Run DAST on staging.
• Automate dependency updates.
• Add runtime security alerts.
• Build a security posture dashboard.
• Define vulnerability fix SLAs.

Metrics to track

Reference tooling

OpenSSF Scorecard can run through GitHub Action or CLI to assess risky open-source project practices, such as branch protection, dependency updates and token permissions.¹¹

FAQ

What is DevSecOps?

DevSecOps integrates security into the entire DevOps pipeline, from code and review to build, test, release, deploy and operations. The goal is early, automated and shared security responsibility.

How is DevSecOps different from AppSec?

AppSec focuses on application security. DevSecOps is broader: it integrates AppSec, software supply chain security, infrastructure security and runtime monitoring into DevOps pipelines.

Do we need to buy many tools?

No. Start with fundamentals: branch protection, MFA, secrets scanning, dependency scanning, basic SAST and a severity policy. Tools help only when findings have owners and are resolved.

Is SBOM mandatory?

Not always, but it is very useful for CVE response, license audit, compliance and supply chain visibility.

Is SLSA only for open source?

No. The SLSA site says it is for producers, consumers and infrastructure providers across open source and commercial supply chains.⁶

When should builds fail?

Fail builds for real secrets, exploitable critical CVEs, severe high-confidence SAST issues, dangerous IaC misconfiguration, unsigned release artifacts and clear policy violations. Do not fail every build for low-confidence warnings.

Conclusion

DevSecOps is the natural next step for IT and engineering teams that rely on cloud, open source, CI/CD and automation. The goal is not “scan for the sake of scanning.” The goal is to build a pipeline that detects serious issues early, protects build integrity, creates artifact evidence, reduces long-lived secrets and secures the software supply chain.

Start layer by layer: secrets scanning, SAST/SCA, IaC/container scanning, SBOM, artifact signing, OIDC for CI/CD, policy gates and runtime monitoring. Done well, DevSecOps helps teams ship faster with better control, fewer unresolved vulnerabilities and more trust in the software running in production.

References

Footnotes

1. OWASP Foundation. “OWASP DevSecOps Guideline.” https://owasp.org/www-project-devsecops-guideline/ ↩ ↩²

2. NIST. “SP 800-218, Secure Software Development Framework (SSDF) Version 1.1.” https://csrc.nist.gov/pubs/sp/800/218/final ↩ ↩²

3. Gitleaks. https://gitleaks.io/ ↩

4. CycloneDX. https://cyclonedx.org/ ↩

5. SPDX. https://spdx.dev/ ↩

6. SLSA. “Supply-chain Levels for Software Artifacts.” https://slsa.dev/ ↩ ↩²

7. Sigstore. https://www.sigstore.dev/ ↩

8. Sigstore Cosign documentation. https://docs.sigstore.dev/cosign/overview/ ↩

9. GitHub Docs. “OpenID Connect.” https://docs.github.com/en/actions/concepts/security/openid-connect ↩

10. Trivy. https://trivy.dev/ ↩

11. OpenSSF Scorecard. “Build better security habits, one test at a time.” https://securityscorecards.dev/ ↩