DevSecOps Change Management Lab

A browser-based training lab where you act as the change manager for a fictional software company. Over three pipeline and tooling changes you classify the change, assess risk, choose approvers, plan testing, rollback, the window, communications and verification, and then see a seeded outcome of what happened. It trains judgement about process weight, not pipeline syntax.

Because it alters what every team can ship. A shared pipeline template applies to every repository on its next run, so a blocking rule has a large blast radius. The safeguards are a dry run on real pipeline history, a pilot, a tested hotfix path, and a per-repository waiver that expires.

Not by itself. In ITIL change enablement terms an emergency change is needed to stop active or imminent harm. A severity score is not exploitation. If there is no known exploitation and the vulnerable path is not reachable, a standard bump through the pipeline, with its tests and canary, is both safer and usually faster than a rushed one.

A canary deploys the change to a small slice first and compares error rate and memory with the old version before widening. A base image bump can break a service that pins an old library or raise memory use, and unit tests will not always show that.

Because the failure mode is developer behaviour. A scanner with many false positives teaches people to bypass it. Tuning the patterns, piloting with volunteers, logging every bypass and measuring hook installs wave by wave keeps the control meaningful.

A fast, tried way back: a policy flag that returns a gate to warn, a previous image digest that can be redeployed, or a per-organisation switch that drops a scanner to warn. Waivers and bypasses need an owner and an expiry so the way round does not become permanent.

Each change hides a few risks, such as a blocked hotfix path, a pinned library or a bot that pushes generated files. The seed fixes the dice. Choosing tests, rollback, windows and approvers that address a risk makes it much less likely to fire, and a good rollback or verification limits the damage if it does. The same seed, level and plan always give the same outcome.

Rookie shows a hint at each step and a "watch for" list of hidden dependencies, and has the lowest chance that an unmitigated risk fires. Pro hides the hints, but a good test plan reveals a hidden dependency as you choose it. Elite hides everything until the outcome and raises the chance that an unmitigated risk fires.

A Markdown change record per change, with type, risk, approvers, window, test, rollback, communications, verification, the simulated outcome and the process findings, and a CSV register of all three. Downloading and copying documents is Pro. You can read the same records on the debrief page.

No. Kestrel Works, its people, repositories and the kestrelworks.example domain are invented, and every outcome is simulated in your browser. Nothing here connects to a real pipeline or repository.