SIMULATION ONLY — NOT A REAL SECURITY INCIDENT

This document is an educational tabletop exercise set in an isolated, fictional environment called Project Lantern. It does not describe a real security incident or the compromise of any real-world project, organization, infrastructure, account, maintainer, or user.

Supply-Chain Incident After-Action and Disclosure Plan

Incident date: 2026-07-15
Severity: SEV-1 / critical software-supply-chain incident
Current status: Repository payloads contained; incident remains open pending credential, package-registry, and downstream verification
Private incident record: [INTERNAL INCIDENT TRACKER]
Trusted repository baseline: [TRUSTED BASELINE]

One-minute after-action recap

An attacker-controlled automation path added [MALICIOUS PACKAGE@VERSION] as a production dependency with an install script, introduced automatic execution through a devcontainer, and added GitHub Actions workflows capable of reading the complete Actions secrets context. One workflow also used a cross-repository credential to create proof-of-access markers in matching [EVIDENCE-MARKER-*] repositories.

The activity reached 14 source repositories. In Project Lantern, 14 successful marker runs occurred between 15:09 and 15:53 UTC. The marker hashes do not reveal secret plaintext, but they prove that attacker-controlled code ran with access to the secrets context. All credentials available to those workflows must therefore be treated as compromised.

All 14 repository-cleanup PRs are merged and Actions are disabled on those repositories. The two suspect organization accounts are no longer members, Project Lantern has been restored to its trusted tree, branch protection is enabled, and the 14 private evidence repositories are archived. That is repository containment, not full incident closure. We have not independently confirmed credential revocation and rotation, malicious-package removal, clean downstream rebuilds, or the absence of provider-side credential use.

What we know

Confirmed findings

The malicious production dependency was [MALICIOUS PACKAGE@VERSION]; its lockfile entry declared an install script.
A devcontainer command was configured to execute attacker-controlled code automatically in a developer environment. Execution through that path is not confirmed.
The deleted [MALICIOUS EXFILTRATION WORKFLOW] was configured to put the full Actions secrets context into an outbound request. All ten observed dispatches failed, so plaintext exfiltration through that path is not confirmed.
The deleted [MALICIOUS PROOF-MARKER WORKFLOW] serialized the secrets context, wrote a SHA-256 proof marker to another repository, and used a cross-repository personal access token to push it.
Fourteen source repositories were affected: Project Lantern, two shared configuration repositories, and eleven related service or tooling repositories. Individual repository names are withheld.
All 14 cleanup PRs were merged by 17:14 UTC.
GitHub Actions are disabled on all 14 affected repositories during recovery.
The restored default branch has no tree difference from [TRUSTED BASELINE].
The suspect [SUSPECT AUTOMATION ACCOUNT] and [SUSPECT USER ACCOUNT] are no longer organization members.
Fourteen [EVIDENCE-MARKER-*] repositories remain private and archived as evidence.
Current main protection requires one approval, resolves review conversations, applies to administrators, and blocks force-pushes and deletion.

Not yet established

The initial-access mechanism and whether the automation identity, its token, or another account was compromised first.
Whether every exposed credential was revoked at its issuer, rotated, and checked for misuse.
Whether the malicious package is still available from any registry, cache, release, branch, tag, artifact, or mirror.
The complete set of package consumers and whether each rebuilt from a trusted baseline.
Whether any end-user system, home-automation data, or physical device was accessed. Repository compromise alone does not prove device impact, but it also does not rule it out.
Whether all open, opaque challenge findings represent additional persistence or impact.

Do not say “no evidence of impact” unless the relevant logs were actually collected and reviewed. Use “not yet confirmed” and name the validation still underway.

Timeline

All times are UTC on 2026-07-15 unless noted.

