This tabletop practices one situation: someone publishes a public package with the same name as one of your internal packages, and a build may have installed it. Run it in 60 minutes with five injects. It tests inventory, blocking, credential decisions and communication, using a scenario that needs no real malware.
What the scenario tests
Dependency confusion happens when a build resolves a name from a public source instead of the private one it was meant to use. The exercise does not need technical detail about any real attack. It needs a plausible chain of events and honest answers about your own setup.
You are testing four things: whether you know which projects use internal package names, whether you can see what a build actually resolved, whether you can block the public name, and whether the team agrees what to rotate.
Setup
Pick a fictional internal package, for example acme-billing-utils, used by four services. Print a one page summary of your real resolution setup: which registries are configured, which names are scoped or reserved, and which pipelines can reach the public registry. Assign facilitator, evaluator and participants. See who should join a dependency compromise tabletop.
The five injects
| Time | Inject | Question to ask the group |
|---|---|---|
| 0 min | A developer notices a public listing with the name of your internal package, published two days ago | Is this an incident yet? Who declares it? |
| 10 min | Build logs show a CI job on service B resolved from the public source on one run | How do you confirm which builds did the same? |
| 20 min | A teammate says the public package contains an install script that contacts an unknown host | What do you assume about secrets in that job? |
| 35 min | A customer success manager reports a customer asking about unusual traffic from an integration | Who talks to the customer, and with what facts? |
| 50 min | The registry has not responded to your report | What can you do without their help? |
Discussion questions
- Where would you look first to see what service B actually installed on that run? Is that data available today?
- Can you block the public name at your mirror or proxy? Who has the permission?
- Which credentials were present in the CI job during the install? Who owns each one?
- Would you rebuild the affected artifacts, and from what source?
- What would stop this from happening again, and how long would each fix take?
Keep the answers specific. "We would check logs" is not an answer until someone names the log and whether it exists.
What good looks like
- Within minutes, the group names the projects that depend on internal packages, from an inventory and not memory.
- A person with authority blocks the public name or reserves it, and the group agrees how to verify the block.
- The team treats the job's credentials as exposed until proven otherwise, and orders rotation by blast radius.
- Communication drafts separate confirmed facts from open questions.
- Someone notes the structural fixes: scoped names, explicit registry routing per scope, and review of lockfile changes that alter a package's source.
Try it yourself
Click through it at your own pace, or open it full screen. Look at where a policy can catch a dependency change before it merges.
After the exercise
Score the session and list gaps with owners and dates. The scoring rubric for a dependency compromise tabletop gives a starting structure.
Quick check
Do we need a real malicious package to run this?
No. A fictional package name and scripted facts are enough, and safer.
What is the most common gap found?
Teams often cannot show what a past build resolved. Build logs and a stored dependency inventory close that gap.
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.
Last reviewed: 19 October 2026.
