Penetration Testing for DevOps: Embed Pentests in CI/CD

Penetration testing for DevOps means building security testing into the CI/CD pipeline: automated scans run on every change, human-led pentests cover high-risk releases, and the pipeline itself is tested as an attack target, because it holds the keys to production. In short:

• What it is: DevSecOps pentesting embeds automated security checks (SAST, DAST, SCA, IaC & secrets scanning) directly into CI/CD so security is continuous and developer-first.
• Why it matters: It finds issues early, lowers remediation costs, and prevents security bottlenecks. In IBM's Cost of a Data Breach Report 2026, the U.S. average breach cost reached a record $11.5M (global: $4.99M), up from $10.22M in the 2025 edition, reinforcing the ROI of proactive controls.
• How to start: Run SAST & SCA on every commit, add DAST & IaC scans in staging, then enforce risk-based security gates that block High/Critical findings pre-deploy.
• Key KPI: Reduce the vulnerability escape rate (defects found in production vs. pre-production) to measure the effectiveness of your shift left strategy.
• Protect the pipeline too: Harden CI/CD against the OWASP Top 10 CI/CD Security Risks, swap stored keys for short-lived credentials, verify build provenance with SLSA, and test in an environment that matches production.

What is Penetration Testing for DevOps?

Penetration testing for DevOps is the practice of embedding automated and continuous security validation across the entire Software Development Lifecycle (SDLC). This approach augments, not replaces, human led pentests: automation covers breadth on every build, while experts probe complex business logic and chained exploits that scanners miss. It also works best alongside threat modeling at design time, so the highest-risk flaws are caught before code exists rather than after deployment. As development teams scale their projects, partnering with a software development company like Binary Studio can provide additional engineering expertise while keeping security considerations integrated throughout the software development lifecycle.

In 2026, this is non-negotiable. The CI/CD pipeline itself is a prime target. The XZ Utils upstream backdoor (CVE-2024-3094) showed how a sophisticated, patient attacker could compromise a core dependency and ripple into production systems worldwide. For U.S. DevOps teams protecting CI/CD pipelines, breach costs averaging $11.5M in IBM's 2026 report (up from $10.22M in 2025) make proactive security a financial necessity.

DeepStrike's Continuous Security Testing adds manual testing of newly deployed features, which can find logic flaws that automated SAST and DAST gates typically miss.

The 2026 Standards Crosswalk: NIST, OWASP & SLSA

A modern DevSecOps program aligns with key industry standards that provide a battle tested roadmap for security.

• NIST SSDF (SP 800-218): This framework provides high level secure development practices that you can operationalize through pipeline policy and automation.
• NIST SP 800-204D (final, Feb 12, 2024): This publication offers concrete strategies to integrate software supply chain security (attestations, dependency controls, build integrity) into DevSecOps CI/CD.
• OWASP Top 10 CI/CD Security Risks: Anchor your controls to critical risks like CICD-SEC-1 (Insufficient Flow Control), CICD-SEC-4 (Poisoned Pipeline Execution), and CICD-SEC-6 (Insufficient Credential Hygiene).
• SLSA (Supply chain Levels for Software Artifacts): This framework is a maturity roadmap for artifact integrity and provenance. Starting at SLSA Build Level 2 (signed provenance from a hosted build platform) is a practical goal for most organizations.

How Do I Add Pentesting to a CI/CD Pipeline?

You can start integrating security into your pipeline by following a clear, five step process. This checklist provides a structured way to begin shifting security left without overwhelming your development teams.

Quick Start: 5 Steps to Embed Pentesting in CI/CD

1. Commit Scan the code (SAST + SCA + secrets): Integrate tools like Semgrep for SAST and GitHub secret scanning to block leaked credentials on every commit.
2. Build Harden artifacts (container scan + SBOM): Use a tool like Trivy to scan container images for vulnerabilities and generate an SPDX or CycloneDX Software Bill of Materials (SBOM).
3. Test Attack the running app (DAST): Deploy to a staging environment and run OWASP ZAP to spider and passively scan for runtime vulnerabilities.
4. Deploy Enforce security gates (fail on High/Critical): In platforms like GitLab, use Merge Request approval policies tied to scanner reports to block insecure code from being merged.
5. Post deploy Sign & monitor: Use Sigstore/Cosign for keyless signing and to create SBOM/SLSA attestations for your artifacts. Continue monitoring in production and schedule regular manual pentests.

Where Does Each Scan Fit?

Each type of security scan plays a specific role at a different stage of the pipeline, providing a defense in depth strategy.