Time	Event
2026-07-14 23:33	Lab-environment changes begin under `[SUSPECT AUTOMATION ACCOUNT]`. A credential is briefly committed and remains in Git history.
14:44	The malicious package is added and locked as a production dependency.
15:02	A devcontainer adds an automatic code-execution path.
15:09	`[MALICIOUS PROOF-MARKER WORKFLOW]` is introduced and proof-marker repositories begin receiving commits.
15:41–15:53	Repeated automated commits and malicious workflow activity continue.
15:53	The final successful Project Lantern marker commit is recorded.
16:34	Repository cleanup begins by removing the devcontainer execution command.
16:36–16:44	The direct exfiltration workflow and malicious dependency are removed in the first remediation PR.
16:52–16:53	The proof-marker workflow is removed in a second remediation PR.
17:01–17:09	Residual artifacts are removed and the trusted lockfile baseline is restored in the final remediation PR.
17:11–17:14	Cleanup PRs across the other 13 affected source repositories merge.

The earliest known malicious dependency commit to organization-wide repository cleanup was approximately 2 hours 30 minutes. Detection time cannot be calculated from the available evidence because the initial alert time was not recorded.

Impact assessment

Confirmed impact

Integrity of 14 repositories and their CI configuration was compromised.
Fourteen successful proof-marker runs executed attacker-controlled workflow code with access to the affected run's secrets context.
A broad credential allowed writes across repositories.
Developer environments could automatically execute the malicious package.
Downstream repository infection occurred through shared automation; automatic package execution was an additional propagation path.
Maintainer time, credential rotation, rebuilds, investigation, and public trust were affected.

Potential impact requiring validation

Use of CI, release, cloud, observability, chat, or third-party-service credentials outside GitHub.
Unauthorized package publication or tampering with release artifacts.
Further propagation from affected downstream repositories.
Exposure of developer environment variables or Codespaces secrets.
Runtime compromise of installed software and, in the worst case, access to home-automation systems.

Scope statement for external use

The safest current statement is:

We confirmed a software-supply-chain compromise affecting 14 project repositories. Known malicious repository artifacts have been removed. We are treating credentials available to affected automation as compromised and are validating registry, downstream, and end-user impact. We will update the advisory as those facts are confirmed.

Root cause and contributing conditions

The root cause is still under investigation. The evidence supports a compromise or misuse of a trusted automation identity or execution context; it does not yet prove how that access was obtained.

Conditions that amplified the incident were:

An automation identity could write directly to protected, high-risk paths.
Workflow, devcontainer, manifest, and lockfile changes lacked mandatory specialist review.
Long-lived credentials crossed repository boundaries.
Secrets were broadly available to workflow execution rather than isolated by environment and job.
Dependency lifecycle scripts and devcontainer startup commands executed code automatically.
Changes to automation files did not trigger a fast enough security alert.
The live incident issue became stale as cleanup PRs merged, weakening the single source of truth.
Package-registry verification requires access not available to the current incident responder.

Current control gaps

Secret scanning, push protection, and code-security features are not enabled.
Branch protection does not yet require status checks, CODEOWNER review, stale-review dismissal, or last-pusher approval.
Reusable workflows and release automation still reference mutable tags such as @latest.
All dependencies flow through a private organization mirror, concentrating package-supply-chain risk.
Package-registry state cannot be verified with the current responder's token scope.

Response assessment

What worked

Responders removed the package, workflow, devcontainer, and residual lockfile artifacts in small, reviewable PRs.
The organization expanded scope from one repository to the full set of 14 affected repositories.
Git history, Actions runs, and proof-marker repositories provided useful forensic evidence.
The suspect identities were removed and branch protection was enabled.
Evidence repositories were preserved privately rather than published or deleted prematurely.

What needs improvement

Code cleanup was initially treated too close to containment; identity, credentials, package distribution, and consumers require separate workstreams and exit criteria.
The first incident record did not remain current as PR states changed.
A credential-by-credential rotation and provider-log matrix should have existed from the start.
Registry access and platform escalation paths should be pre-authorized for the incident team.
Communications should start while containment is underway, with a pre-approved holding statement and a canonical update page.
The plan needs an explicit check that no unrelated upstream project is implicated before any external communication.

