M ManySignal

Use Case: Supply Chain

Software supply chain compromise

A popular npm package was backdoored 6 hours ago. 4 of your services depend on it. ManySignal identified the affected services, blocked the package, and opened PRs before your engineers saw the CVE.

Attack scenario

The trusted dependency that became the breach vector

The SolarWinds Orion compromise (2020), the XZ Utils backdoor (2024), and the event-stream npm incident (2018) represent different variations of the same attack: a trusted software component is modified to include malicious code, which then executes in the environments of all its users. The attack is particularly devastating because it exploits the trust organizations place in their software supply chain.

The attacker's advantage is that security teams rarely monitor what trusted software components actually do at runtime. A package that suddenly makes outbound connections to an unfamiliar IP, or a build artifact whose hash doesn't match the expected value, generates no alert in a traditional security stack. ManySignal monitors both the inventory (SBOM) and the runtime behavior of dependencies.

Detection logic
rule: supply_chain_compromise
type: intel_match + behavioral
sources:
  - github_actions_logs
  - sbom_scanner (syft, trivy, grype)
  - pypi_npm_registry_events
  - edr_process_network_events
trigger:
  - OR:
    - condition: package_version IN malicious_package_feed
    - condition: package_hash != registry_expected_hash
    - condition: |
        runtime_process(package_module) AND
        outbound_connection NOT IN expected_endpoints
        AND postinstall_script_executed == true
enrichments:
  - sbom_impact: all_services_using_package
  - registry_diff: malicious_vs_clean_version
  - exploit_status: cisa_kev, recorded_future
  - pr_generation: github_api (remediation_branch)
mitre: T1195.001 (Supply Chain Compromise: Compromise Software Dependencies)
Triage agent questions
1

Which version of the affected package is deployed in production, and when was it installed?

SBOM / package inventory
2

Has the package made any unexpected network connections since installation?

EDR / NetFlow
3

Does the package's dependency tree include any recently added or modified upstream packages?

Dependency analysis
4

Are other internal teams or projects using the same affected package?

Code search
5

Is there a patched version available, and what's the diff between the malicious and clean versions?

Package registry
6

Did the malicious package execute code at install time (postinstall scripts, setup.py)?

CI/CD build logs
Response playbook
1

Block the affected package version in the internal package mirror

Autonomous
2

Notify all teams with the package in their dependency trees via automated PR or Slack

Autonomous
3

Isolate any systems where the package executed a postinstall script

Approve-gated
4

Submit package hash to MalwareBazaar and share IOCs with vendor

Autonomous
5

Initiate SBOM-based impact assessment across all production services

Recommend

MITRE ATT&CK mapping

T1195.001 — Compromise Software DependenciesT1195.002 — Compromise Software Supply ChainT1554 — Compromise Client Software Binary

Supply chain compromise FAQ

How does ManySignal detect supply chain compromises in real time vs. after the fact?

ManySignal maintains a continuous package intelligence feed that ingests malicious package reports from OSS-Fuzz, Checkmarx, and the PyPI/npm security advisories. When a known-malicious package version appears in a build log or SBOM scan, the alert fires within minutes. Runtime behavioral signals (unexpected network connections from the package process) provide a second detection layer.

Does ManySignal integrate with GitHub Dependabot and Snyk?

Yes. ManySignal ingests Dependabot alerts, Snyk findings, and OWASP Dependency-Check results via webhook. These vulnerability findings are enriched with exploitation data from CISA KEV and Recorded Future to prioritize which vulnerable dependencies have active exploits.

Can ManySignal help with the SolarWinds / XZ Utils scenario?

SolarWinds-style supply chain attacks (trusted vendor update containing backdoor) are addressed via two signals: behavioral analysis of the software after update (unexpected network connections, new persistence mechanisms) and integrity verification of update packages against their expected hash. The XZ Utils backdoor would have been flagged by the behavioral model — the malicious code made SSHD connections on non-standard patterns.

What SBOM formats does ManySignal support?

CycloneDX JSON and XML, SPDX 2.3, and custom SBOM outputs from Syft, Grype, and Trivy. ManySignal also generates SBOMs from build logs when a formal SBOM is not available.

Know when a dependency turns malicious before your build does

SBOM monitoring, package intelligence, and runtime behavioral analysis — connected end to end.