• SAST (Static Application Security Testing): Analyzes raw source code for issues like injection patterns. Open source tools like Semgrep are highly effective here.
• DAST (Dynamic Application Security Testing): Tests the running application for runtime findings like broken authentication or server misconfigurations. OWASP ZAP is the go to open source tool.
• SCA (Software Composition Analysis): Scans for known vulnerabilities (CVEs) in your open source dependencies.
• IaC (Infrastructure as Code) Scanning: Checks Terraform or Kubernetes configurations for misconfigurations like public S3 buckets. Checkov and KICS are popular choices.
• Secret Scanning: Prevents leaked keys and tokens from ever entering your codebase. Tools like GitHub Secret Protection help block secrets before they reach the repository.

Other helpful entities to be aware of for a comprehensive security posture include CISA, ENISA, CERT-In, MFA, and infostealer malware.

What is Poisoned Pipeline Execution (PPE) and How Do We Prevent It?

Poisoned Pipeline Execution (PPE) is an attack where malicious commands are injected into a pipeline's configuration file and run with the CI system's permissions. It's identified as CICD-SEC-4 in the OWASP Top 10 CI/CD Security Risks.

A strong PPE playbook includes these countermeasures:

• Branch Protection: Enforce mandatory code reviews before merging to the main branch.
• Signed Commits: Require developers to cryptographically sign commits to verify their identity.
• Least Privilege & Isolated Runners: Ensure build jobs run with minimal necessary permissions in isolated, ephemeral environments.
• Review Gates: Address CICD-SEC-1 (Insufficient Flow Control) by requiring automated security scans to pass before a merge is allowed.

YAML in 60 Seconds: Practical Security Gates

GitLab Enable SAST on Every Merge Request You can enable SAST with a simple template include, then enforce a gate using Merge Request approval policies (GitLab Ultimate).

#.gitlab-ci.yml
include:
  - template: Jobs/SAST.gitlab-ci.yml

# Then add a merge request approval policy (Secure > Policies, GitLab Ultimate)
# that requires approval when SAST reports High or Critical findings.

This configuration ensures SAST runs before code is merged, and an enforced approval policy requires approval before merge requests with High or Critical SAST findings reach your main branch.

GitHub ZAP Baseline Action as a DAST Gate This GitHub Action runs an OWASP ZAP scan against a staging URL and can be configured to fail the build if it finds vulnerabilities.

#.github/workflows/zap.yml
name: ZAP baseline
on: [push, pull_request]
jobs:
  zap:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: ZAP baseline scan
        uses: zaproxy/action-baseline@v0.14.0
        with:
          target: https://staging.example.com
          fail_action: true
          rules_file_name: '.zap/rules.tsv'   # Ignore tuned false positive rules
          cmd_options: '-a'                   # Also run alpha passive rules (baseline scans are passive only)

The fail_action: true parameter is what turns this scan into a practical security gate. Baseline scans are passive; use the ZAP full scan action against a dedicated test environment if you need active testing.

Sign and Attest with Sigstore/Cosign

Cryptographically signing your artifacts provides a verifiable guarantee of their integrity. Sigstore's Cosign tool enables "keyless" signing, which is ideal for automated CI/CD environments.

# Build & push image first, then:
cosign sign --yes $IMAGE_DIGEST
trivy image --format spdx-json -o sbom.json $IMAGE
cosign attest --yes --predicate sbom.json --type spdxjson $IMAGE_DIGEST

This workflow signs a container image digest and attaches an SBOM as a verifiable attestation, using short lived certificates instead of manually managed keys.

DevOps security practices that protect the pipeline itself

DevOps security is the set of practices that protect the code, pipelines, build systems, credentials and environments a team uses to ship software, so that faster delivery doesn't open new ways in. The scanners above check the application. DevOps security also has to protect the pipeline, because a CI/CD system holds production credentials, decides what gets deployed and runs code from many sources. Penetration testing is how you find out whether those protections actually hold.

These practices sit inside a wider secure software development lifecycle (SSDLC), which also covers requirements, design and code review. For pipeline-specific government guidance, CISA and the NSA published joint guidance on defending CI/CD environments in June 2023, which lists common pipeline risks and recommended mitigations.

CI/CD pipeline threats: the OWASP Top 10 CI/CD Security Risks

The OWASP Top 10 CI/CD Security Risks is the most useful shared vocabulary for pipeline threats. The table lists all ten risks, how each one tends to show up, and what a tester checks during a pipeline-focused assessment.

These risks are not theoretical. In March 2025, CISA warned that the widely used GitHub Action tj-actions/changed-files had been compromised (CVE-2025-30066), exposing secrets such as access keys, GitHub personal access tokens, npm tokens and private RSA keys from affected workflows. CISA's alert on the tj-actions compromise told affected organizations to treat those secrets as compromised and rotate them. One incident touched three risks at once: third-party services (CICD-SEC-8), the dependency chain (CICD-SEC-3) and credential hygiene (CICD-SEC-6).