Containment and closure criteria

Repository containment is complete. Keep the SEV-1 open until all of the following are evidenced:

Disclosure decision

We will disclose. This is an active supply-chain risk with downstream impact; affected maintainers need enough information to stop propagation, rotate credentials, and rebuild. Reputational concerns do not justify withholding actionable safety information.

Disclosure rules:

Notify people who can stop harm before audiences who only need awareness.
Tell directly affected maintainers before, or at worst simultaneously with, the public advisory.
Do not wait for attribution or a perfect victim count when unknown consumers remain at risk.
Separate confirmed facts, assessed risk, and open questions.
Publish one canonical advisory and point every other channel to it.
Never publish credential values, unredacted logs, private repository contents, victim-specific data, or details that enable further abuse.
Correct errors visibly and timestamp every update.

Notification order

Because the press is already asking, the holding statement and harm-reduction notifications run in parallel. The press does not get a private technical briefing before affected maintainers.

Order	Audience	Timing	Channel	Purpose / owner
1	Incident command, security, repository owners, legal/privacy, and communications	Immediate	Private incident channel and bridge	Establish verified facts, spokesperson, legal clocks, and decision authority. Incident commander owns.
2	GitHub, package registry, credential issuers, and relevant infrastructure providers	Immediate and parallel	Provider security/escalation channels	Revoke access, quarantine packages, preserve logs, and block propagation. Security lead owns.
3	Known affected downstream maintainers and distributors	Within 30 minutes	Security contact, maintainer email, or private advisory	Give indicators and exact containment steps before public attention increases exploitation. Downstream lead owns.
4	Reporter who contacted us	Immediate	Written holding response	Confirm the incident without speculation and point to the forthcoming canonical advisory. Spokesperson owns.
5	Unknown downstreams and the wider ecosystem	As soon as minimum actionable facts are ready; target within 1–2 hours	Public security advisory, registry notice, repository notice, release notice	Reach consumers we cannot identify directly. Security and communications co-own.
6	Users/customers and community channels	Simultaneous with public advisory	Status page, project site, mailing list, community channels	Explain user risk and actions in plain language. Communications owns.
7	Insurer, regulators, data-protection authorities, CERT/law enforcement	Per contractual and legal thresholds; do not wait for public disclosure if a deadline applies	Approved formal channels	Meet legal duties and request coordination where useful. Legal/privacy owns.
8	Press follow-up and full postmortem	Updates every 24 hours while active; full report after validation	Canonical advisory, briefing, postmortem	Close factual gaps and document durable changes. Spokesperson and incident commander own.

If active exploitation is continuing or direct notification cannot reach all consumers quickly, publish the public advisory immediately after the first downstream notices rather than honoring an extended embargo.

Audiences to consider

Maintainers and contributors of all affected source repositories.
Direct and transitive package consumers, integrators, distributors, and mirrors.
End users and operators, including people running home-automation systems.
GitHub, package registries, cloud providers, credential issuers, and security vendors.
Employees, contractors, incident responders, and organizational leadership.
Security researchers and coordinating CERTs.
Customers or partners with contractual notification rights.
Insurers, regulators, data-protection authorities, and law enforcement where applicable.
Press and the broader open-source community.
Maintainers of [UNRELATED UPSTREAM PROJECT], only to prevent accidental association with the simulation.

Existing systems to use

A GitHub Security Advisory as the canonical technical advisory; request a CVE/GHSA if affected published software qualifies.
GitHub's dependency graph, repository search, audit log, Actions run logs, and organization security log for scoping.
Dependabot/GitHub Advisory Database and OSV-compatible publication for machine-readable consumer alerts when applicable.
Package-registry deprecation, quarantine, malware-reporting, download, and dependent information.
Provider security contacts for token revocation and audit-log review.
SECURITY.md and security.txt for inbound reports and a stable security contact.
Project status page, website, release notes, mailing list, and community channels, all linking back to one advisory.
Private archived evidence repositories until the retention decision is approved.

