Detecting Compromised Open Source Packages: Sentinel and GuardDuty Detections

Retrospective: this article looks back at events from March 2024, written in 2026 with the benefit of hindsight.

Compromised open-source packages are hard to detect by behavior — they're designed to look legitimate. Detection relies on inventory, threat intelligence and anomaly monitoring.

Signals worth watching

• Vulnerability scanners flagging known-compromised package versions (by CVE or advisory).
• New dependencies or maintainers appearing in critical packages your applications use.
• Packages executing unexpected install scripts that make network connections.
• Build servers making outbound connections to unusual destinations during builds.
• Unusual SSH behavior or CPU usage changes on servers after updates (as in the XZ discovery).

Where the data lives

• Defender Vulnerability Management, Amazon Inspector and container scanners.
• Software composition analysis tools (Dependabot, Snyk and others) in repositories.
• Build system logs and network logs from CI runners.
• Endpoint telemetry on build servers and production hosts.

A starting query

Find devices with a specific vulnerable software version in Defender Vulnerability Management:

DeviceTvmSoftwareVulnerabilities
| where CveId == "CVE-2024-3094"
| project DeviceName, SoftwareName, SoftwareVersion, OSPlatform

Build-time anomaly detection

Monitor outbound connections from CI/CD runners. Package installs that reach domains outside approved registries deserve review.

Response

1. Roll back affected packages.
2. Rebuild images from known-good sources.
3. Assess exposure: were affected systems internet-facing?
4. Report findings to the package ecosystem if you discover something new.