> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # CICD Security at All Stages > Guide to embedding security across CI/CD pipelines covering SAST, DAST, IAST, dependency and container scanning, secrets management, supply chain attestations, automated policies, monitoring, and incident response. Welcome. This lesson covers CI/CD security across the full software delivery lifecycle and how to embed security controls at each pipeline checkpoint. Security is pervasive: protect source code, build artifacts, test environments, packaged images, and deployments. The diagram below shows high-level security checkpoints in a typical pipeline and the control categories you apply at each stage. The image is a flowchart illustrating security checkpoints in a development pipeline, covering stages from "Source" to "Deploy" and detailing specific security measures at each stage. At a glance: * “Source to package” is Continuous Integration (CI): build, unit tests, static analysis, dependency checks, and artifact creation. * CI/CD extends to Continuous Delivery/Deployment (CD): repeatable deployments across environments (dev → QA → staging → UAT → pre-prod → prod). * Apply Static Application Security Testing (SAST) early (source/PR), and Dynamic Application Security Testing (DAST) against running services in test/staging. Treat security as a first-class concern so decisions are consistent across teams and environments. ## SAST (Static Application Security Testing) SAST inspects source code or compiled artifacts without executing them (white-box analysis). It helps detect coding issues like SQL injection patterns, cross-site scripting, insecure API usage, buffer overflows, and other code-level defects. * Run SAST on every commit and pull request to give developers immediate feedback and prevent long review cycles. * Integrate SAST into pre-commit hooks or PR CI pipelines so developers receive fast, actionable findings. * Typical tools: SonarQube, Checkmarx, Veracode, GitHub CodeQL, Quality Checker. Run SAST as part of pre-commit or pull-request CI checks so findings are surfaced early and cheaply. The image describes SAST (Static Application Security Testing) characteristics, including white box testing, early detection, and common findings like SQL injection and buffer overflows. ## DAST (Dynamic Application Security Testing) DAST treats the application like an external attacker would: it performs black-box testing against the running system to uncover authentication bypasses, session-management issues, input validation problems, and more. * Execute DAST in environments that replicate production (QA or staging) after deployment. * Use DAST to validate runtime behaviors and to find issues SAST cannot see (e.g., runtime misconfiguration). * Common tools: OWASP ZAP, Burp Suite, Rapid7, Acunetix. The image outlines Dynamic Application Security Testing (DAST) characteristics, highlighting black box testing, runtime behavior, and common findings like authentication bypass and input validation. ## IAST (Interactive Application Security Testing) IAST combines SAST and DAST by instrumenting the application during functional tests to provide runtime context tied to source code—an effective gray-box approach. * IAST helps pinpoint root causes and data flows that neither SAST nor DAST alone always reveal. * Adopt IAST when you already have SAST and DAST and want richer, contextual runtime analysis. * Examples: Contrast Security, Seeker (Synopsys), and IAST-capable products from major SAST vendors. The image outlines IAST (Interactive Application Security Testing) with three components: Gray Box Testing, Runtime Instrumentation, and Contextual Analysis, each describing their functions. The image is about "IAST – Real-Time Security Analysis" and outlines platform considerations, emphasizing real-time monitoring during functional tests, live security insights, and vulnerability exploitation awareness. ## Overview: Testing Types & Tooling Use the right mix of techniques across the pipeline to achieve coverage and reduce blind spots. | Test Type | Purpose | Representative Tools | | - | - | - | | SAST | White-box code analysis (early detection) | SonarQube, Checkmarx, Veracode, GitHub CodeQL | | DAST | Black-box runtime testing (behavioural issues) | OWASP ZAP, Burp Suite, Rapid7, Acunetix | | IAST | Gray-box: runtime instrumentation + code context | Contrast Security, Seeker, Checkmarx IAST | | Dependency / SBOM | Identify vulnerable or non-compliant third-party components | Snyk, OWASP Dependency-Check, GitHub Dependabot | | Container scanning | Image CVE scanning & layer analysis | Trivy, Clair, Grype, Aqua | ## Example CI snippets * Basic GitHub Actions step for running Trivy container scan: ```yaml theme={null} - name: Trivy image scan uses: aquasecurity/trivy-action@v0.1.13 with: image-ref: myorg/myimage:latest ``` * GitHub CodeQL analysis step: ```yaml theme={null} - name: Initialize CodeQL uses: github/codeql-action/init@v2 with: languages: javascript - name: Perform CodeQL Analysis uses: github/codeql-action/analyze@v2 ``` ## Performance and Load-related Security Systems can fail under load—this is where DoS and resource-exhaustion vulnerabilities manifest. * Validate API throttling, rate limiting, and metering. * Use load testing tools (JMeter, k6) to confirm resilience, detect failure modes, and evaluate mitigation strategies (e.g., autoscaling, throttles). The image is a diagram describing performance security testing under load, highlighting aspects like load testing security, DDoS resilience, and resource exhaustion. The image is about performance security testing under load, highlighting platform integration using tools like JMeter or K6, measuring performance under security controls, and validating peak traffic handling. ## Third-Party Component Analysis and SBOM Third-party dependencies are a major source of risk. * Scan direct and transitive dependencies for CVEs and license issues. * Produce a Software Bill of Materials (SBOM) to catalog components in each build—useful for rapid remediation and compliance. * Tools: Snyk, OWASP Dependency-Check, GitHub Dependabot, and SBOM generators. The image is an infographic about Third-Party Component Security Analysis, highlighting four areas: known vulnerabilities, transitive dependencies, license compliance, and update management. Each area includes a brief description of its focus. The image illustrates a "Third-Party Component Security Analysis" with two detection methods: Vulnerability Scanning and SBOM Generation. Vulnerability Scanning mentions tools like Snyk, OWASP Dependency-Check, and GitHub Dependabot, while SBOM Generation emphasizes transparency into components. ## Container and Artifact Security Protect images and artifacts from build-time through runtime. * Use minimal base images (e.g., distroless) to reduce attack surface. * Scan images for CVEs and analyze layer composition. * Enforce runtime security and policy (admission controllers, OPA/Gatekeeper, Kyverno). * Runtime monitoring solutions (e.g., StackRox/Red Hat) detect suspicious behavior and policy violations. The image outlines key aspects of container security throughout the lifecycle, including base image security, vulnerability scanning, image composition analysis, and runtime security. ## Secrets Management (Do not embed secrets) * Never embed secrets in source code or bake them into images. Kubernetes Secrets are base64-encoded, not encrypted by default—use a dedicated secrets manager. * Prefer short-lived credentials, certificate-based auth, and automated rotation. Inject secrets at runtime and enforce least privilege. Do not store secrets in source, container images, or plaintext configuration. Use managed secret stores (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) and rotate credentials automatically. ## Supply-Chain Security and Attestations * Use SLSA (Supply-chain Levels for Software Artifacts) to measure and improve build integrity. * Aim for reproducible builds, signed artifacts, and signed attestations where practical; SLSA Level 2 is a practical starting point. * Maintain transparency logs and validate signatures at deploy time to block tampered artifacts. The image outlines five supply chain levels for software artifacts, ranging from Level 0 with no specific requirements to Level 4 with reproducible builds as the aspirational standard. ## Automated Policy Enforcement Automate security checks across the pipeline with policy-as-code. * Enforce checks at source control (pre-commit, PR validation), build-time scans, deployment admission, and runtime monitoring. * Tools like OPA/Rego, Gatekeeper, and Kyverno enable declarative policy enforcement. The image outlines "Automated Security Policy Enforcement" across four stages: Source Control, Build Time, Admission Control, and Runtime, detailing activities like pre-commit hooks, policy validation, Kubernetes admission controllers, and continuous monitoring. The image illustrates "Automated Security Policy Enforcement" with three policy types: Security Policies, Compliance Policies, and Operational Policies, each with specific focuses like container security and regulatory requirements. Policy examples to enforce: * Mutual TLS between services and strong service identity. * Fine-grained authorization and workload identity. * Automated provisioning, rotation, and revocation of tokens and certificates. ## Monitoring, Metrics, and Incident Response Measure security effectiveness and prepare response automation. * Key metrics: Mean Time To Detect (MTTD), Mean Time To Recover (MTTR), policy violations, false-positive rates, and scan failures. * Build dashboards, alerts, and runbooks—don’t invent response procedures during an incident. Pre-authorized automation reduces decision friction. * Incident cycle for pipelines: Detection → Containment → Investigation → Remediation → Learning → Tune detection. The image is a flowchart titled "When and Where to Apply Security Testing," showing the stages of software development, including Pre-Commit, Pull Request, Build Stage, Test Environment, Pre-Production, and Production, along with specific security tasks for each stage. The image outlines categories for measuring security effectiveness, including vulnerability metrics, compliance tracking, security events, and response metrics. The image depicts the steps in a security incident response cycle for pipelines, including Detection, Containment, Investigation, Remediation, and Learning, arranged in a circular flow with a shield icon at the center. ## Choosing Security Tools and Platform Strategy Evaluate tooling and define an organizational strategy for platform security. * Evaluate coverage, CI/CD integration, accuracy (false positives/negatives), cost, and vendor/community support. * Standardize a core toolset, but allow justified flexibility for team-specific needs. Centralize onboarding and governance to reduce sprawl. The image is an infographic titled "Choosing the Right Security Tools" and outlines five categories to consider: Coverage, Integration, Accuracy, Cost, and Support, with specific factors listed under each. The image is an infographic titled "Choosing the Right Security Tools," highlighting three strategies: Standardization, Flexibility, and Evolution. Each strategy includes a brief description of its role in evaluating security tools. ## Roles and Coordination Security is a shared responsibility. * Platform teams deliver guardrails, CI/CD integrations, and policy enforcement. * Product teams implement secure coding and operate applications within those guardrails. * Appoint security champions to spread domain knowledge and accelerate secure practices across teams. The image outlines "Team Security Responsibilities and Coordination," focusing on collaboration patterns such as "Shared Responsibility," where the platform provides tools and teams implement practices, and "Security Champions," where domain expertise is distributed across teams. ## Security Trends (platform engineering focus) * AI-assisted security analysis and predictive detection. * Zero-trust architectures, ephemeral credentials, and workload-level identity. * Deeper DevSecOps integration with build-time and runtime attestations. The image outlines four security trends for platform engineers: AI-powered security, zero-trust architecture, predictive security, and DevSecOps evolution, each with a brief description. ## Core Security Pillars * Testing diversity: SAST, DAST, IAST as appropriate. * Multi-layer scanning: source, dependencies, images, and runtime. * Supply-chain protection: SBOM, signed artifacts, and attestations (SLSA). * Secret management: secure injection, rotation, least privilege. The image outlines four core security pillars for achieving security excellence: testing diversity, multi-layer scanning, supply chain protection, and secret management. ## Key takeaways * Automate security policy enforcement and identity lifecycle (provisioning, rotation, revocation). * Instrument security metrics and observability for continuous improvement. * Prepare incident response playbooks and automation in advance. * Embedding security across CI/CD enables faster, safer, and compliant delivery aligned with platform engineering goals. The image outlines key takeaways for security excellence across a pipeline, focusing on policy automation, identity management, security metrics, and incident preparedness. Each section provides a brief description of its importance. The image outlines key takeaways related to security excellence in a platform, emphasizing comprehensive security, fast and safe delivery, and alignment with platform engineering goals. Apply the right checks at the right stages, measure outcomes, and automate responses. When security is embedded in CI/CD, teams can deliver quickly and with confidence. ## Links and References * [Kubernetes Documentation](https://kubernetes.io/docs/) * [OWASP Testing Guide](https://owasp.org/) * [SLSA Framework](https://slsa.dev/) * [GitHub CodeQL](https://securitylab.github.com/tools/codeql/) * [Trivy Container Scanner](https://github.com/aquasecurity/trivy) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.