When a supply chain incident hits, the worst time to figure out your response process is during the incident itself. Game day exercises simulate supply chain attacks in a controlled environment, letting teams practice detection, communication, decision-making, and remediation before a real incident forces them to improvise under pressure.
Game days differ from tabletop exercises in an important way: game days involve actual systems. Instead of discussing what you would do, you do it. You simulate the attack, trigger the alerts, follow the runbooks, and fix the problem. This reveals gaps that theoretical exercises miss -- the alert that fires but goes to an unmonitored channel, the runbook that assumes tool access that nobody actually has, the recovery procedure that takes four hours instead of thirty minutes.
Types of Supply Chain Game Days
Compromised dependency scenario. A popular dependency in your stack is found to contain malicious code. The game day simulates this by replacing a dependency in your test environment with a version tagged as malicious. The team must identify which projects use the dependency, assess the blast radius, determine whether the malicious version reached production, patch or replace the dependency, and communicate status to stakeholders.
Registry outage scenario. The public package registry goes down during a critical deployment window. The team must determine whether builds can proceed with cached dependencies, switch to backup registries or mirrors, communicate deployment delays, and restore normal operations when the registry recovers.
Signing key compromise scenario. Your code signing key may have been exposed. The team must assess the scope of potential compromise, rotate the signing key, re-sign affected artifacts, update verification infrastructure, and determine whether any artifacts signed with the compromised key reached customers.
Account takeover scenario. A maintainer account for one of your published packages is compromised. The team must revoke the compromised credentials, audit published package versions for unauthorized changes, notify affected users, and secure the account with additional controls.
Planning a Game Day
Define objectives. What are you testing? Possible objectives include detection time (how quickly is the incident identified), response coordination (do the right people get involved), decision quality (are the right decisions made under pressure), tool proficiency (can the team use incident response tools effectively), and communication clarity (are stakeholders informed appropriately).
Choose a scenario. Pick a scenario that is realistic for your organization. If you publish open source packages, the account takeover scenario is relevant. If you depend heavily on a specific registry, the registry outage scenario is relevant.
Set scope and boundaries. Define what systems are in scope, what actions are allowed, and what the safety boundaries are. Game days should test the team, not break production.
Prepare the simulation. Set up the test environment with the simulated incident. This might involve deploying a dependency with a known vulnerability, blocking network access to a registry, or creating fake alerts that mimic a real incident.
Brief observers. Have observers who are not participating in the response. They note what works, what does not, and where the team struggles. This feedback is the most valuable output of the exercise.
Running the Exercise
Inject the incident. Start the simulation and let the team discover the problem through normal monitoring and alerting channels. Do not tell them what the incident is -- let them figure it out.
Observe without intervening. Let the team work through the problem. If they go down a wrong path, let them discover it. The learning happens in the struggle.
Introduce complications. Real incidents rarely go smoothly. During the game day, introduce realistic complications: a key team member is unavailable, the primary communication channel goes down, a second issue arises while the first is being addressed.
Time the exercise. Track how long each phase takes: detection, triage, response, remediation, and communication. These timings become benchmarks for improvement.
Debrief immediately. Hold a blameless retrospective immediately after the exercise. What went well? What was harder than expected? What tools or processes need improvement?
Common Findings
Game day exercises consistently reveal several patterns:
Detection is slower than expected. Teams often assume they would notice a supply chain incident quickly. In practice, the alerts may not exist, may go to the wrong channel, or may be lost in noise.
Runbooks are incomplete or outdated. Written procedures that seemed comprehensive have gaps when actually followed. Steps require tool access that has changed, assume knowledge that is not widely held, or skip critical decisions.
Communication breaks down. During high-pressure incidents, communication becomes fragmented. Different team members have different understanding of the situation, status updates are not shared widely enough, and stakeholder communication is delayed.
Recovery takes longer than estimated. Replacing a compromised dependency, rotating a signing key, or re-deploying clean artifacts takes longer than anyone estimated. The actual procedures involve more steps and more approvals than the theoretical process.
Single points of failure exist. One person knows how to rotate the signing key. One person has the credentials for the artifact repository. One person understands the deployment pipeline well enough to modify it under pressure.
Measuring Improvement
Run game day exercises regularly (quarterly is a good cadence) and track metrics over time. Key metrics include time to detection (from incident injection to first human awareness), time to assessment (from awareness to understanding the scope), time to mitigation (from scope understanding to stopping the bleeding), time to remediation (from mitigation to full resolution), and communication effectiveness (measured by observer feedback).
Improvement in these metrics over successive game days demonstrates that the investment in practice is paying off.
How Safeguard.sh Helps
Safeguard.sh provides the supply chain visibility that makes game day exercises realistic and effective. The platform's SBOM generation, dependency tracking, and vulnerability monitoring give your team the data they need to assess blast radius, identify affected systems, and verify remediation during exercises. The same capabilities that support game day exercises become critical tools during real supply chain incidents.