CI/CD Pipeline Security

Build secure CI/CD pipelines with automated security gates, secrets detection, container scanning, and policy enforcement.

Premium Course Content

This lesson is part of a premium course. Upgrade to Pro to unlock all premium courses and content.

Access all premium courses
1000+ AI skill templates included
New content added weekly

← Back to course overview

Your CI/CD pipeline is the gateway to production. Every line of code, every dependency, every container passes through it. If security isn’t embedded in the pipeline, it’s not embedded anywhere.

🔄 Quick Recall: In the previous lesson, you secured infrastructure-as-code — Terraform and Kubernetes configurations. CI/CD security ensures those configurations (and all code) pass through automated security checks before reaching production.

The Secure Pipeline Architecture

Developer writes code
     ↓
Pre-commit hooks (local)
  ├── Secret detection (GitLeaks)
  ├── Code formatting / linting
  └── Quick SAST (fast rules only)
     ↓
Pull Request created
     ↓
CI Pipeline (server-side, mandatory)
  ├── SAST scan (code security)
  ├── SCA scan (dependency vulnerabilities)
  ├── Container scan (image vulnerabilities)
  ├── IaC scan (Terraform/K8s security)
  ├── Secret scan (server-side, can't be skipped)
  └── License compliance check
     ↓
AI Triage (filter results)
  ├── Critical/High → Block merge
  ├── Medium → Warning, don't block
  └── Low/FP → Suppress, log for review
     ↓
Code review + security review
     ↓
Merge to main → Deploy pipeline
  ├── Integration tests
  ├── Image signing
  └── Deploy with admission controller validation

Secrets Detection

Setting Up Secret Scanning

Generate a GitLeaks configuration for my repository:

Language: Python + JavaScript/TypeScript
Cloud: AWS (access keys, secret keys, session tokens)
Services: PostgreSQL, Redis, Stripe, SendGrid, Twilio

I need rules to detect:
1. AWS credentials (access key ID + secret access key)
2. Database connection strings with passwords
3. API keys for our third-party services
4. JWT signing secrets
5. Private keys (RSA, SSH)

Also generate:
- Allowlist patterns for test fixtures and mock data
- .gitleaksignore entries for known false positives
- Pre-commit hook configuration

Remediation After Exposure

A developer committed an AWS access key to our repository.
The commit was pushed to GitHub 15 minutes ago.

Generate an incident response checklist:

1. Immediate actions (first 5 minutes)
2. Credential rotation steps (AWS-specific)
3. Audit steps (what to check for unauthorized access)
4. Repository cleanup (remove from git history)
5. Prevention measures (what to add to prevent recurrence)

Include specific AWS CLI commands for each step.

✅ Quick Check: Your secret scanner has 20 allowlisted patterns for test fixtures. A new developer adds a real production API key to a test file, thinking it’s fine because “it’s just a test.” The scanner doesn’t flag it because test files are allowlisted. How do you fix this design flaw? (Answer: Never allowlist by file path alone. Allowlist by specific patterns that match mock/test formats — like sk_test_* for Stripe test keys but not sk_live_*. Or use entropy-based detection: real API keys have high entropy; test fixtures using placeholder strings like MOCK_KEY_123 don’t. AI can generate precise allowlist rules that distinguish real secrets from test data.)

Policy-as-Code

OPA/Rego Policy Generation

Generate OPA Rego policies for our Kubernetes admission
controller:

Policies needed:
1. All containers must have resource limits (CPU and memory)
2. No containers run as root (runAsNonRoot: true)
3. Images must come from our private registry (gcr.io/our-project/)
4. No privileged containers
5. All pods must have at least one label (app, team)
6. No hostPath volume mounts in production namespace

For each policy, generate:
- The Rego rule
- A test case (passing)
- A test case (violation)
- A human-readable denial message

GitHub Actions Security Workflow

Generate a GitHub Actions workflow for our security pipeline:

Repository: Python FastAPI application
Tests: pytest
Scans needed:
1. Secret detection (GitLeaks)
2. SAST (Semgrep with Python rules)
3. SCA (pip-audit for dependencies)
4. Container scan (Trivy on our Docker image)
5. IaC scan (Checkov on our Terraform)

Requirements:
- Run all scans in parallel for speed
- Critical findings block the PR
- Results posted as PR comments
- Scan artifacts uploaded for audit
- Total pipeline time target: under 10 minutes

Practice Exercise

Set up GitLeaks pre-commit hook on a project and run it against your repository
Generate an OPA policy for one of your Kubernetes requirements
Create a GitHub Actions security workflow for your project using the template above

Key Takeaways

Defense in depth: local hooks catch early, CI catches what hooks miss, admission controllers enforce at deploy
Secrets in git are a when-not-if problem — automated detection at every layer is essential
Pipeline speed matters: parallel scans, incremental scanning, and AI triage keep security fast
Policy-as-code (OPA, Kyverno) makes security rules enforceable and auditable
AI generates pipeline configurations, scanning rules, and policies from plain-language descriptions

Up Next

In the next lesson, you’ll learn AI-powered monitoring and incident response — detecting threats in production and responding before damage spreads.

Knowledge Check

1. A developer accidentally commits an AWS access key to a public GitHub repository. Your pre-commit hook would have caught it, but the developer skipped hooks with `--no-verify`. How do you prevent this from happening again?

Trust developers to not skip hooks Defense in depth: pre-commit hooks are the first layer, but add server-side scanning in your CI pipeline (GitHub secret scanning, GitLeaks in CI) that CANNOT be skipped. If a secret is detected in any push, the pipeline fails and alerts the security team. The developer can skip local hooks, but they can't skip server-side checks Remove the --no-verify option from git

2. Your CI pipeline includes SAST, SCA, container scan, and IaC scan. Total scan time: 25 minutes per PR. Developers complain it's too slow. How do you speed it up without removing security?

Only scan on the main branch Run scans in parallel instead of sequentially, use incremental scanning (only scan changed files), and implement tiered gates: fast checks (secrets, linting) block PRs immediately, full scans run in parallel and report results without blocking unless critical findings are detected. AI triage filters results so only real issues require developer attention Remove the slowest scan

3. You need to enforce that all container images are signed and come from your private registry — not Docker Hub or other public sources. Where in the pipeline do you enforce this?

Document the policy and trust teams to follow it Enforce at multiple points: admission controllers in Kubernetes (OPA/Kyverno) reject unsigned images at deploy time, CI pipeline validates image sources during build, and policy-as-code ensures the Dockerfile FROM directive uses only approved registries. AI helps write and maintain these policies Only in the Dockerfile review

Answer all questions to check

Complete the quiz above first