Before a dependency compromise tabletop, confirm ten practical things: you can search for a package, you know who can block it, you can reach key people, and your logs exist. If several answers are no, fix those first or run the exercise anyway and record each no as a finding.
Why prework matters
A tabletop is meant to test decisions and coordination. If half the session goes to discovering that nobody has registry access, you learn that, but you lose time to practice the rest. A short prework check gets the basics visible and sets realistic expectations.
CISA's tabletop packages include planning documents, a participant feedback form and an After Action Report template. The prework below fits the planning stage.
The ten checks
| # | Check | Yes or no |
|---|---|---|
| 1 | Can you search all lockfiles, or SBOMs, for a package name and version in one place? | |
| 2 | Can you list what is inside a built artifact or image without the source repository? | |
| 3 | Do you know who can block a package version at the mirror, proxy or pipeline? | |
| 4 | Does that person have the permission today, not only on paper? | |
| 5 | Can you pause automated dependency update pull requests and scheduled rebuilds? | |
| 6 | Is there a list of credentials used in CI, with an owner for each? | |
| 7 | Is there a contact sheet with current names and a second way to reach people? | |
| 8 | Is the runbook in a place people can find, and has someone read it in the last quarter? | |
| 9 | Do you keep build and CI logs long enough to cover a few weeks back? | |
| 10 | Is there a named approver for external statements? |
How to use the table
Send it to the planning group a week ahead. Ask each owner to check their rows with evidence, not memory. If the answer is "I think so", count it as a no until proven.
Row 1 and row 2 deserve extra time. Inventory is the question every incident starts with, and a tabletop where the answer is "we would ask each team" will drift. If you are missing an inventory, the one hour shadow dependency sweep is a quick way to build a first one.
What to do with the no answers
Sort them into two groups.
- Fix before the exercise. Quick wins such as updating the contact sheet, granting a permission, or moving the runbook to a shared location.
- Test during the exercise. Larger gaps such as no central inventory. Run the scenario anyway and let the group feel the delay. Record the gap as a finding with an owner.
Keep the exercise honest
Do not rehearse the answers. A common failure is a group that preps the facilitator's questions and presents polished replies. The purpose is to find what breaks. Give the facilitator permission to ask follow-ups that were not in the plan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at what a single searchable inventory looks like, since it is what row 1 asks for.
Quick check
Should we delay the tabletop until all ten are yes?
No. A few no answers make good material. Delay if the gaps would make the exercise meaningless.
Who owns the prework?
The exercise planner assigns each row to the person who can evidence it, then reviews the table the day before.
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.
