Security testing in CI/CD pipelines in 2026 means running static application security testing (SAST), dynamic application security testing (DAST), and dependency scanning automatically at the appropriate stages of the build and deployment pipeline. Each tool catches a different category of vulnerability: SAST analyzes source code for insecure patterns before the application is built, DAST sends requests to a running application to find exploitable vulnerabilities at the HTTP layer, and dependency scanning identifies known vulnerabilities in the libraries and packages the application depends on. Integrating all three without significantly increasing pipeline run time requires placing each tool at the right stage and configuring it to fail fast on high-severity findings while deferring lower-severity findings to asynchronous review.

Security testing in CI/CD is increasingly a requirement rather than an optional practice. In 2026, SOC 2 Type II audits, PCI DSS v4 compliance, and procurement security questionnaires from enterprise customers routinely ask whether security scanning is integrated into the development pipeline and how findings are tracked and remediated. Beyond compliance, the practical case for pipeline-integrated security testing is the same as for any automated quality check: finding a vulnerability when code is written is faster and cheaper to remediate than finding it in a penetration test six months later or in a breach report. For teams building a structured approach to security testing, Astaqc's test automation services cover security testing integration alongside functional and performance testing in CI/CD pipelines. The complete software testing guide provides context on how security testing fits within a broader quality engineering programme.

The Four Layers of CI/CD Security Testing

Pipeline-integrated security testing in 2026 operates at four layers, each corresponding to a different stage of the pipeline and a different category of vulnerability. Understanding which tool operates at which layer is necessary before deciding where to add security scanning — adding a DAST scanner in a pre-build stage where no running application exists will produce no findings; adding SAST in a post-deploy stage misses its purpose as an early gate.

Pre-commit and pre-push (secrets detection): before code reaches the pipeline, secrets scanners like Gitleaks, TruffleHog, and GitHub Secret Scanning detect accidentally committed API keys, connection strings, and private keys. This is the fastest-feedback layer: secrets are caught on the developer's machine before they enter version control. Fixing a committed secret requires revocation, rotation, and history cleaning — prevention is significantly cheaper than remediation.

Build stage (SAST and dependency scanning): static analysis and dependency scanning run against source code and dependency manifests at build time. These tools do not require a running application and typically add 1–5 minutes to the build stage depending on codebase size. SAST tools like Semgrep, SonarQube, and Checkmarx analyze code structure for patterns associated with injection flaws, insecure deserialization, hardcoded credentials, and similar issues. Dependency scanners like Snyk, Dependabot, OWASP Dependency-Check, and Trivy compare the dependency manifest against vulnerability databases and flag packages with known CVEs.

Test stage (DAST against a running application in the CI environment): DAST scanners send HTTP requests to the application and analyze responses for vulnerabilities. Running DAST in CI requires deploying the application to a CI-internal environment (a Docker container, a review app, or a test namespace in Kubernetes) within the pipeline. DAST is the most time-consuming security testing layer — a full OWASP ZAP scan can take 10–60 minutes — so scope limitation is essential for CI use.

Post-deploy (scheduled or triggered full DAST and infrastructure scanning): comprehensive DAST scans, container image scanning, and infrastructure-as-code (IaC) scanning run on a schedule against deployed environments rather than in the CI path. These scans can take hours and are not appropriate as blocking pipeline gates; they feed findings into a vulnerability management backlog for prioritized remediation.

For teams starting to add security testing to CI/CD pipelines, the priority order is: secrets detection first (lowest time cost, highest impact), then dependency scanning (fast and catches the largest volume of actionable findings), then SAST, then DAST. Each layer adds value independently, so starting with the fastest layers and adding DAST later is a reasonable phased approach. Astaqc's software testing services include security testing pipeline design as part of test infrastructure consulting, and the manual vs. automated testing guide covers how manual penetration testing complements automated security scanning in a complete security testing programme.

SAST: Static Application Security Testing in the Build Pipeline

SAST analyzes source code, bytecode, or compiled binaries for patterns associated with security vulnerabilities. Analysis happens without running the application, which means SAST can run in the build stage immediately after compilation or as a PR check before merging. Because SAST does not require a running target, it is the most pipeline-friendly category of security testing: it runs fast, requires no network access to a deployed application, and integrates directly with version control events.

SAST tools use different analysis techniques with different coverage and false positive rates. Pattern-based SAST (Semgrep, CodeQL rules) matches source code against predefined patterns for known vulnerability classes: SQL string concatenation, unsanitized user input in shell commands, cryptographic algorithm selection, insecure deserialization patterns. Pattern-based tools are fast and have low false positive rates on the patterns they cover, but they miss novel vulnerability patterns not in the ruleset. Dataflow analysis SAST (Checkmarx, Veracode) traces how user-supplied data flows through the application and flags paths where tainted data reaches a sensitive operation without sanitization. Dataflow analysis catches more complex vulnerabilities but produces more false positives and runs more slowly.

