When you learn that a dependency has been compromised, you may need to pause affected work before confirming whether it ran in your environment. The next npm install could fetch an affected version; an import or local test run could execute code already downloaded. An unapproved release may already be reaching customers. In each case, you need a fast, trusted way to reach someone who can stop affected jobs or suspend publishing.

This article is a tabletop starting point for AppSec engineers working with platform, identity, and endpoint teams. The three scenarios are fictional; adapt their systems and assumptions to your environment. Read each case through, pause at the decision, and compare your response with the walkthrough. Keep the two-page incident response checklist beside you to record owners, scope, and supporting evidence.

Before starting, identify a response lead, technical owners, backups, and a trusted communication channel. Agree who can pause development or publishing while the investigation proceeds.

A researcher publishes an advisory identifying malware in an npm package version. Your project has no committed package-lock.json, and the version range in package.json allows the affected release. A CI build is due to run, and nobody has yet checked recent developer installs.

The platform owner pauses the affected CI workflows and cancels queued or running jobs. Developers receive instructions to stop installs, updates, tests, and builds in affected projects and report what they have already run. Confirm which jobs were stopped and when; track developer acknowledgments and environments still being checked.

If you have a malware-blocking proxy in place, such as the one in Boost Developer Endpoint Protection, confirm that it rejects downloads of the affected version. Record where it is enforced and review available download records. Earlier downloads, cached copies, and environments outside its coverage still need investigation.

A developer reports installing the package earlier that morning and running the project's tests. In this scenario, the installation log identifies the affected version, and endpoint records show its code executing during the test run. Malicious code can run in an install script or later, when tests, build tools, or the application import the library. As Shai-Hulud campaigns demonstrate, local execution can expose credentials that allow further compromise and package publication.

Pause here: What access would you restrict immediately, and what records would establish whether the attacker went further? Use checklist 03A and 04–10.

The endpoint owner isolates the laptop and preserves available evidence before rebuilding. From a trusted system, the identity owner revokes credibly exposed access, prioritizing publishing, administration, and production. They also check active sessions, refresh tokens, derived credentials, and newly created access; a replacement secret alone would leave those questions unresolved.

A saved query links a source-control token available on the laptop to an unexpected workflow run. Identity records connect that run to a cloud session, so the cloud owner restricts its access while investigators trace subsequent activity. The response record separates observed use from other reachable resources and explicitly lists gaps in audit log coverage.

The team restarts the reviewed CI jobs with verified dependency versions and replacement publishing credentials issued into a clean build environment. The laptop stays isolated until recovery and replacement access are validated; the cloud owner keeps access restricted until the suspect session is invalidated or expires. The status update tells developers which work can resume, what remains suspended, who is investigating, and when they will hear more. Removing the upstream package does not remove cached copies or credentials already taken.

A researcher reports that an active PR test run can feed attacker-controlled content into a privileged workflow. In an open-source project, the contribution might come from a public fork. In a large organization, the same boundary can exist between an internal contributor and another team's release authority.

For this exercise, a release workflow downloads the project archive produced by the PR job and runs its build script with publishing credentials available. The PR job itself had limited permissions, but its output is now being used by a job with greater access. The response lead contacts the platform owner, who cancels the PR job and pauses the release workflow.

Pause here: Does stopping the PR's job contain the incident if another workflow already consumed its output? Use checklist 03B, 07, and 10–11.

Preserve the triggering event, approved and executed commit SHAs, job logs, artifact identifiers, and downstream run records. Check the revision actually executed against the one reviewed. In this scenario, the release-job logs confirm that the build script already ran with publishing credentials available. Containment now includes that runner, its credentials, and any outputs it produced.

The investigation follows the artifact into the release run and checks for credential issuance, registry activity, and further access. A valid signature or provenance record can identify the producing workflow without establishing that its inputs were authorized or safe. Record suspect package versions and digests, known consumers, and distribution that remains unknown.

Before restarting, the platform team changes the release workflow so it no longer runs build scripts supplied by PR artifacts, reviews its permissions, and tests the revised workflow with harmless inputs. The incident lead checks that queued jobs, reruns, alternate triggers, and delegated automation cannot restore the same route. Suspect outputs are replaced through a trusted build and publishing path.