Secrets management in CI/CD

Pipelines need credentials to deploy, but every stored credential is something an attacker can lift from a log, a fork build or a compromised dependency. The goal is fewer secrets, shorter lifetimes and narrower scope:

• Replace stored cloud keys with short-lived tokens. GitHub's secure use reference for Actions recommends OpenID Connect (OIDC), so workflows get short-lived, well-scoped tokens from the cloud provider instead of long-lived secrets. GitLab and most other CI platforms support the same pattern.
• Block secrets before they land. Secret scanning with push protection stops commits that contain recognized tokens or private keys. Scan the full repository history once as well, because old commits still leak.
• Default to read-only tokens. Set the default GITHUB_TOKEN, or your platform's equivalent job token, to read-only and grant write scopes only to the jobs that need them.
• Keep secrets away from untrusted code. Don't expose secrets to builds from forks, don't check out pull request code in privileged workflows such as pull_request_target, and mask secrets in logs.
• Plan for rotation. Keep an inventory of which pipeline uses which credential, so you can rotate everything quickly after an incident like the tj-actions compromise.

In a pentest, secrets are often the shortest path from a pipeline weakness to real impact. A DevOps-focused test should cover repository history, build logs, artifacts and container image layers, not only the running application.

Build integrity with SLSA

SLSA (Supply-chain Levels for Software Artifacts) defines how far you can trust that an artifact was built from the expected source by the expected process. The current specification, v1.2, has a Build track with four levels:

Build L2 is a realistic first target for most teams, and the Sigstore Cosign signing and attestation workflow shown earlier is one way to produce what it needs. Aim for L3 on the artifacts that matter most, such as release builds of customer-facing services. The step teams most often skip is verification: provenance only helps if the deploy stage, or an admission controller in Kubernetes, rejects artifacts whose signature or provenance doesn't match. That is CICD-SEC-9 in practice.

Testers check this by trying to deploy an unsigned or re-tagged image through the normal path and seeing whether anything stops it. Our Kubernetes penetration testing guide covers how admission controls are assessed in a cluster.

CI/CD vulnerability scanning for dependencies

CI/CD vulnerability scanning means checking code, dependencies, container images and infrastructure definitions automatically inside the pipeline, so known vulnerabilities are caught before release. Dependencies deserve particular attention, because most of a modern application is third-party code and software supply chain attacks target exactly that layer. A practical setup:

• Scan on every pull request and on a schedule. Run SCA on each change, and rescan the main branch daily, because new CVEs are published against code you haven't touched.
• Enforce lockfiles and trusted sources. Build from committed lockfiles, pull from approved registries or a proxy, and reserve your internal package names on public registries to reduce dependency confusion.
• Generate an SBOM for every build. An SPDX or CycloneDX SBOM attached to each artifact lets you answer "are we affected?" in minutes when the next critical CVE lands.
• Prioritize by exploitation, not only severity. Fail the build on Critical findings and on anything listed in CISA's Known Exploited Vulnerabilities catalog; send the rest to a tracked backlog with due dates.
• Treat CI plugins and actions as dependencies. Pin third-party actions to a full commit SHA, review them before approval, and use OpenSSF Scorecard to check open source projects for practices such as pinned dependencies and read-only workflow tokens.

Scanners find known issues in known components. They don't tell you whether a vulnerable function is reachable, whether a finding chains with a misconfiguration, or whether a business rule can be abused. For what each automated method can and can't find, see our comparison of SAST vs DAST vs IAST vs RASP.

Environment parity for security testing

A DAST scan or a pentest is only as trustworthy as the environment it runs against. If staging uses a different identity provider, skips the WAF, runs older images or has debug settings switched on, its findings won't match production in either direction. You get false alarms for issues production doesn't have, and false confidence about controls production relies on. To keep test results meaningful:

• Deploy test environments from the same infrastructure-as-code modules and the same image digests that go to production, with differences limited to scale and secrets.
• Mirror security-relevant configuration: authentication and SSO flows, roles, API gateways, WAF and rate limits, TLS settings and feature flags.
• Use synthetic or masked data with a realistic structure, so authorization and business logic tests mean something without exposing real customer records.
• Spin up short-lived preview environments for significant changes, and tear them down, along with their credentials, when the branch is merged.
• Write any remaining differences into the test scope, so testers and report readers know which findings need confirming in production.

Some checks still belong in production, such as external exposure, TLS and DNS. Run those with written authorization, agreed time windows and rate limits. The same rule applies to pipelines: a CI/CD assessment can touch source control, build systems and cloud accounts, so name each one in the rules of engagement.

