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.

Step 2: Assess the Blast Radius

Use NPM Package Search to find every instance of the compromised package across your organization:

1. Navigate to Artifact Security → NPM 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

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 → NPM 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.