GitHub recently ran the first Secure Open Source Fund "Repository Under Attack" Red Team Workshop. It was a simulated software supply-chain incident for open source maintainers, but the lesson applies well outside open source: incident response is not something a team should be designing for the first time while the incident is already moving.
Brad Groux took part in the workshop, and his team, Porcupine-Forge, came out on top. Tools helped. Codex, OpenClaw, and GitHub Copilot were useful during the exercise. But the bigger lesson was not "AI can help during an incident." The bigger lesson was that the useful tooling only worked because the response had structure around it: evidence, roles, decisions, tasks, verification, and communication.
That is the part businesses should pay attention to.
Repository cleanup is not incident closure
The sanitized after-action report from the workshop is available in Brad's public gist. The simulated incident involved a malicious production dependency, automatic execution through a devcontainer, GitHub Actions workflows with access to secrets, and cross-repository credentials.
In the exercise, the known malicious repository artifacts were removed. Cleanup PRs were merged. Actions were disabled on affected repositories. Suspect identities were removed. Branch protection was enabled. That sounds like the finish line if the team only thinks in terms of source control.
It was not the finish line.
Repository containment is one lane. It does not prove every credential was revoked at the issuer. It does not prove package registries, caches, artifacts, mirrors, or downstream consumers are clean. It does not prove provider logs were reviewed. It does not prove a published package was not consumed somewhere else. It does not prove the business is ready to tell affected users what happened and what they should do next.
That distinction matters for open source maintainers, and it matters for businesses running internal apps, SaaS platforms, finance workflows, Microsoft 365 automation, Power Platform apps, ERP integrations, field systems, and AI agents. A clean repo, a fixed workflow, or a reverted change may be necessary. It is rarely enough.
The plan needs lanes before the incident
One practical takeaway from the exercise was to split response work into separate lanes. Businesses should do the same before they need it.
- Repository and application containment: remove malicious code, disable unsafe automation, restore trusted baselines, and preserve evidence.
- Identity and access: remove suspect users, suspend risky automation, review permissions, and verify high-risk administrative paths.
- Credentials: enumerate secrets, revoke at the issuer, rotate replacements, and test that the old values fail.
- Packages and artifacts: check registries, release assets, caches, build outputs, mirrors, and dependency consumers.
- Downstream impact: identify who may have consumed the affected software, data, workflow, integration, or automation.
- Communication: prepare holding statements, direct notices, status updates, executive briefings, and public guidance when needed.
Those lanes should have owners. They should have evidence requirements. They should have a stop condition. Without that, the response turns into a long chat thread where everyone is busy and nobody is sure what "done" means.
Businesses need a source of truth
During a real incident, the status will change quickly. A PR merges. A key is rotated. A provider replies. A customer reports something new. A system owner says the affected credential was never used in production. Then someone finds an old deployment job that had access anyway.
If the source of truth is scattered across Teams messages, Slack threads, email, screenshots, and somebody's notes, the organization will lose time when time matters.
A good incident record does not need to be fancy. It needs to be trusted. At minimum, it should track:
- confirmed facts
- open questions
- affected systems
- decisions and who made them
- task owners
- credential status
- communication status
- evidence links
- closure criteria
That record also protects the team from making stronger claims than the evidence supports. Do not say "no impact" when the real answer is "not yet confirmed." Do not say "contained" if credentials, packages, provider logs, and downstream consumers have not been checked. Say what is known, say what is still being validated, and keep updating the same canonical place.
Credential rotation cannot be improvised
Credential work is where many incident plans get exposed.
It is easy to say "rotate the secrets." It is harder to know which secrets existed, where they were issued, which systems used them, who owns them, which workloads will break when they change, how to prove the old values no longer work, and which logs show whether they were abused.
That work should be mapped before an incident. For each important system, a business should know:
- where secrets are stored
- who owns the issuer
- how revocation works
- how rotation is tested
- which workloads depend on the value
- which logs prove use or non-use
- which emergency contact can help after hours
This is not glamorous work. It is also the difference between a contained incident and a long guessing exercise.
Communication starts before perfect certainty
Every incident has open questions. Waiting for perfect certainty can make the response safer legally in the short term and worse operationally for everyone else.
The better pattern is to prepare communication templates and rules ahead of time. Who gets notified first? What facts are required before a holding statement goes out? Who can approve the language? Where does the canonical advisory live? What never gets published, such as credential values, private logs, customer-specific data, or unredacted forensic details?
The workshop after-action report used a simple rule that applies well to businesses: notify the people who can stop harm before audiences who only need awareness. That may mean platform providers, package registries, affected maintainers, internal system owners, customers, regulators, insurers, or law enforcement depending on the incident.
The point is not to turn every event into a public crisis. The point is to avoid writing the communication plan while legal, security, operations, support, leadership, and customers are all asking different versions of the same question.
Why this matters for AI and automation
More business workflows now include automation, low-code apps, agents, CI/CD pipelines, Microsoft 365 connectors, cloud services, and third-party APIs. That makes incident preparation more important, not less.
An automation account with broad access can create the same kind of blast radius as a careless administrator. A workflow secret can become a production credential problem. A dependency update can become a supply-chain issue. An AI agent with tool access can become another execution path that needs identity, policy, audit, and rollback.
Digital Meld's view is straightforward: if a system can take action for the business, it belongs in the incident plan. That includes the boring systems nobody puts on the architecture slide.
What leaders should ask this week
A business does not need to wait for a tabletop exercise to start improving incident readiness. Start with a short working session and ask practical questions:
- If a critical workflow is compromised, who declares the incident?
- Where is the single source of truth?
- Which identities and automations can write to production systems?
- Which credentials would need immediate revocation?
- Who has authority to disable builds, apps, connectors, jobs, or agents?
- Which vendors or providers have emergency escalation paths?
- What is the first holding statement?
- How will the team prove the incident is contained?
- What evidence is required before saying it is closed?
If those questions create uncomfortable silence, that is useful. It means the exercise found the gap while there is still time to fix it.
Run the drill before the real thing
The GitHub Secure Open Source Fund gives maintainers security education, expert support, health reviews, and incident management guidance. Open source needs that support, because maintainers often carry infrastructure risk for far more users than their project funding would suggest.
Business teams need the same discipline. The names change, but the work is familiar: know the owners, map the credentials, protect the source of truth, prepare the communication path, and define closure before pressure arrives.
Start small if needed. Pick one important workflow. Run a two-hour tabletop. Pretend a token leaked, a package was compromised, a connector was abused, or an automation account made an unauthorized change. Then write down what broke in the plan.
That is the value of a good exercise. It gives the team a chance to fail privately, fix the process, and be less surprised when the real incident does not care how busy everyone already is.