A supply chain breach tabletop is a facilitated, no-hands-on-keyboard walkthrough of a realistic dependency or build-system compromise, designed to find the gaps in your response plan before an attacker does. It costs one conference room, 90 minutes, and eight people. Every time I have run one, the organization discovered at least one assumption that would have failed catastrophically in a real incident — usually within the first twenty minutes, and usually something embarrassing like "nobody in the room can actually list what we ship."
Generic ransomware tabletops are common. Supply chain tabletops are rare, and they exercise different muscles: inventory, provenance, downstream notification, and the miserable question of whether you are the victim or the vector.
Pick a scenario with a real ancestor
Do not invent a scenario. Adapt a documented incident, because when participants push back with "that would never happen," you get to say it already did.
Three scenarios that work, in increasing order of pain:
- Compromised upstream dependency. A maintainer account for a package deep in your tree is taken over and a credential-stealing payload ships in a patch release. Ancestors:
event-stream(2018),ua-parser-js(2021), the xz-utils backdoor attempt (March 2024). - Compromised CI step. A third-party CI component you run on every build is modified to exfiltrate environment variables. Ancestor: Codecov's bash uploader (2021). Every secret your pipeline has seen in four months is potentially gone.
- You are the vector. Your build system is compromised and you have shipped signed, malicious artifacts to customers. Ancestors: SolarWinds (2020) and the 3CX cascading breach (2023), which was itself seeded by another company's trojaned installer.
For a first exercise, run scenario 1. Scenario 3 is the one your executives need eventually, but it is demoralizing as an opener.
Assign roles before the room fills
A tabletop with spectators is a meeting. Everyone present holds a role:
- Facilitator — owns the clock, delivers injects, refuses to answer "what would actually happen" questions. Should not be the CISO, who needs to participate.
- Scribe — captures decisions, open questions, and every "I'd have to check" verbatim. The "I'd have to check" list is the primary output.
- Participants — incident commander, an on-call engineer who knows the build system, someone from legal, someone who owns customer communications, and the person who can approve pulling a release. If you sell to enterprises, add whoever answers security questionnaires; they will be buried in customer emails within 48 hours of any public disclosure.
Six to ten people. Beyond that, split into two sessions.
Script the injects like a plot
The Master Scenario Events List (MSEL) is your script — CISA's Tabletop Exercise Packages (CTEPs) use the same structure and are a fine free starting point. For the compromised-dependency scenario, a 90-minute MSEL that has worked for me:
| Time | Inject |
|---|---|
| 0:00 | GitHub advisory published: libfoo versions 4.2.1 through 4.2.3 contain a token-stealing payload. Your renovate bot merged 4.2.2 eleven days ago. |
| 0:15 | A customer emails: their EDR flagged outbound DNS from a service running your agent. |
| 0:30 | The stolen-credential angle lands: the payload exfiltrated CI environment variables. Which secrets were in scope? |
| 0:50 | A journalist emails your press address citing the advisory and naming your product. |
| 1:05 | Legal asks: do our customer contracts require notification, and does the 72-hour clock in three of them start now or at confirmation? |
| 1:20 | Stop. Begin the hot wash. |
Deliver injects on paper or in a dedicated channel, not verbally — people re-read them, and re-reading is where the good questions come from.
The questions the facilitator must force
Injects create pressure; questions convert pressure into findings. The ones that matter for supply chain scenarios specifically:
- Can we produce, within one hour, the list of every service and released artifact containing
libfoo4.2.2? With what tool, and who has access to it? Teams with a queryable SBOM inventory — whether that is SBOM Studio or a directory of Syft output andgrep— answer in minutes. Teams without one spend the entire exercise on this question, which is itself the finding. - What was in the CI environment during the exposure window? Not what should have been — what was.
- Who can rotate the deploy credentials, and does rotation break anything at 2 a.m. on a Saturday?
- What do we tell customers, when, and through which channel? Who approves the wording?
- If the answer to any of the above is a person's name rather than a role, what happens when that person is on a plane?
Follow the same sequence a real response would, roughly the flow in our CI/CD compromise investigation guide: scope the exposure window, enumerate what the compromised component could reach, then contain.
The hot wash and the after-action report
Reserve the final 15 minutes for the hot wash while memory is fresh. Three questions, answered by everyone in one sentence each: what worked, what failed, what surprised you.
The after-action report should fit on two pages and every finding must have an owner and a date. Format that survives contact with management:
FINDING 3: No single source of truth for shipped dependency versions.
Evidence: 40 minutes spent reconciling package.json files against
deployed images; two services missed.
Owner: platform team. Due: 2024-09-30.
Fix: SBOM generation in CI, retained per release artifact.
Then — this is the part most teams skip — schedule the retest. The same scenario, six months later, measuring whether the timed questions got faster. Findings without a retest date are aspirations.
Frequently asked questions
How often should we run supply chain tabletops?
Twice a year is the pragmatic floor: one dependency-compromise scenario and one where your own build output is the attack vector. Rotate participants so the response plan lives in more heads than the same five people. After any major real-world incident in your ecosystem, an ad hoc 45-minute mini-tabletop against that specific scenario is cheap and timely.
Do we need external facilitators?
Not for your first few. An internal facilitator who prepares the MSEL properly beats an expensive generalist working from a generic ransomware script. Bring in external facilitation when you graduate to board-level exercises or regulated-industry requirements where independence matters.
What is the single most common failure these exercises expose?
Inventory. Almost every team can eventually answer "are we affected," but the difference between 15 minutes and two days determines everything downstream: containment, customer notification, and whether your public statement is accurate. If you fix only one thing after a tabletop, make it the ability to query what you ship.
How is this different from a red team exercise?
A tabletop is discussion-based: no systems are touched, and the deliverable is a list of process gaps. A red team actually attempts the compromise. Tabletops are cheaper, safer, and better at exposing decision-making and communication failures; red teams validate technical controls. Mature programs run both, tabletop first.