Respond

StepSecurity's Respond capabilities help your organization investigate, contain, and remediate NPM supply chain attacks quickly and confidently. In fast-moving incidents, detection alone is not enough — teams need actionable intelligence, real-time alerts, and forensic-level visibility to understand what happened and how to fix it.

This page describes real incident scenarios and the StepSecurity components that power rapid response.

Scenario 1: A supply chain attack is unfolding right now and your security team needs actionable intelligence within minutes

The window between compromise and exploitation keeps shrinking. During incidents like tj-actions, nx, and multiple NPM malware campaigns, StepSecurity customers needed one thing immediately:

“Tell me exactly what this attack is, what it does, which versions are affected, and what to do next.”

Traditional vulnerability feeds lag behind by days or weeks — far too slow for active supply chain attacks.

How StepSecurity responds

Powered by: Threat Intelligence + Threat Center

• Real-time alerts about compromised packages, hijacked maintainers, and emerging attack campaigns

• Delivered directly into your existing SIEM and SOC workflows through S3 and webhooks

• No new integration needed — uses your current StepSecurity setup

• Alerts include:

  • Attack summary

  • Technical analysis

  • Indicators of compromise (IoCs)

  • Affected versions

  • Recommended remediation steps specific to your environment

• Threat Center provides a dashboard view with historical incidents, analysis, and guidance

Why this matters

• Reduces Mean Time To Detect (MTTD) from days to minutes

• Puts all teams (security, engineering, platform) on the same page

• Ensures your SOC is triggered immediately with correct, contextual intelligence

• Uses the same detection systems that discovered tj-actions, nx, and large NPM malware bursts

Scenario 2: A malicious NPM package is confirmed and you need to know exactly which PRs, repos, and teams were impacted

Once you learn a package is compromised, the next question is:

“Where did this package enter our organization?”

Speed matters and you cannot afford manual codebase review or repo-by-repo searches.

After the disclosure of the 20 Popular NPM Packages Compromised incident, organizations needed to quickly identify which PRs had introduced malicious versions of packages like chalk and debug. In many cases, exposure occurred through routine dependency upgrades that had already been merged across multiple repositories.

How StepSecurity responds

Powered by: NPM Package Search

• Instantly identifies every PR that introduced or updated the malicious package

• Shows which repositories and services are impacted

• Enables tenant-wide searches for organizations operating multiple GitHub orgs

• Allows filtering by repo, time range, or package version

• Provides a precise blast-radius view for prioritizing remediation

Why this matters

• Eliminates the “unknown exposure gap” during incidents

• Allows surgical remediation instead of broad panic

• Helps teams roll back, patch, or hotfix only the affected areas

• Speeds up coordinated response across engineering groups

Scenario 3: You must determine whether a malicious package executed malicious behavior inside CI/CD especially network exfiltration attempts

Many NPM attacks use postinstall scripts to steal secrets, tokens, or environment variables using outbound network calls.

Security teams often ask:

“Did any CI/CD workflow contact a malicious domain?”

During the Nx build system compromise and the GhostAction campaign, attackers attempted to exfiltrate secrets by making outbound network calls from CI/CD environments. Determining whether those calls actually occurred was critical for deciding whether secret rotation was required.

How StepSecurity responds

Powered by: Harden-Runner Network Baselines

• Automatically logs all outbound network destinations per job, repo, runner, and organization

• Establishes expected “normal” traffic patterns

• Highlights deviations from baseline behavior (e.g., sudden calls to unknown domains)

• Identifies DNS exfiltration attempts where attackers encode data inside DNS lookups

• Lets you query for suspicious domains or IoCs from Threat Intelligence

• Supports investigation down to the workflow-run level

Why this matters

• Provides forensic proof of whether a malicious script executed

• Helps confirm whether secrets may have been exfiltrated

• Enables targeted secret rotation

• Surfaces anomalous destinations at job, repo, cluster, or org level

Scenario 4: Your organization needs to coordinate remediation across many repositories and teams

During incidents like tj-actions and nx, companies often needed to:

• Revert affected PRs

• Remove malicious dependencies

• Rotate secrets

• Patch workflows

• Harden network policies

Doing this repo-by-repo is slow and inconsistent.

In both the tj-actions breach and Nx compromise, organizations struggled to coordinate remediation across dozens or hundreds of repositories. Teams needed a shared, authoritative view of which repos were affected, what actions were required, and whether malicious behavior had actually occurred.

How StepSecurity responds

Powered by:

• Threat Intelligence (what happened + remediation steps)

• NPM Package Search (which repos require fixes)

• Network Baselines (whether malicious code executed)

Together, StepSecurity enables:

• A prioritized list of affected repositories

• Consistent remediation guidance for all teams

• Automated alerts pushed into existing SOC tooling

• Confidence in which repos require secret rotation or dependency removal

Why this matters

• Reduces remediation time dramatically

• Ensures no affected repo falls through the cracks

• Aligns engineering and security teams around a shared source of truth

Scenario 5: After the incident, you need to verify that remediation was successful and no hidden risk remains

After fixes are applied, teams must verify:

• No repo still uses the compromised package

• No CI job is contacting malicious domains

• No dependency reintroduced risk in later PRs

• All IoCs are clear across logs and workflows

Following cleanup efforts after the Shai-Hulud and popular NPM package compromise incidents, teams needed to validate that malicious dependencies were fully removed, no outbound exfiltration persisted, and no later PRs accidentally reintroduced the compromised versions.

How StepSecurity responds

Powered by:

• NPM Package Search

• Network Baselines

• Threat Center

Why this matters

• Ensures complete closure of the incident

• Supports audit logs, compliance, and postmortems

• Provides confidence that issues won’t resurface

• Validates that remediation steps were applied consistently