TL;DR: Periodic penetration tests can leave blind spots between releases in fast-moving DevSecOps environments, and Jit says continuous attack simulation helps validate exploitability against the current state of application and infrastructure, according to terra. The governance shift is from episodic assurance to ongoing validation, where security must track change velocity instead of relying on point-in-time findings.
At a glance
What this is: This is an analysis of continuous pentesting in DevSecOps, with the key finding that release velocity can outpace periodic penetration tests and leave exploitable blind spots.
Why it matters: It matters because security teams need assurance that tracks current state, not just scheduled testing windows, especially where CI/CD changes continuously alter attack surface and control effectiveness.
Context
Continuous pentesting is a governance response to a simple problem: if systems change faster than security validation, point-in-time testing goes stale. In DevSecOps environments, that gap creates uncertainty about whether a vulnerability is still present, still exploitable, or already fixed by the time a report lands. The article frames this around a platform team that needed security to keep pace with its own delivery model.
The identity angle here is indirect but real. Modern DevSecOps stacks rely on service identities, secrets, cloud permissions, and automation paths that can shift with every release, so exploitability often depends on access scope as much as code quality. Continuous validation therefore becomes part of change governance, not just a red-team exercise.
Key questions
Q: What breaks when penetration tests do not keep up with DevSecOps releases?
A: Point-in-time assurance breaks down when code, infrastructure, and access paths change faster than the next scheduled test. Security teams can end up reporting issues against an old state while the live environment has already moved on. The result is blind spots, stale prioritisation, and weaker confidence in whether a finding still matters.
Q: Why does running pentesting in CI/CD reduce breach risk more than testing only after release?
A: Running pentesting in CI/CD reduces risk because it finds exploitable weaknesses before public deployment, when remediation is cheaper and the attack surface is still controlled. Once code is live, attackers can scan it automatically and exploit defects quickly. Early testing also helps prevent vulnerable changes from becoming part of the production baseline.
Q: What are the signs that a pentest program is too slow to support modern remediation?
A: Common warning signs include tests booked months ahead, reports delivered only as PDFs or spreadsheets, repeated manual copy and paste into ticketing systems, and no practical way to retest fixes. If teams cannot show progress over time or tie results to remediation timelines, the program is likely measuring activity rather than reducing exposure.
Q: How should DevSecOps teams balance continuous testing with delivery speed?
A: They should make validation part of the release workflow, not a separate gate that stops delivery indiscriminately. The better model is targeted simulation against current change sets, fast triage, and risk-based escalation so security keeps pace without turning every release into a manual approval bottleneck.
Technical breakdown
Why periodic pentests go stale in CI/CD pipelines
Traditional penetration tests sample a system at a moment in time. In a CI/CD environment, code, infrastructure, permissions, and integrations can change many times before findings are remediated, which means a validated issue may no longer reflect the live attack surface. The practical weakness is not testing itself, but the mismatch between testing cadence and deployment cadence. Continuous pentesting replaces the single snapshot with repeated attack simulation against the current state, making exploitability a living property of the release process rather than a post-release artifact.
Practical implication: align offensive testing frequency to deployment frequency, not to a fixed calendar cycle.
How continuous attack simulation fits DevSecOps governance
Continuous pentesting works best when it is treated as part of the operational security loop, not as a detached assurance event. That means simulations are triggered against the latest application and infrastructure state, then results are routed into remediation and release decisions with minimal delay. The architectural value is context. Findings are evaluated against the current stack, so teams can distinguish theoretical issues from reachable attack paths in production-like conditions. For DevSecOps, the control objective is ongoing exploitability assessment, which is materially different from periodic compliance evidence.
Practical implication: connect attack simulation outputs to release gates, triage workflows, and remediation ownership.
Why exploitability matters more than theoretical vulnerability presence
A vulnerability only becomes operationally relevant when an attacker can reach it under current conditions. In fast-moving environments, configuration drift, feature flags, ephemeral credentials, and changing network paths can make a report either obsolete or newly urgent. Continuous pentesting shifts the question from 'does the weakness exist?' to 'can it actually be used now?'. That is especially important in modern application security, where exploitability depends on the surrounding runtime environment as much as the codebase. Security teams need a validation model that measures reachable risk, not just static weakness.
Practical implication: prioritise remediation based on reachable attack paths and current runtime exposure, not report age alone.
Threat narrative
Attacker objective: Confirm and exploit weaknesses that remain reachable in the live environment after continuous delivery changes.
- Entry occurs through the current application or infrastructure state that exists after recent changes, not through a one-time snapshot of the environment.
- Escalation or impact becomes possible only if the live configuration still exposes a reachable attack path when the simulation runs.
- The attacker objective is to identify whether a weakness remains exploitable in the present release state so remediation can be driven by current risk rather than stale findings.
Breaches seen in the wild
- McKinsey AI platform breach: McKinsey AI platform hack exposed 46M chats and sensitive data.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Continuous pentesting is a release-governance control, not just a red-team technique. The article shows why fast-moving DevSecOps environments invalidate the assumption that a quarterly or annual test meaningfully represents current exposure. When change velocity is high, security validation has to become part of the operating model. Practitioners should treat exploitability checks as a release-quality signal, not an afterthought.
Release-cycle blind spots are really control-timing failures. The issue is not that teams lack findings, but that findings arrive after the environment has already changed again. That timing gap undermines confidence in both remediation prioritisation and board-level assurance. Continuous validation narrows the window in which an exploitable state can persist unnoticed, which is the point of secure-by-design discipline.
Context-aware validation is the named concept this article sharpens. Security teams do not need more generic test volume; they need testing that reflects the exact state of code, infrastructure, and access at the moment risk is being assessed. In DevSecOps, the relevant question is whether a control still holds in context. That pushes practitioners toward current-state assurance as the operational norm.
For DevSecOps vendors, security posture is now part of product credibility. When the platform itself changes frequently, internal assurance becomes evidence of how the organisation expects customers to govern their own environments. That raises the bar for lifecycle security, change validation, and proof that controls survive rapid delivery. Practitioners should expect the same discipline from the tools they buy as they demand from their own pipelines.
From our research library:
- Valid account abuse was responsible for 35% of cloud-related incidents, according to CrowdStrike's 2025 Global Threat Report.
- Read next: Agentic AI Security Guide
What this signals
Context-aware validation is becoming the practical replacement for one-off assurance in fast-moving DevSecOps programmes. When the environment changes faster than the next scheduled test, teams need controls that answer whether a weakness is reachable now, not whether it existed at some earlier point.
For identity-heavy delivery stacks, the interesting shift is that exploitability often depends on changing access paths, secrets, and automation context as much as code defects. That makes release governance and security validation part of the same decision chain, especially where continuous delivery alters the live attack surface between reviews.
For practitioners
- Map pentest cadence to deployment cadence Run offensive validation whenever material application, infrastructure, or integration changes occur, so findings reflect the live release state rather than a past snapshot.
- Tie exploitability findings to release decisions Route continuous pentesting results into triage, change approval, and remediation workflows so teams act on reachable risk before it spreads into the next release.
- Prioritise reachable attack paths Separate theoretical vulnerabilities from issues that remain exploitable in the current environment, then rank remediation by present exposure and business impact.
- Validate security in the same context as delivery Test the current combination of code, cloud configuration, access paths, and automation instead of assuming a prior test still describes the system accurately.
Key takeaways
- Continuous pentesting addresses a timing gap, not just a testing gap, by validating whether issues are still exploitable after changes ship.
- The article shows that current-state assurance matters more than stale findings in DevSecOps environments with rapid release velocity.
- Teams should tie offensive validation to live change cycles so remediation, release decisions, and risk prioritisation all use current evidence.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0001; TA0040 — Initial Access; Impact | Continuous pentesting is used to verify whether current release states still expose exploitable attack paths. |
| Recommendation — Map current attack paths to TA0001 and TA0040 to prioritise live exploitability over stale findings. | ||
| NIST CSF 2.0 | ID.RA-01 — Asset vulnerabilities identified and documented | The article is about keeping vulnerability assessment aligned to a changing DevSecOps environment. |
| Recommendation — Update vulnerability assessments continuously so live exposure replaces point-in-time evidence. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Continuous pentesting operationalises ongoing discovery and validation of exploitable weaknesses. |
| Recommendation — Use CIS-7 to align continuous testing with remediation prioritisation and release timing. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | RA-5 directly supports repeated scanning and validation against a changing system state. |
| Recommendation — Apply RA-5 to ensure vulnerability discovery keeps pace with rapid deployment changes. | ||
Key terms
- Continuous Pentesting: A security validation model that checks exploitability repeatedly as systems change, rather than at a single scheduled point. It is designed for environments where releases, integrations, and attack surfaces move quickly, so evidence remains aligned to the current application state instead of a past snapshot.
- Exploitability context: Exploitability context is the evidence used to decide whether a vulnerability matters in a specific environment. It includes reachability, code path exposure, compensating controls, and product-specific advisories, and it turns raw scan data into a decision that can be defended.
- Release-cycle Blind Spot: A release-cycle blind spot is the exposure window created when systems change after a security test has already been completed. The risk is that findings become stale before remediation decisions are made, leaving teams to govern yesterday's state rather than the live environment.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org