To pick supply chain tabletop scenarios without guessing, take the SLSA threat categories (source, dependency, build, availability, verification) and write one scenario per category that matches something you actually run. Rotate through them over a year so you cover each area once.
The SLSA categories
The SLSA specification groups supply chain threats into five categories and labels the main ones A to H. These come straight from the threats page.
| Letter | Threat | Plain meaning |
|---|---|---|
| A | Submit unauthorized change | A change gets through normal source control without admin rights |
| B | Compromise source repo | Admin access or infrastructure compromise changes the repository |
| C | Build from modified source | Code built does not match the official repository |
| D | Use compromised dependency | Malicious code enters through something you build or run with |
| E | Compromise build process | The build is tampered with or provenance is falsified |
| F | Upload modified package | A package is published without going through the proper process |
| G | Compromise package registry | Packages or provenance are modified on the registry |
| H | Use compromised package | A package is altered after the registry, or a lookalike is used |
SLSA also names availability threats, such as deleted source or a dependency that becomes unavailable, and verification threats, such as forged change metadata or hash collisions.
One scenario per category
| Threat | Example scenario | Our script |
|---|---|---|
| A, B | A maintainer account is taken over and a backdoor is merged | Adapt the maintainer release script |
| D | A popular action or library is compromised | GitHub Action script, npm worm script |
| E | Your runners run attacker code | Build from the CI angle of the action script |
| F, G | A bad release reaches a registry | Malicious release script |
| H | Lookalike or hallucinated name installed | AI assistant script, internal name script |
| Availability | A dependency disappears from the registry | Pair with a monthly offline build drill |
How to choose this quarter's scenario
- List what you actually use: registries, CI platform, container base images, editor extensions, AI tools.
- Mark which threats apply to each.
- Pick the one where you have the least confidence in your answer.
- Write three objectives for it.
- Run it, record the results, then pick the next.
Why this beats random scenarios
Copying a famous incident can turn the session into a history lesson. Starting from threat categories keeps the focus on your controls. You can still dress the scenario in a recent real event for realism, using only facts from the public record, but the objectives stay about your readiness.
Also keep a "known gaps" column: if you already know you cannot answer a scenario, do the fix first and test it after. A tabletop is for finding unknowns, not confirming known holes.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how items are mapped to a framework, then do the same for your scenarios and threat letters.
Safeguard offers compliance and evidence automation plus SBOM and dependency scanning, useful for tracking which threats your controls address. Start with a free scan.
Quick check
Do we need to cover every SLSA threat?
Not in one exercise. Cover the ones relevant to your stack over a year and revisit them as your tooling changes.
Is SLSA a certification?
No. It is a specification with levels and a threat model. Use it as a checklist for planning, not as a badge.
Sources
Last reviewed: 19 October 2026.