Semgrep is widely adopted for CI SAST in 2026 because it is fast (typically under 2 minutes for medium-size codebases), has an active open-source ruleset covering OWASP Top 10 patterns, and integrates directly with GitHub Actions, GitLab CI, Bitbucket Pipelines, and Jenkins. Semgrep can be configured to fail the pipeline only on specific rule severity levels, allowing teams to start with only critical findings as pipeline gates while lower-severity findings are reported to developers without blocking.

The primary SAST configuration decision for CI integration is the severity threshold for pipeline failure. Failing on every informational finding in SAST will block pipelines constantly and train developers to ignore security gates. Failing only on CVSS 9.0+ (critical) findings catches the most severe issues with minimal noise. A practical starting point: block the pipeline on critical and high severity SAST findings; report medium and low findings as PR annotations for developer awareness without blocking merge. Tuning the threshold up or down based on false positive rates after the first 30 days of operation is standard practice. For teams implementing SAST in existing pipelines, Astaqc's manual testing services can complement SAST findings with manual code review for complex vulnerability classes that SAST tools frequently miss, and the testing cost guide covers the cost trade-offs between SAST tooling tiers.

DAST and Dependency Scanning: Runtime and Supply Chain Coverage

DAST sends HTTP requests to a running application to find vulnerabilities that only manifest at the network and runtime layer: authentication bypasses, authorization failures, SQL injection via HTTP parameters, cross-site scripting via reflected input, server-side request forgery via URL parameters, and misconfigured CORS headers. SAST cannot detect these vulnerabilities because they depend on how the application handles HTTP requests at runtime, not on code patterns in isolation.

