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: The article argues that continuous pentesting fits DevSecOps better than periodic testing because it keeps pace with frequent platform changes and reflects the current attack surface.
Why it matters: For IAM and security teams, the key issue is whether validation, access controls, and remediation can keep up with release velocity, including the identity and privilege paths attackers exploit.
👉 Read terra's analysis of continuous pentesting for DevSecOps teams
Context
Continuous pentesting is a security validation model that runs attacks repeatedly against the live or current environment instead of waiting for scheduled test windows. In DevSecOps programmes, that matters because release frequency can outpace manual assurance, leaving exploitable weaknesses untested for too long. The article sits in application security, but the governance question is broader: can security controls stay aligned with the pace of change, especially where identities, tokens, and service access are part of the attack path?
For identity practitioners, the intersection is clear. Fast-moving engineering environments depend on service accounts, secrets, and automated workflows, so validation is never just about code quality. It is also about whether privilege, authentication, and access assumptions still hold after each change. That makes continuous security testing relevant to NHI governance, not only AppSec, because stale credentials and overbroad access often become the real exploit path.
Key questions
Q: How should security teams run continuous pentesting without disrupting production workflows?
A: Use narrow test scopes, explicit approval paths, and evidence collection that is aligned to release cycles. The safest model is one where testing agents can validate exploitability without broad, unsupervised production access. That lets teams keep pace with change while preserving reliability, auditability, and operational control.
Q: Why do periodic security tests leave blind spots in CI/CD pipelines?
A: Because CI/CD environments change faster than scheduled assessments. A point-in-time test can miss new services, altered permissions, or freshly exposed dependencies that appear after the assessment. Continuous validation reduces that gap by testing the live or current state of the platform as it evolves.
Q: What do teams get wrong about automated pentesting?
A: They assume automated coverage is enough on its own. Automation is good at scale, but it often misses business logic abuse, chained privilege paths, and the context needed to judge whether a finding is truly exploitable. Automated pentesting works best when paired with human validation and strong remediation governance.
Q: How does continuous pentesting help identity and access governance?
A: It exposes whether service accounts, tokens, and permissions still make sense after each release. That matters because many real attacks move through machine identities rather than code defects alone. Continuous testing should therefore cover credential scope, privilege drift, and the trust paths between systems.
Technical breakdown
Why periodic pentests miss fast-moving attack surfaces
Periodic penetration testing assumes the environment is relatively stable between assessments. In CI/CD-heavy platforms, that assumption breaks quickly because deployments, integrations, and permissions can change many times before the next scheduled test. Continuous pentesting closes that gap by re-running attack simulations against the current code, cloud configuration, and workflow state. The value is not just more testing, but better timing: findings arrive while the exposed path still exists and can be remediated in the same delivery cycle.
Practical implication: tie testing cadence to release cadence, not calendar cadence.
How continuous attack simulation improves exploitability validation
A vulnerability only matters if an attacker can realistically chain it into access, escalation, or impact. Continuous pentesting focuses on exploitability in context, which means the test environment must reflect live integrations, current permissions, and actual runtime behaviour. That is especially important in modern platforms where application security and infrastructure security overlap with identity and secret handling. A static scan may flag a weakness, but continuous simulation shows whether the issue can be weaponised in the environment as configured today.
Practical implication: prioritise findings that demonstrate an end-to-end attack path, not isolated weaknesses.
Why developer-friendly security controls matter in DevSecOps
DevSecOps fails when security validation becomes a bottleneck that teams route around. The article frames continuous pentesting as part of a developer-first operating model, which means findings must be contextual, timely, and actionable enough to fit into engineering workflows. That is a governance design problem as much as a tooling problem. If reports arrive too late or lack operational detail, the control exists in theory but not in the delivery process.
Practical implication: require findings to map cleanly into engineering tickets, ownership, and remediation SLAs.
NHI Mgmt Group analysis
Continuous validation is becoming the practical answer to release-cycle risk. Static assurance models assume change happens slowly enough for scheduled testing to remain useful. In DevSecOps environments, that assumption no longer holds, so the real governance problem is maintaining control coverage as the attack surface shifts between builds. The practitioner conclusion is straightforward: validation must be continuous if the environment is continuous.
Continuous pentesting is as much an identity governance issue as an AppSec one. Modern development pipelines depend on service accounts, tokens, secrets, and machine-to-machine permissions, and those identities often become the exploitable path when configuration changes. If access is not tested alongside code, teams can ship secure software with insecure privileges attached. The practitioner conclusion is to treat identity and access validation as part of the security test plan, not a separate review track.
Change-velocity blind spots define the new assurance gap. The article highlights a common failure mode in fast-moving platforms: security controls that validate the last known state, not the current one. That gap is not solved by more reports alone, but by tighter integration between release events, runtime testing, and remediation ownership. The practitioner conclusion is to align assurance with deployment velocity or accept residual exposure between releases.
Developer-first security succeeds only when it produces engineering-grade outputs. Contextual findings, clear exploit paths, and low-friction remediation matter more than volume. That matches broader DevSecOps practice, where controls fail when they create noise instead of decisions. The practitioner conclusion is to measure security testing by how often it changes code, configuration, or access decisions.
For identity-led teams, this is a reminder that machine access is part of the attack surface. Continuous testing should include the credentials, permissions, and trust paths that modern platforms use to operate. When those controls drift, AppSec findings turn into identity incidents. The practitioner conclusion is to include service accounts and secrets in continuous assurance coverage.
What this signals
Continuous testing will matter more as engineering teams compress release cycles and increase automation. The governance shift is not just about finding bugs faster, but about proving that identities, secrets, and permissions still match the system state after each change. For teams building around machine access, the control question is whether validation can keep pace with deployment without creating review debt.
Change-velocity blind spots: this is the emerging assurance failure mode in DevSecOps. When validation is periodic, the environment can become materially different before the next test completes, and that leaves security teams reacting to a past state. Practitioners should treat deployment frequency, identity drift, and re-test latency as the operational indicators that matter most.
Security leaders should also expect continuous validation to move closer to the places where identity is enforced. That means better coverage of service accounts, ephemeral tokens, and workflow permissions, not just code vulnerabilities. For identity programmes, the message is clear: if access is not tested as part of change control, the organisation is only partially validating its attack surface.
For practitioners
- Implement release-aligned pentesting Run penetration tests and attack simulations on every material change to application logic, cloud config, or workflow permissions so validation reflects the current attack surface, not last quarter's state.
- Include machine identities in test scope Add service accounts, API keys, tokens, and integration permissions to each assessment so identity flaws are evaluated alongside code flaws and runtime misconfigurations.
- Require exploit-path reporting Ask for findings that show how a weakness could be chained into access or impact, then route those results into engineering tickets with clear owners and remediation deadlines.
- Align remediation to CI/CD flow Attach triage and re-test steps to the same delivery workflow that introduced the change so security validation becomes part of the release process rather than a separate queue.
Key takeaways
- Periodic pentesting can no longer keep up with DevSecOps environments that change between releases.
- The biggest governance gap is not code alone but the machine identities and permissions attached to it.
- Security teams need validation, triage, and remediation to operate on the same cadence as delivery.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-1 | Continuous validation maps to ongoing security monitoring of changes and attack surface. |
| NIST SP 800-53 Rev 5 | CA-8 | Continuous pentesting directly aligns with security assessment and continuous validation. |
| CIS Controls v8 | CIS-8 , Audit Log Management | Continuous testing depends on evidence from runtime and change logs to verify exploit paths. |
| MITRE ATT&CK | TA0007 , Discovery; TA0004 , Privilege Escalation | Continuous pentesting is designed to reveal discovery and escalation paths before attackers do. |
Use DE.CM-1 to ensure tests and monitoring track material changes in production and pre-production.
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 Management: Exploitability management is the practice of prioritising vulnerabilities based on whether they can actually be used in a specific environment. It combines vulnerability intelligence, asset reachability, and compensating controls so teams focus on exposure that can lead to real operational impact.
- Change-Velocity Blind Spot: A change-velocity blind spot occurs when a security control assesses an environment after it has already changed materially. In DevSecOps programmes, this creates a gap between what was tested and what is now live, especially when credentials, permissions, and integrations are updated frequently.
What's in the full article
terra's full article covers the operational detail this post intentionally leaves for the source:
- How continuous pentesting is embedded into an operational security stack alongside CI/CD workflows
- What the attack simulation process looks like when it is aligned to current application and infrastructure state
- Why the team positioned continuous validation as part of developer-friendly security operations
- How the approach supports enterprise security reviews without interrupting delivery processes
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to broader security programmes that depend on automation and access governance.
Published by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
