How do you write good injects for a supply chain tabletop?

An inject is a timed piece of new information handed to participants during a tabletop exercise, such as an alert, a message or a customer question. Good injects are specific, arrive in a deliberate order, and force a decision rather than a discussion about theory.

What an inject is and is not

An inject is not a quiz question. It is an event. "A maintainer posts that a release was published without their knowledge" is an inject. "What is your incident response plan?" is not.

CISA's tabletop exercise packages are built around scenarios, objectives and discussion questions that you can customise, plus templates for roles, an invitation, slides, a feedback form and an after action report. Their listed cyber scenarios cover ransomware, insider threats, phishing and industrial control system compromise, and the page does not list a software supply chain scenario. That is a good reason to write your own injects for the dependency and pipeline cases your team actually faces.

The anatomy of one inject

Every inject needs five fields.

Write the expected evidence before the session. It stops the facilitator from improvising and makes the later report fairer.

Pacing: escalate one variable at a time

Four to six injects fit an hour. Change one thing per inject.

1. Detection. Something looks wrong, but it is ambiguous.
2. Scope. You learn how many systems are involved.
3. Impact. A secret, a customer or a deploy is touched.
4. Pressure. An outside party wants an answer.
5. Recovery. Rebuilding and proving the system is clean.

If you escalate everything at once, people stop reasoning and start guessing.

Make the evidence look real

Paste a fake log line, a trimmed advisory, or a screenshot of a ticket. A concrete artifact produces concrete answers. Keep it fictional: invented package names, invented dates, no real victims. Avoid copying wording from real incident reports.

Useful supply chain artifacts include:

• a lockfile excerpt showing a version range
• a workflow file with a mutable tag reference
• a registry page showing a release time that does not match your release calendar
• a cloud console alert from an unfamiliar location

Common injection mistakes

• Too many facts. If one inject lists five findings, participants chase the shiny one.
• Hidden answers. Do not design a puzzle with a trick. The point is to test process.
• Facilitator rescue. If the team is stuck, ask "who would know?" rather than giving the answer.
• No off ramp. Have a spare inject ready if the team moves faster than planned, and a skip list if they move slower.

Reusable inject bank

• A dependency you use has a new maintainer and a release published late at night.
• A scanner flags a package you removed last month, still present in a build cache.
• An internal package name appears on a public registry.
• A vendor emails that "some customers may have been affected" and gives no detail.
• A new hire's laptop is reported lost on the day of the incident.

Pair any of these with the scripts for a compromised GitHub Action or an npm worm.

Try it yourself

Click through it at your own pace, or open it full screen. Notice the style of alert it shows, then reuse that shape as the first inject in your own script.

Safeguard's zero-day discovery and continuous monitoring can supply realistic alert shapes for your drills. A free scan shows what a real finding looks like.

Quick check

Sources

• CISA Tabletop Exercise Packages

Last reviewed: 19 October 2026.