Notifications
Clear all
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.
NHIMG editorial — based on content published by terra: Jit enables secure-by-design DevSecOps with continuous pentesting
Questions worth separating out
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.
Q: Why do periodic security tests leave blind spots in CI/CD pipelines?
A: Because CI/CD environments change faster than scheduled assessments.
Q: What do teams get wrong about automated pentesting?
A: They assume automated coverage is enough on its own.
Practitioner guidance
- 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.
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
👉 Read terra's analysis of continuous pentesting for DevSecOps teams →
Continuous pentesting for DevSecOps teams: what changes in practice?
Explore further
02/08/2026 12:52 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Continuous pentesting in DevSecOps closes release-cycle blind spots
