# Detect StepSecurity's Detect capabilities give your organization continuous visibility into open-source dependency usage across PRs, repositories, developer machines, and time. This section explains the real scenarios where detection matters and the StepSecurity features that power these workflows. {% hint style="info" %} For runtime detection during CI/CD execution, see [Harden-Runner](/harden-runner.md) {% endhint %} ## Scenario 1: A newly disclosed malicious package hits the ecosystem and you need to know everywhere it was used When a package is declared malicious, every security team asks the same immediate question: **"Where in our organization has this package ever been introduced?"** Manually searching through repositories, branches, and lockfiles is slow, error-prone, and often incomplete. After the disclosure of the [*Shai-Hulud: The Second Coming* campaign](https://www.stepsecurity.io/blog/sha1-hulud-the-second-coming-zapier-ens-domains-and-other-prominent-npm-packages-compromised), security teams needed to rapidly determine whether compromised packages used across Zapier, ENS Domains, and other ecosystems had ever been introduced into their repositories. In many cases, exposure was limited to specific PRs or short-lived updates that were not obvious from current dependency state alone. ### How StepSecurity detects this Powered by: [**OSS Package Search**](/oss-package-security/oss-package-search.md) * Search across all PRs in all repositories * Identify every PR where the package was introduced * Understand the blast radius instantly * Run both custom searches and compromised-package searches * Search at either the organization or tenant level ### Why this matters * Reduces incident response from hours to minutes * Ensures complete visibility across all teams and repos * Prevents missed exposures in large or distributed organizations ## Scenario 2: A developer adds or updates a dependency in a PR and you need to know whether it's malicious or high-risk Every dependency update is a potential supply chain entry point. If a package is known malicious, recently weaponized, or flagged by StepSecurity’s intelligence, you need real-time detection before the merge happens. In the [*20 Popular NPM Packages Compromised* incident](https://www.stepsecurity.io/blog/20-popular-npm-packages-compromised-chalk-debug-strip-ansi-color-convert-wrap-ansi), malicious versions of widely trusted packages like chalk and debug were introduced via normal version bumps in PRs. Without real-time detection at PR time, these changes would have merged unnoticed, even though the package names themselves were already deeply trusted across the ecosystem. ### How StepSecurity detects this Powered by: [**Package Compromised Updates**](/github-checks/configuration.md#package-compromised-updates) * Every PR modifying package manifests or lockfiles (`package.json`, `package-lock.json`, `requirements.txt`, `poetry.lock`, and similar) is evaluated * Dependency changes are compared against StepSecurity's real-time compromised package intelligence * Includes both confirmed malicious packages and packages flagged as high-risk * If a dependency is unsafe, the PR fails immediately and the developer is notified * Runs as separate **npm Package Compromised Updates** and **PyPI Package Compromised Updates** checks ### Why this matters * Prevents compromised packages from merging into main * Gives developers instant clarity while the PR is still open * Detects threats **before** CVEs or advisories are published * Helps maintain consistent dependency hygiene across teams ### Scenario 3: You need to understand whether you were exposed in the past even if the dependency has been removed A malicious package might have been introduced weeks or months ago, merged briefly, and then removed during cleanup. During an incident, you need to answer: **“Were we ever using this dependency? When was it introduced? In which PR?”** Even if the dependency is no longer in your repositories today, the historical introduction event still matters. During investigations into the [*Nx build system compromise*](https://www.stepsecurity.io/blog/supply-chain-security-alert-popular-nx-build-system-package-compromised-with-data-stealing-malware), teams discovered that the malicious package had been introduced temporarily in some repositories and later removed. Organizations still needed to determine whether CI runs occurred during that exposure window, even though the dependency no longer existed in the current codebase. ### How StepSecurity detects this Powered by: [**OSS Package Search**](/oss-package-security/oss-package-search.md) * Tracks when and where packages were added through PRs * Allows you to search historical PR introduction events * Enables reconstruction of exposure windows * Works even if the dependency no longer exists in the current codebase #### Why this matters * Essential for forensic investigations * Enables accurate determination of exposure periods * Supports compliance and post-incident reporting ### Scenario 4: A package appears suspicious before it is officially declared malicious and you want early warning signals Many supply chain attacks have early behavioral signals long before the security community identifies them: * Sudden ownership changes * Unusual publishing activity * Publisher anomalies * Strange versioning patterns * Connections to past malicious campaigns These are early “smoke signals” that often precede large-scale compromises. Prior to full disclosure of the [*Shai-Hulud*](https://www.stepsecurity.io/blog/sha1-hulud-the-second-coming-zapier-ens-domains-and-other-prominent-npm-packages-compromised) resurgence, affected packages showed abnormal publishing behavior and ties to previously compromised maintainers. These early indicators appeared before public advisories but were critical for identifying risk ahead of widespread impact. ### How StepSecurity detects this Powered by: [**OSS Security Feed**](/oss-package-security/oss-security-feed.md) * Ecosystem-wide monitoring surfaces anomalous NPM activity * Proprietary signals flag suspicious packages early * StepSecurity intelligence feeds into PR checks and search workflows * Alerts appear even before public disclosures {% hint style="info" %} The OSS Security Feed currently tracks compromised and suspicious **npm** package releases and maintainers. PyPI threat intelligence is already used by the PyPI Package Compromised Updates check at PR time {% endhint %} ### Why this matters * Allows teams to take proactive action * Helps prevent early-stage adoption of risky dependencies * Provides visibility into emerging NPM threats at their earliest stage ## Scenario 5: You need consistent visibility into dependency usage across many repositories Organizations with microservices or large engineering teams often struggle to answer: • Which repos use which dependencies?\ • Are we using the same package versions everywhere?\ • Where do we have outdated, drifted, or duplicated dependencies? During the [*GhostAction* investigation](https://www.stepsecurity.io/blog/ghostaction-campaign-over-3-000-secrets-stolen-through-malicious-github-workflows), widespread secret exfiltration across hundreds of repositories highlighted how difficult it was for organizations to quickly understand which repositories shared common tooling, workflows, and dependencies — and therefore shared exposure. ### How StepSecurity detects this Powered by:[ OSS **Package Search**](/oss-package-security/oss-package-search.md) * Aggregates dependency introduction events across all repos * Provides a unified view of package usage * Highlights inconsistencies, outdated usage, and hotspots * Makes cross-repository dependency governance feasible ### Why this matters * Reduces supply chain sprawl * Improves upgrade planning * Creates a consistent security posture across services --- # 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/oss-supply-chain-security/detect.md?ask= ``` 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.