When your open-source dependency gets compromised, you have about 72 hours to contain the damage before it worsens. CrowdSec's May 2026 breach, which exposed around 300 repositories through a compromised TanStack package, offers a practical example of effective containment.
This template provides the incident response structure their team used: token rotation, lateral movement hunting, and exposure mapping. You're not starting from scratch when your supply chain is breached.
Purpose of This Template
This post-breach response checklist is for open-source projects that discover a dependency attack. It's designed for teams managing both public and private repositories, helping them assess exposure, rotate credentials, and communicate impact quickly.
Use this template when:
- A dependency in your supply chain is flagged in an attack
- You detect unauthorized access to your GitHub organization
- You need to determine what an attacker could have accessed during a known exploitation window
The template assumes you're using a modern CI/CD pipeline, API token-based authentication, and a mix of public and private codebases.
Prerequisites
Before you begin, ensure you have:
Access inventory: A current list of all API keys, service tokens, and credentials your repositories use, mapped to their scope (read, write, admin). If you lack this, you'll need to build it under pressure, costing valuable time.
Repository classification: Know which repos are public, private, and which contain sensitive data. CrowdSec's team knew their private repositories contained SaaS console code, AWS routines, and connectors, which shaped their response.
Dependency manifest: A software bill of materials (SBOM) or equivalent that shows which packages you're using and when you integrated them. This helps correlate your exposure window with the attack timeline.
Audit log access: GitHub audit logs (or equivalent) with at least 90 days of retention, showing who accessed what and when.
Communication authority: Pre-approved disclosure language and a designated spokesperson. You'll need to explain the impact to customers, partners, and possibly regulators within 24-48 hours.
The Response Template
Hour 0-4: Containment and Scope
1. Identify the exploitation window
Cross-reference the dependency's compromise date with your integration timeline. CrowdSec used a TanStack package in May 2026; the malicious artifacts were published during that month. Your window is the overlap between when the malicious version was available and when you rotated credentials afterward.
2. Rotate all potentially exposed tokens immediately
Don't wait for confirmation of exfiltration. Rotate:
- GitHub personal access tokens with repository read/write scope
- CI/CD pipeline secrets
- Cloud provider API keys (AWS, GCP, Azure)
- Service-to-service authentication tokens
- Database connection strings in config files
CrowdSec rotated "all potentially affected tokens and credentials" during this phase. Assume compromise; verify safety later.
3. Map what was accessible
For each compromised token, document:
- Which repositories it could read
- Whether it had write access
- What data those repositories contain
- Whether any customer data or production credentials were present
CrowdSec determined their private repositories contained internal tooling but no customer credentials, which shaped their disclosure.
Hour 4-12: Lateral Movement Hunt
4. Audit for secondary compromise
Search for evidence the attacker used stolen credentials to:
- Create new API tokens
- Add SSH keys to user accounts
- Modify webhook configurations
- Clone additional repositories outside the initial scope
- Commit malicious code to your codebase
CrowdSec's team "quickly hunted for any token, credential, or sensitive leak that could enable lateral movement but found none so far." This step determines whether you're dealing with a read-only exfiltration or an active persistence threat.
5. Review commit history during the window
Check for:
- Unsigned commits from unknown authors
- Changes to dependency manifests (package.json, requirements.txt, go.mod)
- New secrets added to configuration files
- Modified CI/CD workflows that could execute attacker code
Hour 12-24: Impact Assessment
6. Classify the stolen code
For each compromised repository, document:
- Whether it's runnable outside your infrastructure (CrowdSec's code required their network and data to function)
- Whether it contains hardcoded secrets (even expired ones reveal architecture)
- Whether it exposes proprietary algorithms or business logic
- How much it has changed since the breach (CrowdSec noted "most of the leaked code has evolved significantly over those four months")
7. Determine customer impact
Answer:
- Was customer data accessed? (CrowdSec: no)
- Were customer credentials exposed? (CrowdSec: no)
- Could the stolen code be used to attack customers? (CrowdSec: no, requires context-specific infrastructure)
- Do you have a regulatory notification obligation?
Hour 24-72: Communication and Hardening
8. Disclose with specificity
Your disclosure should include:
- Number of repositories affected (CrowdSec: approximately 300, including 170 private)
- Type of data exposed (source code, not credentials)
- Customer impact (CrowdSec: "limited to its own organization")
- Remediation steps taken (token rotation, audit)
- Continuous Monitoring of Active Arrangements plans
9. Implement post-breach controls
- Enable mandatory two-factor authentication for all repository access
- Require signed commits
- Implement secret scanning (GitHub Advanced Security, GitGuardian, TruffleHog)
- Add dependency pinning and hash verification to your build process
- Schedule regular SBOM audits
Customizing the Template
For smaller teams: Combine hours 0-4 and 4-12 into a single sprint. You won't have the staffing for parallel workstreams.
For regulated environments: Add regulatory notification steps at hour 12. Financial services (SR 23-4) and healthcare (HIPAA) have specific timelines.
For SaaS platforms: Add a customer communication template at hour 24. Even if customer data wasn't exposed, your customers' security teams need to know you were breached.
For teams without SBOMs: Start building one now. Use syft or cyclonedx-cli to generate it from your repositories. You can't assess supply chain exposure without knowing what you're using.
Validation Steps
After executing the template:
Verify token rotation: Attempt to authenticate with old tokens. They should fail.
Confirm audit log coverage: Ensure you captured the full exploitation window. If your logs only go back 30 days and the breach was 45 days ago, you have a blind spot.
Test secret scanning: Commit a fake API key to a test repository. Your scanning tool should flag it within minutes.
Document lessons learned: What delayed your response? What information was missing? CrowdSec's clarity on repository contents and lack of customer data exposure suggests they had good asset inventory. Build what you were missing.
Update your SBOM cadence: If this breach caught you because you didn't know you were using the compromised package, you need more frequent dependency audits. Weekly is reasonable for active projects.
The CrowdSec breach shows that even security-focused organizations can fall victim to supply chain attacks. The difference between a contained incident and a cascading breach is having this checklist ready before you need it.
