Most engineers understand shift-left security as "run SAST in your CI/CD pipeline." That is partially right and significantly incomplete.
SAST (static analysis that scans source code for known vulnerability patterns: it is the natural shift-left tool because it runs in seconds, integrates cleanly into a PR gate, and gives developers feedback in the environment where they work. It belongs in the pipeline. But SAST has a hard structural boundary: it finds code-pattern vulnerabilities and nothing else. Business logic flaws, authorization gaps between user roles, race conditions in transaction flows, API-specific vulnerabilities: these vulnerability classes require a running application, real user sessions, and testing methodology that reasons about runtime behaviour rather than parsing source code.
The practical question for engineering teams building a shift-left security programme is not "should we add security testing to CI/CD?": the answer is clearly yes. The question is which testing tool belongs at which stage, and why placing penetration testing at the wrong stage either breaks the pipeline (too early) or fails to deliver the shift-left value proposition (too late).
This is that guide.
The modern SDLC for teams shipping continuously has five relevant stages for security testing integration:
Stage 1: Code commit / PR creation. Developers write code and open a pull request. Tests that run here must complete fast (ideally under five minutes) to avoid blocking the developer feedback loop.
Stage 2: Build and unit test. CI runs builds and unit tests. Security controls at this stage run alongside standard test suites.
Stage 3: Staging / integration. Code is deployed to a staging environment where integration tests run. The application is live but not in production.
Stage 4: Production deployment. Code ships to production. Post-deploy testing validates what is now live.
Stage 5: Continuous runtime. The running production application is monitored and tested on an ongoing basis between deployments.
Each security testing tool class belongs at a specific stage based on its technical requirements, its runtime speed, and what it can find relative to where in the pipeline a vulnerable code change is most efficiently caught.
SAST scans source code without executing it. It requires access to code but not a running application. It runs in seconds to minutes on most codebases. It integrates directly into PR workflows through native integrations with GitHub, GitLab, Bitbucket, and other source control platforms.
SAST belongs at Stage 1 because it can provide developer feedback at the moment a vulnerability is introduced: before any downstream infrastructure processes the code, before code review, before merging. Finding a SQL injection pattern in a PR is significantly cheaper to fix than finding it in production.
SAST tools: what they catch and what they miss covers the structural boundary of SAST coverage in detail. The summary for SDLC placement purposes: SAST finds vulnerability patterns in code. It does not find vulnerabilities that only appear at runtime, that depend on application configuration, that require interactions between components, or that require operating as specific authenticated users.
Pipeline implementation: SAST runs as a CI check on every PR. Findings above a defined severity threshold block merge. False positive management is the primary operational challenge: SAST false positive rates require tuning to avoid developer fatigue from alert noise that obscures real findings.
DAST tests a running application by sending HTTP requests and analysing responses. It requires a live application instance: source code alone is not enough. Runtime requirements mean it cannot run at Stage 1 (no application exists yet). Speed requirements for PR-gate testing mean it is typically too slow for Stage 1 even with a deployed environment available.
DAST belongs at Stage 3 because staging provides a live application that closely mirrors production without the risk of production disruption from active scanning. DAST scanning against staging runs in the background during integration test cycles.
How DAST compares to agentic AI pentesting on real-world coverage covers what DAST finds and what it misses. For SDLC placement purposes: DAST finds web vulnerability classes with known HTTP signatures (injection patterns, missing security headers, authentication configuration issues). It operates through a single HTTP session and cannot find multi-role authorization gaps, business logic flaws, or API-specific vulnerabilities requiring multi-step authenticated sequences.
Pipeline implementation: DAST runs against the staging environment on every significant deployment or on a scheduled basis during integration test periods. Findings route to the security team for review before production deployment proceeds.
The traditional placement for penetration testing in the SDLC is pre-production: a two-week engagement before a major release. This made sense when releases happened quarterly or annually. It has three failure modes in continuous delivery environments.
The scheduling problem. Manual penetration testing requires scheduling an engagement window. In a team shipping daily or multiple times daily, there is no "pre-production" window that does not immediately precede another production deployment. The engagement completes, the report lands, and three deployments have shipped in the meantime.
The coverage gap. A two-week pre-production engagement tests the code as it existed at the start of the engagement. Every commit made during the engagement period is untested. In high-velocity environments, a significant portion of the production release may have been written during the engagement that was supposed to test it.
The deployment-block problem. If penetration testing findings must be resolved before release, critical findings discovered late in the engagement create hard stops. Teams under release pressure deprioritise or defer findings. The test becomes a checkbox rather than a security gate.
None of these are problems with penetration testing as a methodology. They are problems with placing a two-week manual process in a pipeline designed to move at daily cadence. The solution is not to eliminate penetration testing from the SDLC: it is to find the placement that preserves the value of penetration testing methodology without the scheduling constraints of manual engagements.
Agentic penetration testing conducts the reasoning work of expert penetration testing: observing application behaviour, forming test hypotheses, confirming exploitability, chaining findings: it runs continuously at deployment cadence. The right SDLC placement is post-deploy, triggered by every significant production or staging deployment.
Why post-deploy rather than pre-merge:
Agentic testing requires a running application with real user session handling, real authentication, and real business logic execution. The same reason DAST cannot run at Stage 1 applies: agentic testing requires a live application. But unlike DAST, agentic testing needs the full production-equivalent application stack including real data handling, real external integrations, and production-equivalent authentication configurations.
Staging environments frequently have simplified configurations that produce false results in both directions. Agentic testing against a staging environment with a stub authentication service does not test the production authentication configuration. The most reliable agentic testing environment is production itself, or a production-equivalent staging environment with full application stack parity.
Why post-deploy rather than blocking pre-production:
The deployment-block failure mode that breaks traditional pre-production penetration testing would apply equally to agentic testing if it were placed as a pre-production blocking gate. The fix for the scheduling and coverage gap problems is not to make agentic testing another blocking gate: it is to move it to a non-blocking post-deploy trigger that provides continuous coverage without blocking deployment.
The post-deploy model:
Every significant deployment triggers an agentic test cycle against the deployed application. The test cycle runs against the full defined scope (not just the changed components), producing findings within hours of deployment. Critical findings trigger immediate notification through the same channels the team uses for production incidents. Less critical findings route through the standard vulnerability management workflow.
This model eliminates the coverage gap (every deployment is tested), eliminates the scheduling problem (testing runs automatically on every trigger), and eliminates the deployment-block problem (testing runs after deployment, not before). Continuous penetration testing and how it differs from annual pentests covers the cadence model in detail.
With the right tool at the right stage, a complete shift-left security programme looks like this:
| SDLC Stage | Tool | What it finds | Pipeline behaviour |
|---|---|---|---|
| Stage 1: PR gate | SAST | Code pattern vulnerabilities | Blocks merge on critical findings |
| Stage 1: PR gate | SCA/dependency scanning | Known CVEs in dependencies | Blocks merge on critical CVEs |
| Stage 3: Staging | DAST | Web vulnerability signatures | Non-blocking scan, routes findings |
| Stage 4: Post-deploy | Agentic penetration testing | Business logic, auth gaps, chained paths | Non-blocking trigger, critical findings notify immediately |
| Stage 5: Continuous | Agentic penetration testing | Ongoing coverage between deployments | Continuous, findings route to VM pipeline |
This stack is not sequential with an "and then" relationship between tools: each tool runs continuously at its stage. SAST runs on every PR. DAST runs on every staging deployment. Agentic testing runs on every production deployment and continuously during runtime. The security programme produces findings across all five stages simultaneously.
The "shift left" framing creates a risk of overemphasising the early stages at the expense of runtime testing. SAST and SCA at Stage 1 are valuable. They are also structurally incapable of finding the vulnerability classes that cause the most serious breaches.
The OWASP Top 10 most commonly exploited vulnerability class is broken access control: one user reaching another user's resources. SAST cannot find this. The code that implements access control may be correctly written for the tests SAST evaluates, but fail under conditions that only appear when real user sessions interact with real application state. The security gaps DAST and standard testing misses maps the full coverage gap.
Business logic vulnerabilities are application-specific failures of the rules the application is supposed to enforce. Finding them requires knowing what the application is supposed to do and testing whether the code enforces those rules under adversarial conditions. This is the work of penetration testing, not static analysis.
A shift-left security programme that stops at SAST and DAST has shifted many tests left but has not shifted the tests for the most exploited vulnerability classes. Those classes require runtime testing with reasoning-based methodology: the post-deploy agentic layer.
For engineering teams building the integration, how autonomous pentesting works in a DevSecOps pipeline covers the CI/CD integration in detail. The key integration points:
Deployment trigger: the deployment pipeline sends a webhook to the testing platform on successful production or staging deployment. The testing platform initiates a new test cycle against the deployed application.
Finding routing: findings above a defined severity threshold create tickets in the team's issue tracker (Jira, Linear, GitHub Issues) with full exploitation context, reproduction steps, and remediation guidance. Critical findings additionally trigger immediate notifications to on-call security or engineering leads.
Retest trigger: when a developer marks a vulnerability as remediated and deploys the fix, the next deployment trigger automatically retests the finding to confirm it is resolved. No manual retest scheduling required.
Compliance evidence: the testing platform produces reports from each test cycle that constitute penetration testing evidence for PCI DSS, SOC 2, and ISO 27001 auditors, accumulated automatically as a by-product of the deployment-triggered testing rather than requiring separate engagement scheduling.
API vulnerabilities standard penetration tests miss covers API-specific coverage that is particularly relevant for teams shipping microservice architectures where each service exposes API endpoints requiring independent security validation.
For penetration testing services in the US, agentic penetration testing for the post-deploy continuous coverage layer, and PTaaS for the deployment-triggered model, the 10x Pentest platform covers the runtime security layer. See pricing or get in touch to discuss how agentic testing integrates with your specific CI/CD environment. Penetration testing automation: beyond scripted scans covers the full automation spectrum that shift-left security sits within.
Q1. What is shift-left security testing?
Shift-left security testing means moving security testing earlier in the software development lifecycle rather than reserving it for a pre-release or post-release phase. In practice, it means integrating security tests into the same CI/CD pipelines that run functional tests: static analysis (SAST) at the pull request stage, dynamic analysis (DAST) at staging, and runtime security testing triggered by deployments. The goal is to find and fix security vulnerabilities when they are introduced rather than weeks or months later when the cost of fixing is higher and the exposure window is longer.
Q2. Where does penetration testing fit in a shift-left security programme?
Penetration testing belongs at the post-deploy stage rather than the pre-merge stage in a shift-left programme. Penetration testing requires a running application with real user sessions and production-equivalent configuration: it cannot run at the PR stage. Placing it as a blocking pre-production gate creates the scheduling and coverage gap problems that break at deployment velocity. The correct placement is a non-blocking post-deploy trigger: every significant deployment triggers a penetration test cycle, findings route through the vulnerability management workflow, and critical findings trigger immediate notification. This delivers continuous penetration testing coverage without the deployment-blocking constraints of manual engagement scheduling.
Q3. What is the difference between SAST, DAST, and agentic penetration testing in a DevSecOps pipeline?
SAST (Static Application Security Testing) scans source code at the PR stage without requiring a running application. It finds code-pattern vulnerabilities in seconds and integrates directly into PR gates. DAST (Dynamic Application Security Testing) tests a running application at the staging stage by sending HTTP requests and matching responses against vulnerability signatures. It finds web vulnerability classes visible through external HTTP testing. Agentic penetration testing reasons about application behaviour at the post-deploy stage, confirms exploitability through active exploitation, tests multi-role authorization boundaries simultaneously, and finds business logic and chained attack path vulnerabilities that SAST and DAST structurally cannot. The three tools complement each other at different pipeline stages; no single tool covers the other two's coverage territory.
Q4. Why does agentic penetration testing trigger post-deploy rather than blocking pre-deploy?
Agentic penetration testing runs post-deploy rather than as a pre-deploy blocking gate for three reasons. First, it requires a production-equivalent running application, meaning it cannot run before deployment without a full staging environment that mirrors production. Second, using it as a blocking gate recreates the deployment-block failure mode that makes pre-production penetration testing impractical at deployment velocity: critical findings create hard stops that teams under release pressure defer rather than fix. Third, testing post-deploy on every deployment provides continuous coverage of what is actually running rather than what was running at the moment a blocking gate checked. Critical findings from post-deploy testing trigger immediate notification rather than blocking the next deployment, which keeps teams moving while ensuring vulnerabilities are surfaced and tracked.
Q5. What security vulnerabilities does shift-left testing miss without runtime penetration testing?
Shift-left security programmes that stop at SAST and DAST miss the vulnerability classes that require runtime testing with reasoning-based methodology. These include: broken access control (the most commonly exploited OWASP Top 10 category), which requires testing whether one authenticated user can access another user's resources and cannot be found through code analysis alone; business logic vulnerabilities specific to the application's intended behaviour and rules; race conditions in transaction flows that require coordinated concurrent requests; multi-step attack chains that combine individually minor findings into high-impact breach paths; and API-specific vulnerabilities in GraphQL, REST, and WebSocket interfaces that require authenticated, session-aware testing across multiple endpoints. SAST finds code-pattern vulnerabilities. DAST finds externally visible signature vulnerabilities. Agentic penetration testing finds the rest.
Cyber insurers now require penetration testing as a condition of coverage but not every pentest satisfies underwriting requirements. This guide maps what underwriters actually review and why it matters.
Tejas Dhokane Sep 9, 2026 
An AI agent conducting penetration testing has credentials, tool access, and exploit capabilities. These raise legitimate security questions. This guide maps five risk categories and the design controls that address each.
Tejas Dhokane Sep 8, 2026 
Most "automated penetration testing" is scripted scanning with a different label. This guide maps the full automation spectrum scanners, DAST, BAS, and agentic testing and what each actually does.
Tejas Dhokane Sep 8, 2026 Schedule a free consultation and see how teams like yours are strengthening their security posture — continuously.