Do not reuse the current release workflow unchanged: it is conditioned for [UNRELATED UPSTREAM PROJECT] and links to that real project.

Draft: immediate press holding statement

We confirmed a simulated software-supply-chain compromise affecting Project Lantern and 13 related project repositories. Known malicious repository artifacts have been removed, affected automation has been disabled or cleaned up, and we are directly notifying downstream maintainers. We are treating credentials available to the affected automation as compromised while we validate registry, downstream, and end-user impact. We will publish indicators, cleanup steps, and timestamped updates at [CANONICAL ADVISORY URL]. We will not speculate about attribution or impact that has not been verified.

Mandatory real-world clarification if this statement leaves the exercise:

Project Lantern is a fictional, isolated exercise environment. This simulation did not compromise any real-world project, organization, infrastructure, account, maintainer, or user.

Short press Q&A

Did you expose secrets?

Attacker-controlled workflow code had access to the Actions secrets context. The stored proof markers are hashes, not plaintext secret dumps, but access is enough for us to treat every available credential as compromised.

How many projects were affected?

We have confirmed 14 source repositories. We are still validating package consumers and downstream builds, so that number may not represent the entire consumer impact.

Were homes or devices accessed?

We have not confirmed access to end-user devices. That investigation is separate from the confirmed developer and CI supply-chain compromise, and we will update the advisory when validation is complete.

Who did this?

We have not made an attribution. Our priority is containment, downstream safety, and preserving evidence.

Why should anyone trust the cleanup?

The affected default branches have been restored to a trusted baseline, the cleanup PRs are public to the exercise participants, and we are adding independent credential, registry, and downstream verification before closing the incident.

Draft: direct downstream maintainer notice

Subject: Urgent security action required: Project Lantern supply-chain simulation

We are notifying you privately because your project may have consumed or inherited compromised automation or package content from Project Lantern.

Confirmed indicators include:

[MALICIOUS PACKAGE@VERSION]

unexpected changes matching [MALICIOUS PROOF-MARKER WORKFLOW] or [MALICIOUS EXFILTRATION WORKFLOW]

unexpected devcontainer startup commands

commits associated with [SUSPECT AUTOMATION ACCOUNT] during 2026-07-15 14:44–17:14 UTC

unexpected [EVIDENCE-MARKER-*] repositories or proof-marker commits

Please act now:

Pause affected builds, releases, and deployments.

Isolate working copies or runners that executed the package or devcontainer command.

Remove the malicious package and workflows; rebuild from a trusted commit in a clean environment with lifecycle scripts disabled for initial verification.

Treat every credential available to affected workflows or developer environments as compromised. Revoke at the issuer, rotate, and review provider logs.

Search branches, tags, release artifacts, caches, and mirrors for the indicators above.

Reply to [SECURITY CONTACT] with the versions/commits used, execution times, and your containment status. Do not send credential values or unredacted logs by email.

We plan to publish a broader advisory at [TIME, UTC] at [CANONICAL ADVISORY URL]. Contact us immediately if a short coordination delay would materially reduce harm.

Draft: wider ecosystem advisory

Title: Simulation advisory: supply-chain compromise affecting Project Lantern and related projects

On 2026-07-15, we confirmed a supply-chain compromise that introduced a malicious package, automatic devcontainer execution, and GitHub Actions workflows capable of accessing CI secrets and writing across repositories.

We confirmed impact to 14 source repositories. Known malicious repository artifacts were removed by 17:14 UTC. Because attacker-controlled code had access to workflow secrets, affected credentials must be treated as compromised even where the available evidence contains only hashes.

