# How to Respond to a Compromised npm Package in Your Organization

When a compromised npm package is discovered in your organization, speed matters. This guide provides a step-by-step incident response workflow using StepSecurity's tools across all three product areas.

### **Step 1: Confirm the Compromise**

Check the Threat Center in your StepSecurity dashboard for active advisories. The Threat Center provides real-time threat intelligence with technical analysis, indicators of compromise (IOCs), and affected package versions. If the package appears in the Threat Center, StepSecurity has already confirmed the compromise.

If you received the alert from an external source (GitHub advisory, social media, security mailing list), cross-reference it against the Threat Center. StepSecurity's automated detection systems often flag malicious packages within minutes of publication, sometimes before public advisories exist.

<figure><img src="/files/FLFzP7ZbBRPp8NTz55R2" alt=""><figcaption></figcaption></figure>

### **Step 2: Assess the Blast Radius**

Use [**OSS Package Search**](/packages/oss-package-search.md) to find every instance of the compromised package across your organization:

1. Navigate to **Artifact Security → OSS Package Search**
2. Select Compromised Packages as your Search Type
3. Review results to identify all repositories, pull requests, and (if Developer MDM is enabled) developer machines where the package is present

<figure><img src="/files/wYuTbZjPfCogJ5mqj4JE" alt=""><figcaption></figcaption></figure>

This tells you exactly how widespread the exposure is. Prioritize remediation based on which repositories handle production deployments or sensitive secrets.

### **Step 3: Block Further Introduction**

If you have **GitHub Checks** enabled with the **Compromised NPM Package** control, StepSecurity is already blocking PRs that introduce the compromised package. Verify this is active:

1. Navigate to **GitHub Checks → Configuration**
2. Confirm the Compromised NPM Package control is enabled and set to **Required**

If **NPM Package Cooldown** is enabled, PRs introducing very recently published packages are also being blocked, which provides proactive protection against zero-day npm attacks.

### **Step 4: Check Runtime Exposure**

If the compromised package was already in your workflows before detection, check Harden-Runner for signs of exploitation:

1. Navigate to **Harden-Runner → Detections**
2. Look for anomalous outbound network calls or suspicious processes from recent workflow runs in affected repositories
3. Check the **Network Events** tab on relevant workflow run Insights pages for connections to known malicious endpoints (check the Threat Center for IOC domains)

If you had `egress-policy: block` enabled, Harden-Runner may have already blocked exfiltration attempts. Review blocked call detections to confirm.

### **Step 5: Remediate**

For each affected repository identified in Step 2:

* Update the compromised package to a safe version (check the Threat Center for recommended versions)
* If no safe version exists, remove the package and find an alternative
* Rotate any secrets that were accessible during workflow runs that used the compromised package, including GITHUB\_TOKEN, cloud deployment credentials, npm publish tokens, and any other secrets in the workflow environment

### **Step 6: Check Developer Machines (if Developer MDM is enabled)**

If your organization uses Developer MDM, check whether the compromised package is installed locally on developer machines:

1. Navigate to **Developer MDM → OSS Package Search**
2. Search for the compromised package
3. If found on developer machines, initiate remote removal to contain the blast radius

### **Step 7: Post-Incident Review**

Document the timeline: when the package was compromised, when it was detected, how it entered your organization, and what the impact was. Use the **Historical Dependency Timeline** to understand your exposure window. Review whether enabling additional controls (stricter cooldown periods, block-mode egress policies) would have prevented or limited the impact.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.stepsecurity.io/start-here/guides/how-to-respond-to-a-compromised-npm-package-in-your-organization.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.