Skip to content
a Programmer

DevOps CI/CD Security

CI/CD Security is the practice of embedding security controls throughout the Continuous Integration (CI) and Continuous Delivery/Deployment (CD) pipeline. The goal is to deliver software quickly without sacrificing security.

This concept is often referred to as DevSecOps, where security becomes a shared responsibility across development, operations, and security teams.

Why CI/CD Security Matters

Section titled “Why CI/CD Security Matters”

Modern applications are deployed frequently, sometimes multiple times per day. Without automated security controls:

  • Vulnerabilities can be introduced into production rapidly.
  • Secrets (API keys, passwords, tokens) may be exposed.
  • Malicious dependencies can enter the software supply chain.
  • Infrastructure misconfigurations can create security risks.
  • Attackers can compromise build systems and inject malicious code.

CI/CD security aims to detect and prevent these issues before deployment.

CI/CD Pipeline Security Overview

Section titled “CI/CD Pipeline Security Overview”
Developer
    │
    ▼
Source Control (Git)
    │
    ├── SAST
    ├── Secret Scanning
    ▼
Build Stage
    │
    ├── Dependency Scanning
    ├── SBOM Generation
    ▼
Test Stage
    │
    ├── Security Tests
    ├── IaC Scanning
    ▼
Container Build
    │
    ├── Container Scanning
    ▼
Deployment
    │
    ├── Approval Gates
    ├── Policy Enforcement
    ▼
Production
    │
    ├── Runtime Monitoring
    ├── Threat Detection

Security Controls in the CI Stage

Section titled “Security Controls in the CI Stage”

1. Source Code Scanning (SAST)

Section titled “1. Source Code Scanning (SAST)”

Static Application Security Testing (SAST) analyses source code without executing it.

Detects:

  • SQL Injection
  • Cross-Site Scripting (XSS)
  • Hard-coded credentials
  • Authentication flaws
  • Insecure coding patterns

Tools

Section titled “Tools”
  • SonarQube
  • Checkmarx
  • Veracode
  • Semgrep
  • Microsoft Security Code Analysis

2. Secret Scanning

Section titled “2. Secret Scanning”

Developers sometimes accidentally commit:

API Keys
Passwords
Certificates
Database connection strings
JWT signing keys

Security scanners detect such secrets before code is merged.

Tools

Section titled “Tools”
  • GitGuardian
  • TruffleHog
  • GitHub Secret Scanning
  • Gitleaks

Example:

// Bad
string apiKey = "abc123-secret-key";

The pipeline should fail if this is detected.

3. Dependency Scanning

Section titled “3. Dependency Scanning”

Applications depend heavily on third-party libraries.

Example:

Newtonsoft.Json
Log4Net
EntityFramework

A vulnerable package can compromise the application.

Tools

Section titled “Tools”
  • Snyk
  • Dependabot
  • OWASP Dependency-Check
  • GitHub Advanced Security

Checks:

  • Known CVEs
  • Outdated packages
  • License violations

Security Controls in the Build Stage

Section titled “Security Controls in the Build Stage”

4. Supply Chain Security

Section titled “4. Supply Chain Security”

Attackers increasingly target software supply chains.

Examples:

  • Malicious package uploads
  • Build server compromise
  • Dependency hijacking

Mitigations:

  • Package signing
  • Trusted repositories
  • Dependency pinning
  • Build provenance verification

5. Software Bill of Materials (SBOM)

Section titled “5. Software Bill of Materials (SBOM)”

An SBOM is an inventory of every component used in the application.

Example:

Application:
├── ASP.NET Core 9
├── Serilog 4.0
├── AutoMapper
└── Newtonsoft.Json

Benefits:

  • Faster vulnerability investigations
  • Compliance support
  • Supply-chain visibility

Tools:

  • Syft
  • CycloneDX
  • SPDX

Security Controls in the Testing Stage

Section titled “Security Controls in the Testing Stage”

6. DAST

Section titled “6. DAST”

Dynamic Application Security Testing analyses a running application.

