{"slug":"zero-trust-devsecops-pipeline","title":"Building a Zero-Trust DevSecOps Pipeline: From Code to Production","description":"A comprehensive guide to implementing supply chain security, container signing, runtime protection, and policy-as-code in your CI/CD pipeline","date":"2025-01-20","author":"Elaph Hilful","thumbnail":"/blog-images/zero-trust-pipeline.svg","tags":["DevSecOps","Security","Supply Chain","Kubernetes","CI/CD"],"category":"Security","featured":true,"readTime":6,"htmlContent":"

The software supply chain has become a primary attack vector. From the SolarWinds compromise to the Log4Shell vulnerability, we've learned that security can't be an afterthought. Zero-Trust DevSecOps embeds security at every stage of the software delivery lifecycle — verifying every artifact, enforcing policies automatically, and detecting threats in real-time.

\n

In this guide, I'll walk through building a production-grade zero-trust pipeline that blocked 2,400+ CVEs in its first year.

\n

\"Zero-Trust

\n

The Zero-Trust Security Model for CI/CD

\n

Traditional security relies on perimeter defense — once inside the network, everything is trusted. Zero-Trust flips this: never trust, always verify. Applied to CI/CD, this means:

\n\n

Stage 1: Source Security — Signed Commits and SBOM Generation

\n

Security starts at the first keystroke. Require GPG-signed commits and generate Software Bill of Materials (SBOM) for every build:

\n
# .github/workflows/source-security.yml\nname: Source Security\non: [push, pull_request]\n\njobs:\n  verify-signatures:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v4\n        with:\n          fetch-depth: 0\n\n      - name: Verify commit signatures\n        run: |\n          git log --show-signature -1 HEAD | grep -q \"Good signature\"\n\n      - name: Generate SBOM\n        uses: anchore/sbom-action@v0\n        with:\n          format: spdx-json\n          output-file: sbom.spdx.json\n\n      - name: Upload SBOM as attestation\n        uses: actions/attest-sbom@v1\n        with:\n          subject-path: sbom.spdx.json\n
\n

Stage 2: Build Security — SAST/DAST and Dependency Scanning

\n

The build stage is where we catch vulnerabilities before they reach a container:

\n
# .github/workflows/build-security.yml\njobs:\n  security-scan:\n    runs-on: ubuntu-latest\n    steps:\n      - name: SAST - Semgrep Analysis\n        uses: returntocorp/semgrep-action@v1\n        with:\n          config: >-\n            p/security-audit\n            p/secrets\n            p/owasp-top-ten\n\n      - name: Dependency Audit\n        run: |\n          npm audit --audit-level=high\n          # Generate vulnerability report\n          trivy fs --severity HIGH,CRITICAL --format sarif .\n\n      - name: Secret Detection\n        uses: trufflesecurity/trufflehog@main\n        with:\n          extra_args: --only-verified\n
\n

Key Insight: Fail Fast, Fix Fast

\n

The critical principle is fail fast. Don't let vulnerable code progress through the pipeline. Set exit-code: 1 on security scans so builds break immediately when critical issues are found.

\n

Stage 3: Registry Security — Image Signing with Sigstore

\n

Container image signing with Sigstore/Cosign provides cryptographic proof of image provenance:

\n
# .github/workflows/image-sign.yml\njobs:\n  build-and-sign:\n    runs-on: ubuntu-latest\n    permissions:\n      contents: read\n      id-token: write # Required for keyless signing\n      packages: write\n\n    steps:\n      - name: Build container image\n        run: |\n          docker build -t ghcr.io/${{ github.repository }}:${{ github.sha }} .\n\n      - name: Push to registry\n        run: |\n          docker push ghcr.io/${{ github.repository }}:${{ github.sha }}\n\n      - name: Sign image with Cosign (keyless)\n        uses: sigstore/cosign-installer@v3\n      - run: |\n          cosign sign --yes \\\n            ghcr.io/${{ github.repository }}:${{ github.sha }}\n\n      - name: Scan with Trivy\n        uses: aquasecurity/trivy-action@master\n        with:\n          image-ref: ghcr.io/${{ github.repository }}:${{ github.sha }}\n          severity: CRITICAL,HIGH\n          exit-code: 1\n          format: sarif\n
\n

Why Keyless Signing?

\n

Traditional signing requires managing private keys — which become their own security liability. Sigstore's keyless signing uses short-lived certificates tied to OIDC identity (your GitHub Actions workflow identity). The signatures are recorded in a tamper-proof transparency log (Rekor), providing immutable audit trails.

\n

Stage 4: Deployment Security — OPA Gatekeeper Policy Gates

\n

Before any workload reaches the cluster, OPA Gatekeeper enforces organizational policies:

\n
# policies/require-signed-images.rego\npackage kubernetes.admission\n\n# Deny unsigned container images\ndeny[msg] {\n    container := input.request.object.spec.containers[_]\n    not has_valid_signature(container.image)\n    msg := sprintf(\"Image %v must be signed with Cosign\", [container.image])\n}\n\n# Require images from approved registries only\ndeny[msg] {\n    container := input.request.object.spec.containers[_]\n    not approved_registry(container.image)\n    msg := sprintf(\"Image %v not from approved registry\", [container.image])\n}\n\n# Enforce non-root containers\ndeny[msg] {\n    container := input.request.object.spec.containers[_]\n    not container.securityContext.runAsNonRoot\n    msg := \"All containers must run as non-root\"\n}\n\napproved_registry(image) {\n    startswith(image, \"ghcr.io/myorg/\")\n}\n
\n

Deploy the constraint template:

\n
apiVersion: templates.gatekeeper.sh/v1\nkind: ConstraintTemplate\nmetadata:\n  name: requiresignedimages\nspec:\n  crd:\n    spec:\n      names:\n        kind: RequireSignedImages\n  targets:\n    - target: admission.k8s.gatekeeper.sh\n      rego: |\n        package requiresignedimages\n        violation[{\"msg\": msg}] {\n          container := input.review.object.spec.containers[_]\n          not startswith(container.image, \"ghcr.io/myorg/\")\n          msg := \"Only signed images from approved registries allowed\"\n        }\n
\n

Stage 5: Runtime Security — Falco Threat Detection

\n

Even with perfect build-time security, runtime threats exist. Falco monitors kernel syscalls for anomalous behavior:

\n
# falco-custom-rules.yaml\n- rule: Unexpected Process in Container\n  desc: Detect processes not in the expected list\n  condition: >\n    spawned_process and container and\n    not proc.name in (node, npm, python, java) and\n    not proc.pname in (containerd-shim)\n  output: >\n    Unexpected process spawned in container\n    (user=%user.name command=%proc.cmdline container=%container.name)\n  priority: WARNING\n\n- rule: Write to /etc from Container\n  desc: Detect writes to /etc directory in containers\n  condition: >\n    open_write and container and fd.directory = /etc\n  output: >\n    Write to /etc detected in container\n    (user=%user.name file=%fd.name container=%container.name)\n  priority: ERROR\n\n- rule: Crypto Mining Detection\n  desc: Detect potential cryptocurrency mining\n  condition: >\n    spawned_process and container and\n    (proc.name in (xmrig, minergate, minerd) or\n     proc.args contains \"stratum+tcp\")\n  output: >\n    Potential crypto mining detected\n    (process=%proc.name args=%proc.args container=%container.name)\n  priority: CRITICAL\n
\n

Results: Security at Scale

\n

After implementing this pipeline for a fintech platform:

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
MetricBeforeAfter
CVEs reaching production~200/year0
Mean time to remediation30 days< 4 hours
Compliance audit findingsMultipleZero
Supply chain incidentsUntrackedZero
Developer frictionHigh (manual reviews)Low (automated gates)
\n

Key Lessons Learned

\n
    \n
  1. \n

    Shift left, but don't shift blame: Provide developers with fast feedback and auto-fix suggestions, not just failures.

    \n
    2. \n
  2. \n

    Policy-as-code is non-negotiable: If a security rule isn't codified, it doesn't exist. Human review doesn't scale.

    \n
    3. \n
  3. \n

    Runtime detection is your last defense: Build-time security catches known vulnerabilities; runtime security catches novel attacks.

    \n
    4. \n
  4. \n

    Transparency logs create accountability: Every artifact's provenance is recorded immutably — critical for incident response and compliance.

    \n
    5. \n
  5. \n

    Automate compliance evidence: SOC 2 and PCI-DSS audits become simple when every security control generates machine-readable evidence.

    \n
    6. \n
\n

Getting Started

\n

Start with the highest-impact, lowest-friction controls:

\n
    \n
  1. Week 1: Enable Trivy container scanning in CI (catches 80% of known CVEs)
    2. \n
  2. Week 2: Add Cosign image signing (establishes provenance)
    3. \n
  3. Week 3: Deploy OPA Gatekeeper with basic policies (prevents misconfigurations)
    4. \n
  4. Week 4: Install Falco for runtime detection (catches novel threats)
    5. \n
\n

The goal isn't perfection on day one — it's continuous improvement with automated guardrails that make the secure path the easy path.

"}