Invite the people who would have to make a decision or take an action in a real dependency compromise: security, engineering leads, release or platform owners, support, and someone who can approve external statements. Keep the room small enough to talk, and name facilitator, evaluator and participants separately.
Start from decisions, not departments
A dependency compromise forces a handful of decisions. For each one, someone must be able to say yes. If that person is not in the exercise, you will discover the gap during the real event.
| Decision | Role that usually owns it | What the exercise tests |
|---|---|---|
| Is this an incident? | Security lead or incident commander | Declaration criteria |
| Which systems contain the package? | Engineering leads, platform owner | Inventory access |
| Block the version in the mirror or pipeline | Platform or release owner | Whether they have the permission |
| Freeze or continue deploys | Incident commander with release owner | Scope and end condition |
| Rotate credentials | Owners of each secret store | Rotation order and access |
| Customer or public statement | Communications lead, executive approver | Approval path |
| Support responses | Support lead | Prepared answers |
CISA's tabletop packages define separate roles for exercise planners, facilitators and evaluators, and participants. That separation is worth copying even in a small team.
The core group
- Facilitator. Runs the scenario, paces injections, keeps discussion on the question. Not the person who owns the process being tested.
- Evaluator or scribe. Records decisions, timestamps and gaps. See supply chain tabletop roles for how these differ.
- Security. Brings the triage and containment view.
- Engineering representatives. One or two people who know how builds and dependencies really work, including the awkward legacy services.
- Platform or release owner. The person who can actually block a package or hold a deploy.
- Support. Because customers will write in before you have answers.
- An approver for statements. Often a senior leader, who also learns what the first hours feel like.
Seats people forget
Privacy or legal. Bring them for the question of when a notice becomes necessary. They do not need to attend every run, but one session a year builds shared language. This guide gives no legal advice, so use your own counsel for notice rules.
Procurement or vendor management. Useful when the compromised package comes through a supplier.
Whoever owns the mirror, cache or artifact store. These people hold the controls that decide whether the bad version keeps being served.
On call engineers. If real incidents land on them at night, they should know the runbook before they need it.
How big should the room be
Eight to twelve people is workable. More than that and the discussion turns into a presentation. If many teams are involved, run a smaller core exercise and have team leads cascade a short version.
Rotate the participants
Do not invite the same five people each time. A runbook that works solely when its author is present is a risk. Rotate in newer engineers as participants and let senior staff observe, so the plan is tested against people who did not write it.
Quick check
Do executives need to attend?
At least one person with authority over customer statements should. They do not need to attend the whole exercise.
Can we run it without a facilitator?
It is possible, but a participant acting as facilitator will join the discussion and miss gaps. Assign one person to the role.
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.
