Pick the scenario that matches your biggest worry and your current readiness. For a first run, a hijacked popular package that is already in your lockfiles is a good default, because it tests inventory, blocking and communication together without exotic detail. Save harder scenarios for later rounds.
Match scenario to situation
| If your main worry is | Start with | What it tests |
|---|---|---|
| "We cannot say what we use" | Known bad version in a widely used package | Inventory and search |
| Secrets in CI | Compromised build or test tool | Credential scope and rotation |
| Internal packages | A public package with an internal name | Registry routing |
| Shipped software | Bad version in a released product | Release mapping and customer communication |
| AI assisted coding | Agent adds a lookalike package | Review, tokens, allowlists |
| Slow decisions | Unconfirmed report with no advisory | Triage and decision rights |
Several of these have scripts: internal package name, dev dependency and AI agent.
Three questions to choose
- How good is your inventory? If you cannot search lockfiles in one place, pick the first row. Everything else depends on it.
- Who will be in the room? A small engineering group can run a technical scenario. Mixed groups with executives do better with one that forces a communication decision.
- What happened recently? A real near miss or a public incident makes the scenario feel relevant. Adapt it, and keep real names out of the script.
Use real incidents as inspiration, not scripts
Public incident reports are useful for shape: how long a bad version stayed live, what the first signals looked like, what response steps people took. Use what a reputable source states, and change the names and dates in your version. CISA's tabletop packages offer templates for objectives, scenarios and discussion questions that you can adapt for your own topic.
Keep the first one simple
- One package, one decision-heavy path.
- Four or five injects.
- Sixty minutes.
- A written scoring sheet. See how to score a dependency compromise tabletop.
Avoid layering multiple failures in round one. Complexity hides the lessons.
Plan the second and third rounds
Rotate the scenario each time and keep the scoring dimensions fixed so results compare. A simple progression:
| Round | Scenario |
|---|---|
| 1 | Hijacked popular package in lockfiles |
| 2 | Compromised build tool with CI secrets |
| 3 | Shipped release contains the bad version |
| 4 | Unconfirmed report and fast triage |
Adjust the order to your risks.
Signs you picked wrong
If everyone knows the answers, the scenario is too easy. If the group spends the hour on one missing capability, it is too hard for now, so fix the capability and rerun. Either way, record what you learned and choose the next one with that evidence.
Quick check
Should the first scenario involve a named real incident?
Use real incidents for inspiration, but change names and details. It avoids arguments about what actually happened.
How many injects are right for a first run?
Four or five. More than that and the discussion cannot keep up.
Safeguard can help with the inventory side of this work. SBOM and dependency scanning show where a package and version appear across your projects, and policies and gates can stop a flagged version at the pull request. You can try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
