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
# 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
# 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.
- 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.
Container Scanning
- 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
# 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
| Level | Requirements | Goal |
|---|---|---|
| SLSA 1 | Build process documentation | Basic transparency |
| SLSA 2 | Hosted build service + provenance generation | Tamper detection |
| SLSA 3 | Hardened build platform + verifiable provenance | Tamper prevention |
Container Signing with Sigstore
Sigstore is open infrastructure for signing and verifying container images. It consists of three components: Cosign, Fulcio, and Rekor.
# 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
- 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
# 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
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
# 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.
- Detect: Falco identifies runtime anomalies
- Notify: Send alerts to Slack/PagerDuty
- Analyze: Identify root cause as a pipeline gap
- Fix: Update policies or scan rules
- 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).
- 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.