Lion Cipher Lab
Prioritize which findings to retest under a time budget
- Penetration Testing / Red Team
- Intermediate
- ~45 min
- Free · no account required
Why it matters
After a client fixes the findings from a penetration test, they often buy a retest — a limited block of time to verify the fixes actually worked. The time is never enough to re-verify everything, so someone has to choose which fixes to retest. The instinct is usually wrong: testers clear the quick ones first (to show a long list of 'verified'), or they retest strictly worst-first and run out of hours. Both can leave the most risk unverified. The right framing is that each retest costs hours and 'buys back' the risk of that fix, which stays unverified — and therefore uncertain — until someone…
What you'll learn
- framing retest selection as verified-risk coverage
- comparing severity-first, cheapest-first and risk-per-hour rules
- solving the selection as a 0/1 knapsack with dynamic programming
- seeing where quick heuristics leave risk unverified
- reporting what was verified and what remains unverified
- the limits of greedy selection
Steps in this lab
- A retest has a budget, and every fix buys back risk
- The fixes awaiting retest
- Write the selector
- Run it: where the quick rules lose risk
- Use it, and the limit of greedy