Running DAST in CI requires the application to be running in an accessible environment when the scan executes. The most common CI DAST pattern is to deploy the application to a Docker network within the CI job, start it on a known port, run the DAST scanner against the local URL (e.g., http://localhost:3000), and fail the pipeline if findings above the severity threshold are returned. OWASP ZAP provides an Automation Framework mode designed specifically for CI use: a YAML configuration file specifies the target URL, the scan policy (which checks to run), and the reporting format. A scope-limited ZAP scan running only the OWASP Top 10 checks against a single application takes 5–15 minutes in CI and catches the most exploitable vulnerability classes.

Burp Suite Enterprise is the commercial alternative to ZAP for teams that need scheduled scans, a vulnerability management dashboard, and integration with issue trackers. Burp Enterprise runs scheduled scans against deployed environments rather than inside CI jobs; findings feed into a project-tracked backlog rather than failing a pipeline gate. For teams with compliance requirements that mandate documented DAST coverage, Burp Enterprise's audit reports provide the evidence format that auditors expect.

Dependency scanning addresses supply chain vulnerabilities: known CVEs in the open-source packages, libraries, and base images the application uses. In 2026, supply chain vulnerabilities are one of the highest-volume finding categories in security programmes. The NPM, PyPI, Maven, and RubyGems ecosystems collectively add hundreds of new CVE disclosures per week. Snyk and Dependabot provide continuous monitoring of dependency manifests against updated CVE databases and generate automated pull requests when a vulnerable package has a patched version available. For container-based deployments, Trivy scans Docker images for vulnerable OS packages, language runtime packages, and misconfigurations in the image layers. Trivy integrates directly with container registries and CI pipelines and typically adds under 2 minutes to a build. For teams scaling security testing to cover both application code and infrastructure, Astaqc's performance testing services include load testing alongside security configuration validation to ensure that security controls do not degrade application performance under load, and Astaqc's QA team service covers ongoing vulnerability management support.

Building a Security Testing Pipeline Without Blocking Releases

The most common reason security testing does not get integrated into CI/CD pipelines is that the first attempt adds too much time to the pipeline or produces so many findings that the team cannot process them without blocking delivery. Both problems are solvable with configuration, but they require deliberately scoped initial rollouts rather than turning on all scanning at maximum sensitivity from day one.

Start with dependency scanning. Snyk or Trivy as a build step adds under 3 minutes to the pipeline and produces actionable findings immediately: packages with known CVEs, base images with vulnerable OS packages, and dependency trees with transitive vulnerabilities. Failing only on CVSS 9.0+ (critical) findings as a pipeline gate and reporting lower-severity findings as informational keeps the initial false-positive noise low. The first two weeks of dependency scanning typically produce a finite backlog of real vulnerabilities that can be addressed in a planned sprint.

Add SAST in the second phase. Configure Semgrep with the OWASP Top 10 ruleset and set the pipeline failure threshold to critical and high findings only. Run SAST as a PR check that runs in parallel with unit tests rather than sequentially after them — this prevents SAST from adding to the critical path. Most medium-size codebases will see between 0 and 20 high/critical SAST findings on the initial run; these should be reviewed and either remediated or marked as accepted risk before enabling the pipeline gate.

Add scope-limited DAST in the third phase. Deploy the application to a CI test environment and run OWASP ZAP's OWASP Top 10 scan against it. DAST produces the most interesting findings — authentication bypass, IDOR, reflected XSS — that static tools miss, but it also produces the most false positives. Configure a DAST baseline to suppress known false positives before enabling it as a pipeline gate. The ZAP Automation Framework supports baseline files that record known false positives so subsequent runs do not re-flag them.

Infrastructure-as-code scanning (Checkov, tfsec, Terrascan) and full DAST should run on a schedule against deployed environments, not as blocking pipeline gates. These scans take longer and cover a broader attack surface than is practical to scan on every commit. Schedule them nightly or weekly, and route findings to a security backlog tracked in the team's issue tracker. Astaqc's test automation services include security testing pipeline design for teams introducing SAST, DAST, and dependency scanning to existing CI/CD configurations. The QA outsourcing guide explains how security testing responsibility is structured in outsourced QA programmes, and testing documentation services at Astaqc cover the documentation of security test coverage for compliance evidence packages.

Frequently Asked Questions

How do SAST and DAST differ, and do I need both?

SAST analyzes source code without running the application; DAST sends HTTP requests to a running application. They find different vulnerability categories with minimal overlap. SAST finds insecure code patterns: SQL string concatenation, unvalidated input in OS commands, hardcoded secrets, insecure cryptographic algorithm use. DAST finds runtime exploitable vulnerabilities: authentication bypass, CORS misconfiguration, reflected XSS, API authorization failures. Both are needed for comprehensive coverage; starting with SAST first is practical because it requires no running application.

Will adding security scanning significantly slow down CI pipeline run times?

Secrets scanning adds under 30 seconds. Dependency scanning adds 1–3 minutes. SAST adds 1–5 minutes for most codebases. DAST in CI, scope-limited to the OWASP Top 10, adds 5–20 minutes depending on the application size. Running SAST and dependency scanning in parallel with unit tests rather than sequentially means only the longest of the parallel steps adds to the critical path. For most pipelines, the net impact on total run time is under 5 minutes for the first three layers. DAST is the only layer that noticeably increases the critical path if run sequentially.

What is a reasonable CVSS threshold for failing a CI pipeline on a security finding?

CVSS 9.0 (critical) is the standard starting threshold for pipeline failure gates. This catches findings like unauthenticated remote code execution and SQL injection with minimal false positive noise. CVSS 7.0 (high) is appropriate after the initial backlog is remediated and the team has established a process for triaging SAST and DAST findings quickly enough that pipeline gates at this threshold do not become a bottleneck. Thresholds below CVSS 7.0 as blocking gates produce too many findings to process without slowing releases.

How do you prevent dependency scanning from generating hundreds of false-positive alerts?

The primary strategy is threshold configuration: fail only on critical CVEs and report lower severity findings without blocking the pipeline. The second strategy is suppression files: both Snyk and OWASP Dependency-Check support configuration files that suppress specific CVE IDs that have been reviewed and accepted as low-risk for the application's deployment context. A CVE in a library function that the application does not use, or a CVE that requires local access to exploit in a remote-only application, can be suppressed once reviewed and documented. Regular review of suppressed CVEs is necessary because the risk assessment may change if the library usage or deployment model changes.

Can DAST be run against production, or only against test environments?

DAST scanners send active attack payloads — SQL injection strings, XSS payloads, path traversal sequences — to the target application. Running DAST against a production application with real user data risks triggering error states that affect real users, generating garbage records in production databases, and triggering fraud detection or rate limiting. DAST should run against dedicated test environments that are isolated from production. Scheduled full DAST against staging environments (which mirror production configurations but have no real user data) is the standard approach for comprehensive coverage without production risk.

What security testing is most important for teams shipping APIs without a frontend?

For API-only services, DAST focused on authentication and authorization is the highest priority. The most common API vulnerabilities — broken object-level authorization (BOLA/IDOR), broken function-level authorization, and JWT misconfiguration — are not detectable by SAST because they involve the runtime authorization logic, not code patterns. Tools like OWASP ZAP with an API definition (OpenAPI/Swagger spec), Postman API security testing collections, and dedicated API security scanners like 42Crunch can run API-specific DAST against the defined endpoints. Dependency scanning and SAST remain relevant for the API codebase itself. The AI in Software Testing Guide 2025 covers how AI-assisted API testing tools are increasingly covering authorization vulnerability patterns in automated scans.