If you consumed [MALICIOUS PACKAGE@VERSION], used affected repository revisions, or inherited the identified workflows, stop builds and deployments; remove the artifacts; revoke and rotate accessible credentials at their issuers; review provider logs; and rebuild from a trusted baseline in a clean environment.

We are still validating package-registry state, downstream consumers, credential use, and end-user impact. We will post timestamped updates, affected-version details, and machine-readable indicators at [CANONICAL ADVISORY URL]. Report suspected impact to [SECURITY CONTACT] without including credential values.

Add the workshop clarification at the top before publication outside the exercise.

Draft: user/community notice

We are investigating a confirmed compromise of project development and release infrastructure. The known malicious repository components have been removed. We have not confirmed access to end-user devices, but downstream package and credential validation is still underway.

Do not install or update from the affected project until the advisory identifies a clean version. Operators who installed an affected version should disconnect it from sensitive integrations where practical, preserve logs, and follow the cleanup guidance at [CANONICAL ADVISORY URL]. We will update that page at least every 24 hours while the incident remains active.

Draft: platform or package-registry escalation

We are responding to a simulated software-supply-chain incident involving [MALICIOUS PACKAGE@VERSION] and related repository automation. Please preserve access and publication logs; quarantine or deprecate the affected package without destroying evidence; identify downloads, tokens, and dependent projects during 2026-07-15 14:44 UTC through [END TIME]; and provide an incident escalation contact. We can supply private indicators and commit evidence through an approved secure channel. Do not include credential values in ordinary support tickets.

Defensive postures that would have reduced impact

Prevent or slow initial execution

