A pentest that happens quarterly and a pentest that happens per release carry very different risk models. Continuous pentests catch the bug that shipped last week; quarterly pentests catch the bug that was already there. Moving from one to the other is mostly an operational change, not a tooling rip-and-replace.
This runbook lays out the three moves that get you there: scoping by criticality, authoring a gating rule, and assigning ownership.
Why cadence changes the risk model#
A quarterly test is a snapshot of a moving system. Between two snapshots, dozens of releases ship — and the vulnerability introduced in week two sits in production for ten weeks before anyone looks. Continuous, release-gated testing collapses that window to a single release. This is the practical core of “shift-left”, and it pairs naturally with continuous penetration testing as a program.
Move one: scope by criticality#
Do not gate every service on every commit — that is how teams end up disabling the gate. Tier the estate instead:
- Critical path (authentication, authorisation, anything that touches money): a chain inventory on every promotion to staging.
- Everything else: a weekly run.
This keeps the critical path fast while still producing evidence across the full surface. The criticality lens is the same one used to choose a first target — start where a bug hurts most.
Move two: author the gating rule#
A deterministic chain that confirms privilege escalation is a different object from a noisy signal. Pentrova’s output is designed to be gateable because every finding ships with a replayable bundle. That makes the gating rule simple to state and simple to defend:
# Conceptual gate logic — adapt to your CI system
gate:
block_promotion_when:
- severity: [critical]
status: deterministic # reproduced against the live target
state: unfixed
# No probability threshold to argue about — the chain either
# reproduced or it did not.
If any critical chain is deterministic and unfixed on the candidate build, the build cannot promote.
The rule is easy to author precisely because there is no probability to reason about. A score-based gate invites endless debate about thresholds; an evidence-based gate is binary, which is the CVSS-to-evidence shift applied to the pipeline.
Move three: assign ownership#
Each chain class maps to a service team. The team sees the evidence bundle attached to the CI failure, replays it locally against their fix branch, and confirms the exploit no longer reproduces before merging. Engagement speed matters more than dashboard coverage: a finding a team can replay in two minutes gets fixed; a finding buried in a dashboard does not.
Putting it together#
The end state is a pipeline where a confirmed critical chain blocks a release, the owning team gets a bundle they can replay, and the fix is verified by re-running the exploit. The same loop that proves the bug proves the fix. That is the whole value of release-gating on deterministic evidence rather than scores.
Key takeaways#
- Continuous testing collapses the exposure window from a quarter to a single release.
- Tier by criticality: gate critical-path services on every staging promotion, run the rest weekly.
- Gate on deterministic, unfixed critical chains — a binary rule with no threshold to argue about.
- Map each chain class to an owning team that replays the bundle to verify its own fix.
FAQ#
Won’t gating on security findings slow down releases? Only when the gate is noisy. An evidence-based gate blocks on reproduced critical chains, not on probability scores, so it fires rarely and never on a false positive — which is what keeps teams from disabling it.
Do I need to gate every service? No. Gate the critical path (auth, authorization, payments) on every promotion and run the rest weekly. Over-gating is the fastest way to get a gate switched off.
How does the owning team verify a fix? They replay the finding’s evidence bundle against their fix branch. If the exploit no longer reproduces, the fix is confirmed and the gate clears — the same exploit that found the bug proves the patch.
See how findings become gateable evidence in the platform pipeline, or start a free engagement.