Labs decay because frameworks, base images and dependencies change. Test each lab before every use, review the full library every six months, and retire anything that teaches outdated practice. Store labs in version control with an owner and a last-tested date.
How labs go stale
Three things break a lab. The setup stops working, because a dependency was removed or a base image changed. The exploit stops working, because a framework now defends by default. Or the lesson becomes outdated, because the recommended fix changed. The first two are visible when you run the lab. The third needs a human to notice.
Treat labs as software
Put labs in a repository with a README per lab: goal, time estimate, prerequisites, hints, solution and last tested date. Pin dependency versions so the lab behaves the same on every run, and keep a lockfile. Review changes through pull requests, like any other code.
Deliberately vulnerable code is still code that can be misused, so keep the repository private to your organization, and make sure no real credentials are committed. Our guide on writing a lab exercise has a template.
The schedule
Before every session. Run the lab end to end on a clean machine. Fix breakage. Note the date.
Each quarter. Rebuild each lab from scratch, update pinned dependencies where safe, and rerun the tests that prove the fix.
Every six months. Review the whole library. Check each lesson against current guidance, such as the OWASP cheat sheets for the bug class, which are maintained pages. If the recommended defense has changed, update the lab and its explanation.
Yearly. Retire labs that nobody has used. Add labs for bug classes that appeared in your own incidents or reviews.
Signals that a lab needs attention
- Setup takes longer than last time
- A participant reports an unexpected error
- The exploit no longer works as written
- A newer framework version behaves differently
- The fix in the lab is no longer what your teams use
Use real findings
The best labs come from your own history. When a review finds a new pattern, sanitize the code and turn it into a lab. Remove names, secrets and anything that identifies customers or colleagues.
Ownership
Name an owner for each lab. Ownerless labs are the first to break. Rotate ownership yearly so that knowledge spreads.
Keep a changelog
A short log per lab helps: what changed, why, and who tested. It also supplies evidence if training is audited.
Quick check
How often should we test a lab?
Before every session at minimum, and a full rebuild each quarter.
Should old labs be deleted?
Archive them rather than delete, but mark them clearly as retired so nobody runs outdated lessons by accident.
Last reviewed: 19 October 2026.