Detects:

  • Authentication issues
  • Session vulnerabilities
  • XSS
  • Security misconfigurations

Tools:

  • OWASP ZAP
  • Burp Suite
  • Acunetix

7. Infrastructure as Code (IaC) Scanning

Section titled “7. Infrastructure as Code (IaC) Scanning”

Infrastructure definitions should be checked before deployment.

Example Terraform/Azure Bicep:

Azure Storage Account
Azure SQL Database
Kubernetes Cluster

Detects:

  • Publicly exposed databases
  • Weak network rules
  • Missing encryption
  • Excessive permissions

Tools:

  • Checkov
  • tfsec
  • Terrascan

Container Security

Section titled “Container Security”

8. Container Image Scanning

Section titled “8. Container Image Scanning”

Container images can contain vulnerabilities.

Example Docker image:

FROM ubuntu:22.04

The base image may include vulnerable packages.

Scanners analyse:

  • Operating system packages
  • Installed libraries
  • Known CVEs

Tools:

  • Trivy
  • Clair
  • Anchore
  • Microsoft Defender for Containers

9. Container Hardening

Section titled “9. Container Hardening”

Best practices:

FROM mcr.microsoft.com/dotnet/aspnet:9.0


RUN adduser appuser
USER appuser

Avoid:

  • Running as root
  • Unnecessary packages
  • Open ports not required

CD (Deployment) Security

Section titled “CD (Deployment) Security”

10. Secure Deployment Gates

Section titled “10. Secure Deployment Gates”

Before production deployment:

✓ Unit tests passed
✓ Security scans passed
✓ Vulnerabilities below threshold
✓ Approvals completed

The deployment should automatically stop if requirements are not met.

11. Least Privilege Access

Section titled “11. Least Privilege Access”

CI/CD systems should have only necessary permissions.

Bad:

Contributor access to entire Azure subscription

Better:

Deployment permission only
to specific resource group

12. Secrets Management

Section titled “12. Secrets Management”

Never store secrets in:

Git repositories
Build scripts
Configuration files

Use dedicated secret stores:

  • Azure Key Vault
  • HashiCorp Vault
  • AWS Secrets Manager

Example:

connectionString: $(SQL_CONNECTION_STRING)

The secret is injected at runtime.

Runtime Security

Section titled “Runtime Security”

Security should continue after deployment.

Monitor for:

  • Unusual logins
  • Privilege escalation
  • Malware
  • Container escapes
  • Suspicious network traffic

Tools:

  • Microsoft Defender for Cloud
  • Microsoft Sentinel
  • Falco
  • CrowdStrike

CI/CD Security Best Practices

Section titled “CI/CD Security Best Practices”

Do

Section titled “Do”

✅ Shift security left

✅ Automate all security scans

✅ Scan every pull request

✅ Use signed artifacts

✅ Generate SBOMs

✅ Rotate secrets regularly

✅ Apply least-privilege access

✅ Continuously monitor production

Don’t

Section titled “Don’t”

❌ Hard-code credentials

❌ Ignore dependency updates

❌ Deploy without security gates

❌ Run containers as root

❌ Give pipelines excessive permissions

❌ Rely solely on manual security reviews

CI/CD Security in Azure DevOps Example

Section titled “CI/CD Security in Azure DevOps Example”
1. Developer creates Pull Request
        │
2. SAST Scan
        │
3. Secret Scan
        │
4. Dependency Scan
        │
5. Build Application
        │
6. Create SBOM
        │
7. Container Scan
        │
8. Deploy to Test
        │
9. DAST Scan
        │
10. Approval Gate
        │
11. Deploy to Production
        │
12. Continuous Monitoring

Key Takeaway

Section titled “Key Takeaway”

CI/CD Security (DevSecOps) means integrating automated security checks into every stage of the software delivery pipeline, from code commit to production deployment. The objective is to identify vulnerabilities, misconfigurations, secrets, and supply chain risks as early as possible while enabling fast, reliable, and secure software releases.