Skip to main content

ci-cd Pipeline Security: A Practical DevSecOps Guide

Your ci-cd pipeline is the fastest route for code to reach production---and the most attractive target for attackers. The GhostAction attack in early 2025 compromised a widely-used GitHub Action, exfiltrating secrets from thousands of repositories. According to Qualys research, 68% of organizations have now implemented DevSecOps, but technical complexity (41%), resource constraints (35%), and cultural resistance (38%) remain significant challenges. Kubo provides a ci-cd foundation with security built in, and the practices in this article are available as standard capabilities.

Shift-Left: Embed Security from the Start

The core DevSecOps principle is "Shift-Left"---moving security checks to the earliest possible stage of the pipeline. According to Practical DevSecOps, the cost of fixing security issues increases exponentially the later they are discovered.

Security in the Development Environment

yaml
# pre-commit hook configuration example
repos:
  - repo: https:--github.com-gitleaks-gitleaks
    rev: v8.18.0
    hooks:
      - id: gitleaks
        name: Detect hardcoded secrets

  - repo: https:--github.com-hadolint-hadolint
    rev: v2.12.0
    hooks:
      - id: hadolint-docker
        name: Lint Dockerfile

Detect accidental secret commits and Dockerfile best practice violations at the developer IDE or pre-commit stage. Tools like GitGuardian automate secret scanning across entire repositories.

Early CI Pipeline Stage

yaml
# Shift-Left security in GitHub Actions
security-checks:
  runs-on: ubuntu-latest
  steps:
    - uses: actions-checkout@v4

    - name: SAST - SonarQube Scan
      uses: SonarSource/sonarqube-scan-action@master
      env:
        SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
        SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}

    - name: Secrets Detection
      uses: gitleaks/gitleaks-action@v2
      env:
        GITLEAKS_LICENSE: ${{ secrets.GITLEAKS_LICENSE }}

    - name: Dependency Check
      uses: dependency-check/Dependency-Check_Action@main
      with:
        path: '.'
        format: 'SARIF'

Captain.AI helps analyze security scan results and prioritize issues with AI, clarifying which problems developers should act on.

Multi-Layer Automated Security Testing

Embed multiple security testing layers into your ci-cd pipeline to detect different threats at different stages.

SAST (Static Application Security Testing)

Analyzes source code before compilation to detect vulnerabilities like SQL injection, XSS, and buffer overflows.

  • sonarqube: multi-language support, quality gate features
  • Semgrep: Lightweight, fast, easy custom rule definitions
  • CodeQL: GitHub-native, semantic analysis

SCA (Software Composition Analysis)

Detects known vulnerabilities in open-source dependencies.

yaml
    - name: SCA Scan
      uses: aquasecurity/trivy-action@master
      with:
        scan-type: 'fs'
        scan-ref: '.'
        format: 'sarif'
        severity: 'CRITICAL,HIGH'

DAST (Dynamic Application Security Testing)

Tests against running applications to detect authentication bypass and session management issues.

  • owasp zap: open-source web application scanner
  • Nuclei: Template-based vulnerability scanner

Container Scanning

yaml
    - name: Container Image Scan
      uses: aquasecurity/trivy-action@master
      with:
        image-ref: 'ghcr.io/your-org/app:${{ github.sha }}'
        format: 'sarif'
        severity: 'CRITICAL,HIGH'
        exit-code: '1'

Trivy, Grype, and Snyk Container detect vulnerabilities in both OS and application layers of container images.

IaC Scanning

bash
# Scan Kubernetes manifests and Helm charts
trivy config ./k8s-manifests/
kubescape scan framework nsa ./helm-charts/
checkov -d ./terraform/

Kubo's deployment pipelines come with these security scans integrated as standard.

Supply Chain Security and the SLSA Framework

As software supply chain attacks surge, the SLSA (Supply-chain Levels for Software Artifacts) framework has become essential for ensuring build integrity.

Graduated SLSA Level Adoption

LevelRequirementsGoal
SLSA 1Build process documentationBasic transparency
SLSA 2Hosted build service + provenance generationTamper detection
SLSA 3Hardened build platform + verifiable provenanceTamper prevention

Container Signing with Sigstore

