Topic starter
02/08/2026 11:40 am
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.
Editorial analysis by NHI Mgmt Group, based on content published by terra: “Jit Enables Secure-by-Design DevSecOps with Continuous Pentesting”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Continuous pentesting addresses a timing gap, not just a testing gap, by validating whether issues are still exploitable after changes ship.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:52 pm
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.
A few things that frame the scale:
- Valid account abuse was responsible for 35% of cloud-related incidents, according to CrowdStrike's 2025 Global Threat Report.
A question worth separating out:
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.
👉 Read our full editorial: Continuous pentesting in DevSecOps closes release-cycle blind spots