Require organization rulesets and PR review for all default-branch changes, including administrators and bots.
Require CODEOWNER review for .github/workflows/**, .devcontainer/**, package manifests, lockfiles, .npmrc, release configuration, and ownership files.
Require status checks, dismiss stale approvals, and require approval from someone other than the last pusher.
Deny direct bot pushes to main; use a narrowly scoped GitHub App that opens PRs.
Pin internal dependencies exactly and review new packages, ownership changes, install scripts, and lockfile deltas.
Use npm ci --ignore-scripts for untrusted verification and explicitly allow only reviewed lifecycle scripts where they are required.
Treat devcontainer startup commands as code execution requiring explicit review and user trust.

Limit blast radius

Replace classic, cross-repository PATs with short-lived GitHub App installation tokens or OIDC.
Keep default GITHUB_TOKEN permissions read-only and add minimal permissions per job.
Expose production and release credentials only through protected environments with required reviewers.
Scope secrets to individual repositories and jobs; do not make organization secrets broadly available by default.
Restrict Codespaces secrets to selected repositories and avoid injecting sensitive values before trust is established.
Use separate release identities per project so one repository cannot publish or modify another.
Restrict allowed Actions and pin third-party Actions to immutable commit SHAs.
Add egress monitoring or controls for runners handling high-value credentials.

Detect faster

Alert on workflow, devcontainer, package-manifest, lockfile, branch-protection, organization-member, secret, webhook, deploy-key, and GitHub App changes.
Alert on direct pushes by automation identities and repeated empty or near-empty commits.
Enable secret scanning and push protection across the organization, including organization defaults.
Run dependency review and package provenance checks before merge and release.
Inventory workflow secrets, package publishers, and cross-repository credentials continuously.
Monitor for new repositories matching incident indicators and for unexpected package publications.

Recover more reliably

Maintain a tested credential-revocation matrix with issuer contacts, owners, and validation commands.
Pre-authorize incident access to registry metadata, organization audit logs, Actions logs, and provider audit logs.
Keep signed or otherwise verified release provenance, SBOMs, and reproducible build records.
Prepare downstream and public advisory templates with one canonical status location.
Run supply-chain incident exercises that include package consumers, developer environments, and CI—not only source cleanup.

Changes to the response plan

Split containment into five independently tracked lanes: repository, identity/access, credentials, packages/artifacts, and downstream consumers.
Require evidence for each lane before changing incident status; a clean default branch alone cannot close a supply-chain incident.
Assign a source-of-truth scribe and timestamp incident-issue updates whenever PR or credential status changes.
Add a communications lead at SEV-1 declaration with authority to issue a holding statement within 30 minutes.
Maintain a downstream inventory from dependency graphs, registry data, SBOMs, organization search, and known integrators.
Pre-stage provider escalation contacts and registry-read access for the incident team.
Define an observation window and monitoring queries before re-enabling automation.
Add a mandatory real-upstream confusion check for workshop forks, mirrors, and reskinned projects.
Hold a 24-hour hotwash and a blameless written postmortem within 7–14 days.

Action register

Priority	Action	Owner role	Due / exit evidence
P0	Re-enumerate and revoke/rotate every repository, organization, environment, Codespaces, registry, and provider credential exposed to affected code.	Identity/credential lead	Before incident downgrade; issuer proof and failed-old-credential test.
P0	Verify malicious-package quarantine, download history, dependents, mirrors, caches, and publication tokens.	Package/registry lead	Before public “eradicated” claim; registry evidence attached privately.
P0	Confirm downstream containment and clean rebuild across known consumers.	Downstream lead	Before closure; maintainer acknowledgements and clean build attestations.
P0	Review provider logs for credential use and escalate confirmed misuse.	Forensics lead	Before impact is finalized; reviewed time ranges recorded.
P0	Update `[INTERNAL INCIDENT TRACKER]` to replace stale remediation status and assign remaining tasks.	Incident scribe	Immediate; the tracker reflects current state and owners.
P1	Add CODEOWNERS and complete branch-protection gaps: required checks, stale-review dismissal, and last-pusher approval.	Repository security lead	Before normal bot write access returns.
P1	Replace broad PATs with GitHub Apps/OIDC and protected environments.	Platform lead	Time-bound migration plan approved.
P1	Enable organization-wide secret scanning, push protection, Actions restrictions, and high-risk-file alerts.	Organization security lead	Settings export or audit evidence.
P1	Publish the canonical advisory and direct downstream notices.	Communications/security	As soon as minimum actionable facts are ready.
P2	Resolve or rule out the six opaque open challenge findings.	Investigation lead	Before final incident closure.
P2	Decide evidence-retention duration and delete evidence only after legal/security approval.	Legal/forensics	Written retention decision.
P2	Publish the final postmortem and verify action-item completion at 30 and 90 days.	Incident commander	Postmortem plus follow-up reviews.

Final briefing points

This was not just a bad package; it was a chain spanning package installation, developer startup, CI secrets, and cross-repository credentials.
We contained the known repository payloads across 14 projects in roughly 2.5 hours from the earliest known malicious dependency commit.
We should not declare the incident closed until credential, registry, downstream, and remaining-finding evidence is complete.
We disclose because unknown consumers need actionable information now.
The notification order is defenders and affected maintainers first, public ecosystem immediately after, and press through the same canonical facts.
The biggest defensive gains come from eliminating broad long-lived credentials, requiring review on executable control-plane files, and separating secret access by repository, job, and environment.

Evidence used for this document

A private incident issue maintained as the response system of record.
A reviewed remediation PR that removed the malicious dependency and automatic execution path.
A second reviewed remediation PR that removed the proof-marker workflow.
A final reviewed remediation PR that removed residual artifacts and restored the trusted baseline.
Repository history and a tree comparison against [TRUSTED BASELINE].
Current organization membership, branch-protection, cleanup-PR, and archived evidence-repository checks performed on 2026-07-15

This document intentionally names credentials only by category. Keep token values, unredacted logs, victim-specific information, and private forensic artifacts out of public advisories and ordinary support channels.

BradGroux/SIMULATION-ONLY-INCIDENT-POSTMORTEM-2026-07-15.md