Sigstore is open infrastructure for signing and verifying container images. It consists of three components: Cosign, Fulcio, and Rekor.

bash
# Sign an image with Cosign (keyless signing)
cosign sign --yes ghcr.io/your-org/app@sha256:abc123

# Verify the signature
cosign verify \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-identity-regexp "https://github.com/your-org/" \
  ghcr.io/your-org/app@sha256:abc123

SBOM (Software Bill of Materials) Generation

yaml
    - name: Generate SBOM
      uses: anchore/sbom-action@v0
      with:
        image: ghcr.io/your-org/app:${{ github.sha }}
        format: spdx-json
        output-file: sbom.spdx.json

    - name: Attest SBOM
      uses: actions/attest-sbom@v1
      with:
        subject-name: ghcr.io/your-org/app
        subject-digest: sha256:abc123
        sbom-path: sbom.spdx.json

According to the GitHub Blog, SLSA Level 2 can be achieved in hours with GitHub Actions and Sigstore, and Level 3 can be implemented in weeks.

Policy as Code and Guardrails

Define security policies as code and enforce them automatically across the pipeline.

Admission Control with OPA/Gatekeeper

yaml
# Policy to deny privileged containers
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPPrivilegedContainer
metadata:
  name: deny-privileged
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
  parameters:
    exemptImages:
      - "istio-proxyv2:*"

Policy Enforcement with Kyverno

yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-signed-images
spec:
  validationFailureAction: Enforce
  rules:
    - name: verify-signature
      match:
        any:
          - resources:
              kinds:
                - Pod
      verifyImages:
        - imageReferences:
            - "ghcr.io-your-org-*"
          attestors:
            - entries:
                - keyless:
                    subject: "https://github.com/your-org/*"
                    issuer: "https://token.actions.githubusercontent.com"

Deploy Kyverno and OPA Gatekeeper to your Kubernetes cluster to block unsigned images and privileged container deployments.

Baseline Policy Configuration

As Wiz's guide recommends, set baseline policies that block clearly unacceptable risks (actively exploited vulnerabilities, unsigned images, etc.) without overly constraining development velocity.

Runtime Monitoring and Feedback Loops

Security monitoring must continue post-deployment.

Runtime Drift Detection

yaml
# Runtime security monitoring with Falco
- rule: Unexpected Network Connection
  desc: Detect network connections to unexpected destinations
  condition: >
    outbound and not (fd.sip in (allowed_outbound_destinations))
  output: >
    Unexpected outbound connection
    (command=%proc.cmdline connection=%fd.name user=%user.name)
  priority: WARNING

Falco is a Kubernetes runtime security monitoring tool that detects unauthorized process execution, network connections, and file access in real time.

Building the Feedback Loop

Build a cycle that feeds runtime-detected issues back into ci-cd improvements.

  1. Detect: Falco identifies runtime anomalies
  2. Notify: Send alerts to Slack/PagerDuty
  3. Analyze: Identify root cause as a pipeline gap
  4. Fix: Update policies or scan rules
  5. Verify: Confirm the fix in the next deployment

Captain.AI accelerates this feedback loop with AI, automating the path from detection to remediation recommendations.

Compliance and Audit

Automated Audit Trails

Each ci-cd pipeline step automatically generates audit evidence, simplifying compliance with major frameworks (SOC 2, ISO 27001, NIST, PCI DSS).

yaml
    - name: Generate Attestation
      uses: actions/attest-build-provenance@v1
      with:
        subject-name: ghcr.io/your-org/app
        subject-digest: sha256:abc123

SLSA provenance, Sigstore signing logs (Rekor), and SBOMs serve as compliance evidence.

Conclusion: Achieve Secure ci-cd with Kubo

ci-cd pipeline security consists of five layers: Shift-Left, multi-layer testing, supply chain protection, Policy as Code, and runtime monitoring. You don't need to implement everything at once. Start with SAST and container scanning, then gradually increase maturity.

Kubo provides a ci-cd foundation with security built in, including container scanning, policy enforcement, and signature verification as standard features. Captain.AI's AI security assistant automates vulnerability prioritization and remediation recommendations, enabling security operations that don't slow development. Ready to build a secure ci-cd pipeline? Contact us today.

← Back to all posts