Lion Cipher Lab
Find the commit that broke a security check with git bisect run
- Foundations
- Intermediate
- ~45 min
- Free · no account required
Why it matters
Security checks rarely break with a dramatic commit titled 'remove security.' They break in a tidy refactor that looks like an improvement, sixty commits ago, and nobody notices until a pentester or an attacker sends a link like //evil.example/login through your login redirect. When that happens, the first question in the incident is 'when did this break, and what else shipped with it?' git bisect answers it in a handful of test runs instead of an afternoon, and it does it mechanically, so it works even when you do not understand the code yet. Every developer, AppSec engineer and DevSecOps…
What you'll learn
- what a regression is and why security regressions hide inside harmless-looking refactors
- binary search over commit history with git bisect start / bad / good
- marking commits by hand, including git bisect skip for commits that cannot be tested
- automating the hunt with git bisect run and the exit-code contract (0 good, 1-127 bad, 125 skip)
- reading git bisect log and cleaning up with git bisect reset
- writing a small, deterministic Python security test that a tool can trust
- fixing the regression with git revert and keeping the test so it never comes back
- judging when bisect beats reading the diff, and when it does not
Steps in this lab
- The idea: a regression, and why halving beats walking
- Open a terminal and confirm git and Python are installed
- Build the throwaway repo: 60 commits, one quiet break
- Meet the security test, and its three exit codes
- The slow way first: walk the history and count
- Bisect by hand: start, bad, good, and a skip
- Automate it: git bisect run, and measure
- Fix it, and keep the test so it never comes back
- Judgment: when bisect is the right tool, and where it fails