Continuous pentesting is changing how teams validate code risk

At a glance

What this is: OXSecurity frames continuous pentesting as an always-on validation model that re-tests code and infrastructure changes as they happen, rather than waiting for periodic security reviews.

Why it matters: That matters because CI/CD speed can outpace point-in-time testing, leaving teams with stale assurance, noisy findings, and weak evidence that runtime fixes still hold after each change.

Context

Continuous pentesting is the move from scheduled assessment to event-driven validation. In fast-moving cloud and application environments, a quarterly report cannot keep pace with code merges, infrastructure drift, or newly exposed APIs, so the real governance problem is stale assurance rather than lack of testing activity.

The identity angle appears where CI/CD runners, build tokens, and deployment secrets become part of the attack surface. When validation and remediation are embedded in the pipeline, the control question shifts from whether a team tested to whether the pipeline itself can continuously prove that access paths, code changes, and runtime exposure remain within policy.

Key questions

Q: What breaks when pentesting is only done on a schedule?

A: Scheduled testing misses the rate of asset change, so newly deployed services, changed configurations, and temporary exposures can remain live long enough to be exploited. The control failure is not the test itself, but the assumption that a point-in-time view represents the current attack surface.

Q: Why does proof of exploit matter more than scanner output?

A: Because validated exploitability tells you whether a weakness can be turned into real impact, not just whether a detector flagged a condition. That distinction reduces false positives, focuses remediation on reachable exposure, and gives risk owners evidence they can act on instead of a long list of theoretical issues.

Q: What are the signs that continuous pentesting is not giving security teams useful coverage?

A: Warning signs include findings that do not change remediation priorities, repeated blind spots in the same applications, and test results that arrive too late to influence release or control decisions. If the program cannot show what was covered, what changed, and what was verified after fixes, it is more reporting than security assurance.

Q: How should security teams balance AI pentesting with human review?

A: Use AI to expand coverage, repeat workflows, and validate exploitability across a broad API estate, then reserve human specialists for novel architecture, highly bespoke logic, and advanced threat modeling. The best programme assigns each type of work to the place where it is strongest.

Technical breakdown

Event-driven retesting in CI/CD pipelines

Continuous pentesting works by triggering validation when code, configuration, or infrastructure changes occur. Instead of relying on a calendar window, the engine monitors builds, deployments, schema changes, and cloud posture so it can run targeted exploit simulations against the changed surface. That makes the test closer to a regression check than a one-off assessment. The technical value comes from coupling asset discovery with attack chaining, because the tool is not just finding assets, it is proving whether the new state is reachable and weaponisable. This is why the model fits high-velocity release environments better than periodic manual testing.

Practical implication: Treat pipeline events as control points and require re-validation after every material code or infrastructure change.

Proof-of-exploit reduces alert noise

A continuous testing program is only useful if it can distinguish a real exploit path from a theoretical weakness. Proof-of-exploit means the system demonstrates reachability and a viable attack chain before promoting the finding, which cuts down on false positives and dashboard fatigue. This is especially important in DevSecOps workflows, where teams can drown in scanner output if every low-confidence issue becomes a ticket. The downside is that the engine may still miss novel logic flaws or creative attacks, so proof-of-exploit should be viewed as a high-confidence filter, not a complete substitute for adversarial judgment.

Practical implication: Use validated exploitability as the triage threshold and reserve human review for ambiguous or business-logic findings.

Why automated offensive testing still needs human judgment

Automation is strong at scale, repetition, and known attack patterns, but it struggles with abstract business logic and genuinely novel zero-days. Those cases depend on contextual reasoning about how a process should behave, not just whether a vulnerability scanner can execute a chain. In practice, continuous pentesting becomes a baseline layer that broadens coverage while humans evaluate edge cases, sensitive scope boundaries, and the business impact of a flaw. The architectural point is that autonomy expands test frequency, but it does not eliminate the need for expert interpretation.

Practical implication: Keep human analysts in the loop for logic abuse, zero-day uncertainty, and release decisions with business risk attached.

Threat narrative

Attacker objective: The attacker wants to turn a fresh change in the delivery pipeline into a reachable production flaw before defenders validate the new state.

1. Entry begins when code, configuration, or infrastructure changes create a fresh exposure that continuous validation is designed to catch before exploitation.
2. Credential or access abuse can follow when build runners, deployment tokens, or cloud permissions are reachable through the changed pipeline.
3. Impact occurs when an untested change reaches runtime and leaves a flaw exploitable in production before the next manual review cycle.

Breaches seen in the wild

• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
• ArtiPACKED 2024: Unit 42 found public GitHub Actions artifacts in major open source projects leaking live GITHUB_TOKENs, runtime tokens and cloud tokens.

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 validation is becoming a pipeline control, not a testing preference. The article shows that release velocity has turned point-in-time security into stale evidence, especially where CI/CD runners and deployment secrets are part of the attack surface. The governance question is no longer whether testing exists, but whether it is tied closely enough to change events to matter. Practitioners should treat validation as a control embedded in delivery, not a separate assurance activity.

Proof-of-exploit is the right antidote to alert fatigue, but only if teams understand what it cannot prove. A validated exploit path is far more actionable than a theoretical scanner hit, yet it still says little about business logic abuse or unfamiliar attack design. The named concept here is proof-of-exploit prioritisation: the practice of ranking findings by demonstrated reachability instead of raw detection volume. That changes triage discipline, but it does not replace skilled review. Practitioners should use it to compress noise without outsourcing judgment.

CI/CD identity is now part of security governance. When build runners, pipeline tokens, and deployment secrets are the mechanisms by which code reaches runtime, they become operational identities that must be governed like any other privileged actor. This is where the identity bridge matters most: the article is not just about testing depth, it is about trust in machine-driven delivery. Practitioners should re-evaluate pipeline entitlements, token scope, and the security boundaries around automated releases.

Human-in-the-loop remains necessary because autonomous validation has a bounded threat model. The article is clear that automated offensive testing handles scale and repetition, while humans handle novel zero-days and abstract business logic. That division is healthy, because it prevents teams from confusing breadth of coverage with completeness of understanding. Practitioners should design operating models that let automation surface issues quickly without forcing every risk decision through a fully automated queue.

Continuous pentesting is exposing a governance gap between detection speed and remediation capacity. As validation gets faster, the bottleneck shifts to engineering response, exception handling, and release governance. That is a useful discipline signal for the market: mature programmes will be measured less by how many tools they own and more by how quickly validated flaws are triaged into code fixes. Practitioners should align remediation SLAs to validated exploitability, not to the calendar.

From our research library:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• Read next: CI/CD Pipeline Identity Security Guide

What this signals

Proof-of-exploit prioritisation is the right response to validation noise. Security teams do not need more alerts, they need a defensible way to separate reachable exposure from theoretical output. That matters most in CI/CD environments where every release can generate fresh findings and where developer attention is the scarcest control.

CI/CD identity has become a governance problem, not just a delivery problem. Build runners and automation tokens are now privileged actors inside the software supply chain, so their scope and lifecycle need the same scrutiny as human admin access. The operational test is whether your pipeline can prove that machine access remains bounded after each release.

Continuous pentesting will work best where teams align remediation to confirmed exposure. If security still measures success by the volume of issues found, the programme will stall under noise. Mature teams will measure how quickly a validated flaw moves from detection to fix, because that is what determines whether a runtime weakness becomes an incident.

For practitioners

• Embed re-testing into CI/CD gates Trigger offensive validation on pull requests, schema changes, infrastructure edits, and new asset deployment so exposed paths are checked before release.
• Prioritise proof-of-exploit findings Route only reachable, weaponisable findings into the developer workflow and suppress theoretical noise that does not demonstrate a viable attack chain.
• Track pipeline identities and tokens Inventory build runners, deployment tokens, and automation accounts as privileged identities and review their scope, rotation, and ownership alongside application access.
• Reserve human review for logic and zero-day cases Escalate business-logic abuse, ambiguous exploitability, and unfamiliar attack patterns to human testers instead of forcing them through automated triage.
• Measure remediation against validated exposure Use the elapsed time between confirmed exploitability and code fix as the primary operational metric, not the number of alerts produced.

Key takeaways

• Continuous pentesting shifts assurance from periodic snapshots to event-triggered revalidation, which fits high-velocity software delivery far better than annual or quarterly tests.
• The strongest operational value comes from proving that a finding is actually exploitable, because that cuts noise and helps teams focus on issues that can reach runtime.
• Programmes still need human testers for business-logic abuse and novel attack patterns, so automation should expand coverage rather than replace expert judgment.

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.
• Proof-of-exploit: Evidence that a suspected weakness can actually be used to achieve the expected security outcome. In practice this includes the request, response, and reproduction details needed to confirm the issue independently, which separates actionable findings from unverified hypotheses.
• CI/CD runner: A CI/CD runner is the execution environment that performs build, test, or deployment jobs. It often has access to source code, tokens, and cloud credentials, which makes it a high-value identity surface when workflows are compromised.
• Continuous Security Testing: A security model that revalidates an AI agent whenever its prompt, model, tools, memory, or permissions change. For agentic systems, this is not a pipeline stage but a living control that tracks behaviour as the system evolves in production.

Deepen your knowledge

NHI Mgmt Group’s NHI Foundation Level course covers NHI governance, machine identity security, and secrets management, with the industry's only accredited NHI security programme. It helps practitioners connect identity controls to the delivery pipelines and access paths their programmes depend on.