Open Source Supply Chain Attack Simulation: A 1-Hour Exercise Your Team Can Run Today

Supply chain attacks against open-source packages are increasing in frequency and sophistication. Your team needs to practice responding to them — but most tabletop exercises take half a day to plan and 3-4 hours to run. Not every team has that bandwidth.

This article is a complete, facilitator-ready, 1-hour tabletop exercise simulating an open-source supply chain compromise. Print it, gather your team, and run it today. No preparation required beyond reading this page.

Exercise Overview

• Duration: 60 minutes
• Participants: 5–10 (security, engineering, platform, optionally legal/comms)
• Facilitator: 1 person who reads the scenario and injects (can be a team lead or security engineer)
• Materials: This article (printed or on screen), whiteboard or shared document for notes
• Prerequisite knowledge: Basic understanding of CI/CD pipelines, container registries, and dependency management

Ground Rules (Read Aloud — 2 Minutes)

"This is a simulation. There are no wrong answers — only learning opportunities. Respond as you would in a real incident with the tools and access you actually have today. If you're not sure who handles something, say so — that's a finding, not a failure. I'll introduce new information every 10–15 minutes. Let's begin."

Phase 1: Detection (Minutes 0–15)

Scenario (Read Aloud)

"It's Tuesday at 10:15 AM. Your automated dependency scanner flags an unusual finding: a widely-used npm package in your dependency tree — config-utils-pro, used by 340,000 projects — published a new minor version 48 hours ago. The scanner flagged it because the new version adds a postinstall script that wasn't present in previous versions. The script makes an outbound HTTPS request to an IP address that doesn't match the package maintainer's known infrastructure."

Discussion Questions

1. Who receives this alert? Is it the security team, the engineering team, or both?
2. What's your first action? Do you have a process for evaluating suspicious dependency changes?
3. Can you determine, right now, which of your services use this package? How long would that take?
4. Is the suspicious version currently being installed in your CI/CD pipelines?

Inject 1A (After 10 Minutes)

"Twitter/X is now buzzing about this package. A security researcher has confirmed: the package maintainer's npm account was compromised via a phished session token. The postinstall script collects environment variables — including CI tokens, registry credentials, and cloud API keys — and exfiltrates them to the attacker's server. The compromised version has been live for 48 hours."

Phase 2: Impact Assessment (Minutes 15–30)

Discussion Questions

1. Which of your CI/CD pipelines installed the compromised version in the last 48 hours? Can you determine this within the next 30 minutes?
2. What secrets were exposed to those pipeline environments? List them
3. Were any container images built during the compromise window? Are any of those images running in production right now?
4. Do you have SBOMs for your production artifacts? Can you query them to find all instances of this package?

Inject 2A (After 25 Minutes)

"Your SBOM query confirms: 4 services installed the compromised version during their CI builds in the last 48 hours. Two of those services are deployed in production. The CI environment for all 4 had access to: container registry push credentials, Kubernetes deploy tokens, and a Vault token with read access to production database credentials."

Phase 3: Containment (Minutes 30–45)

Discussion Questions

1. What do you do right now to stop the bleeding? Walk me through your first 5 actions in order
2. Do you rotate all exposed secrets immediately, or do you assess which ones were actually exfiltrated first? What's the trade-off?
3. The two production services are handling live customer traffic. Do you take them offline, roll back to a previous image, or keep running while you investigate?
4. Do you need to notify customers? At what point in the incident do you make that decision?
5. The CRA requires notification to ENISA within 24 hours for actively exploited vulnerabilities in products you sell. Does this qualify? Who drafts the notification?

Inject 3A (After 40 Minutes)

"While rotating credentials, your team discovers that the exfiltrated container registry credentials have push access. Checking registry audit logs, you find 2 image pushes from an unknown IP address during the compromise window. The pushed images have the same tags as your legitimate images but different digests. One of those images is currently running in your staging environment — it was pulled 6 hours ago during an automated deployment."

Phase 4: Recovery and Reporting (Minutes 45–55)

Discussion Questions

1. The attacker pushed malicious images to your registry. How do you verify the integrity of every image currently running in every environment?
2. Do you have image signing? If the attacker pushed unsigned images, would your clusters have rejected them?
3. Walk me through your recovery plan: what gets rebuilt, what gets rotated, what gets redeployed, and in what order?
4. The CRA 24-hour notification window is now 20 hours in. Who drafts the ENISA notification? What information do you include? Where is the submission portal?
5. What evidence do you preserve for forensic analysis? Where is it stored?

Phase 5: Debrief (Minutes 55–60)

Scoring Rubric

Score your team honestly on each dimension (1 = no capability, 5 = strong capability):

• Detection speed: Could you identify the compromised package across all services within 30 minutes? (1–5)
• Secret inventory: Did you know exactly which secrets were exposed to the compromised CI environments? (1–5)
• Containment clarity: Did the team agree on the first 5 actions, or was there confusion about priorities? (1–5)
• Image integrity: Could you verify which production images were legitimate vs. potentially compromised? (1–5)
• Regulatory readiness: Did anyone know the ENISA notification process, portal, and required fields? (1–5)
• Recovery plan: Was the recovery sequence clear (what to rebuild, rotate, redeploy), or ad hoc? (1–5)

25–30: Strong capability — your supply chain security is mature
18–24: Good foundation — specific gaps to address
12–17: Significant gaps — prioritise remediation
Below 12: Critical risk — supply chain compromise would cause major damage

Top Findings From Running This Exercise

Having facilitated this exercise with dozens of teams, the most common findings are:

1. No SBOM capability: Teams can't query "which services use this package" without manually checking lockfiles in each repository. This takes hours, not minutes
2. Secret sprawl: CI environments have access to far more secrets than they need. Nobody maintains an inventory of which pipeline has access to which credentials
3. No image signing: Container registries accept any push with valid credentials. There's no admission control to reject unsigned or unknown images
4. Nobody knows the ENISA process: Teams know they need to notify regulators but have never tested the actual submission process
5. Credential rotation is manual and slow: Rotating all exposed credentials takes days because there's no automated rotation process

What Open Empower Delivers

We run supply chain security simulations and build the infrastructure that makes your team ready:

• Facilitated exercises: Custom scenarios calibrated to your actual tech stack and regulatory obligations
• SBOM infrastructure: Automated generation, central storage, instant querying — see our SBOM guide
• Supply chain hardening: Image signing, admission control, CI secret scoping, dependency pinning
• Incident readiness: ENISA notification templates, secret rotation automation, forensic evidence preservation

Run this exercise today. Score your team honestly. Then let's close the gaps.