The release owner authorizes resumption for the validated workflow and artifacts, with unresolved outputs still quarantined. Developers receive precise instructions about which jobs may run; downstream recipients receive affected identifiers and mitigation guidance through the designated communication owner.

An engineer notices a new package version published overnight, when no release was scheduled. Publication records associate it with a familiar employee account, but the release owner finds no matching approval. The employee describes it as maintenance. The team checks for an authorized exception while restricting further publication.

An independent administrator restricts the implicated account's publishing access and protects evidence outside its administrative reach. The response lead involves designated insider-response, HR, and legal contacts through a restricted channel. The technical investigation separates the account's recorded actions, the authority granted to it, and the question of who operated it.

Pause here: Could another credential or service account restore the access you just removed? Use checklist 03C, 05–07, and 11.

Audit records show that the account created another publishing credential before the release. Removing its original token therefore leaves a second route to investigate and contain. The identity owner inventories sessions, keys, applications, and delegated grants, then records invalidation results and any access that remains usable until expiry. Permissions and automation configurations show who could reverse those restrictions.

Investigators compare repository access, workflow changes, and publication events with approved roles and change records. These records establish actions and authorization; they do not, by themselves, establish an employee's intent. Preserve that distinction in updates and limit attribution to the people handling the investigation.

The release owner quarantines the suspect version, traces known downloads and deployments, and coordinates recipient guidance. Recovery includes reviewing the release inputs, replacing affected outputs, and restoring only the access required for the approved publication process. An independent owner verifies that the implicated identity and its delegated access cannot bypass or undo the restored controls.

The lesson applies wherever a contributor can exercise more authority than the task permits. Our research on supply chain insider threats explores how repository permissions and release controls can create that gap.

The first containment action differs across these cases, but the response record serves the same purpose: show what was stopped, what remains exposed, what the evidence supports, and who can authorize recovery. Checklist 12–16 keeps communication, trusted restoration, scoped resumption, and follow-up connected to those findings.

Test your Blast Radius prediction

Choose a starting point from your threat model and trace direct and delegated access before an incident. Include the credentials, sessions, and automation available from a developer endpoint, as well as CI and publishing identities. Use simulation to identify where removing a permission or long-lived credential changes what an attacker could reach. Keep the map's assumptions visible and revisit it when access changes.

That predicted Blast Radius guides containment and investigation. During an incident, audit evidence establishes which paths were actually used. Reducing unnecessary access beforehand also reduces the number of paths responders must investigate.

Test your ability to investigate

Identify the records required for each path, their owners, retention, and collection health. Protect the archive from the identities it records, then verify that responders can retrieve and query it. An archive that takes hours to access delays every decision depending on it. Preserve queries, event identifiers, timelines, and coverage gaps so another responder can assess the conclusions.

During the exercise, identify who reviews dependency advisories, workflow activity, and publication records, and how a concern reaches someone authorized to act. Verify external updates through trusted sources; our LiteLLM investigation documented a compromised account closing a public disclosure. Record detection and effective-containment times separately, preserving unknowns when calculating mean time to detect (MTTD).

Test containment and recovery decisions

Confirm who can act, including backups, and what evidence would justify resuming each system. Assign follow-up actions and verify procedures through safe technical tests. Exercise the ability to revoke access and restore the delivery process without relying on the implicated identity.

Use the findings to improve the starting conditions: enforce reviewed dependency selections, separate untrusted execution from privileged operations, constrain release authority, and minimize standing access. GitHub Actions workflow lockfiles became generally available on October 28, 2026. Boost Security contributed to their design and testing. Review what you lock and account separately for runtime downloads; locking a dependency does not establish its safety.

An upcoming Boost Security Labs article will examine how GitHub Actions hardening controls work together and how to verify their boundaries.

Use P1–P3 in the checklist to build exercises around your own environment. Keep the completed decisions and follow-up work with your runbooks, and keep the printable checklist accessible to the people who will respond when the next warning arrives.