Automated gates cover known issues. A periodic human review of the pipeline itself covers the rest: flow-control bypasses, privileged fork builds, over-scoped tokens and unverified artifacts. If you want that review to keep pace with your releases, DeepStrike's continuous penetration testing services pair comprehensive penetration tests twice a year with testing of newly deployed features, functions and APIs.

Metrics That Prove "Shift-Left" is Working

To demonstrate the ROI of your DevSecOps program, track these key metrics:

Key KPI Definitions

• Mean Time to Detect (MTTD): The average time it takes to identify a vulnerability from the moment it's introduced.
• Mean Time to Remediate (MTTR): The average time it takes to fix a vulnerability once it's been detected.
• Vulnerability Escape Rate: The percentage of vulnerabilities discovered in production versus those found in pre-production. This is the ultimate measure of your "shift left" effectiveness.

Micro Cases from the Field

These are illustrative examples, not client results.

• FinServ API: A financial services firm implements mandatory SAST gates on all merge requests, lowering its vulnerability escape rate by blocking High/Critical findings before they reach the main branch.
• E-commerce Platform: By running an OWASP ZAP baseline scan on every deployment to staging, an e-commerce company catches multiple misconfigured security headers and other passive findings that manual QA had repeatedly missed.
• SaaS Provider: After adopting IaC scanning with Checkov, a SaaS provider reduces cloud misconfigurations, blocking public S3 buckets and overly permissive IAM roles before they are deployed.

Frequently Asked Questions

Is penetration testing compatible with continuous delivery?

For UK software teams embedding pentesting into CI/CD, routine SAST/DAST/SCA scans can run on each change, while human-led pentests should be scheduled for high-risk releases. Our comparison of PTaaS vs. Traditional Penetration testing covers which delivery model keeps up with a weekly release cadence

What standards should my pipeline meet in 2026?

Your pipeline should align with NIST SSDF (SP 800-218) for process maturity, NIST SP 800-204D for supply chain controls, OWASP Top 10 CI/CD for pipeline threats, and aim for SLSA Build Level 2 (signed provenance generated by a hosted build platform).

How do we avoid noisy scanners?

Tune your rulesets. Start by only blocking on High/Critical findings. Use per-repository baseline or ignore lists (e.g., ZAP's rules.tsv or Semgrep's --baseline flag) to manage accepted risks and false positives.

How do I secure API authentication in CI/CD tests?

Follow the OAuth 2.0 Security Best Current Practice and ensure your DAST tool is configured to handle token based authentication flows.

What is DevOps security?

DevOps security is the practice of protecting the whole software delivery process, including source code, CI/CD pipelines, build systems, secrets, dependencies and deployment environments, without slowing delivery down. It combines automated checks in the pipeline, such as SAST, SCA, secret scanning and IaC scanning, with pipeline hardening against the OWASP Top 10 CI/CD Security Risks, build integrity controls such as SLSA, and periodic human-led penetration testing.

What is CI/CD vulnerability scanning?

CI/CD vulnerability scanning is automated security scanning that runs inside the build and release pipeline. Typical scans are SAST on source code, SCA on open source dependencies, container image scanning, IaC scanning and DAST against a staging environment. Results feed security gates that block High or Critical findings before deployment. It finds known issues quickly but doesn't replace manual testing for business logic flaws and chained attacks.

Integrating penetration testing into DevOps is the definitive way to build secure software at modern speeds. It’s a strategic shift from reactive, end-of-cycle security to a proactive, continuous, and developer-centric model. By leveraging automation, aligning with modern standards like NIST SSDF and SLSA, and fostering a culture of shared responsibility, you can transform your CI/CD pipeline into your strongest security asset.

The journey starts with small, iterative steps: add one scanner, tune the results, and automate a single gate. Over time, these incremental improvements compound to create a resilient, secure, and efficient software delivery process that doesn't just meet compliance requirements (see our PCI DSS 11.3 penetration testing guide); it builds trust with every release.

Ready to Strengthen Your Defenses?

The threats of 2026 demand more than just awareness; they require readiness. If you're looking to validate your security posture, identify hidden risks, or build a resilient defense strategy, DeepStrike is here to help. Our team of practitioners provides clear, actionable guidance to protect your business.

Explore our penetration testing services for businesses to see how we can uncover vulnerabilities before attackers do. Drop us a line, we’re always ready to dive in.

About the Author

Mohammed Khalil is a Cybersecurity Architect at DeepStrike, specializing in advanced penetration testing and offensive security operations. With certifications including CISSP, OSCP, and OSWE, he has led numerous red team engagements for Fortune 500 companies, focusing on cloud security, application vulnerabilities, and adversary emulation. His work involves dissecting complex attack chains and developing resilient defense strategies for clients in the finance, healthcare, and technology sectors.