They often focus on known-bad signatures and miss behaviour that looks legitimate until the package runs. A dependency can be harmless in static review but malicious at runtime, especially when it reads credential files, spawns subprocesses, or calls unexpected external endpoints. Behavioural telemetry is the control that closes that gap.
Why This Matters for Security Teams
Package abuse is rarely obvious at publish time. Security teams often inspect metadata, signatures, or dependency names and assume that a clean static review means a safe package. That misses the real risk: a malicious package can behave benignly until install or runtime, then read environment files, enumerate secrets, spawn child processes, or exfiltrate tokens to a command-and-control endpoint. NHI Mgmt Group’s research on the LiteLLM PyPI package breach shows how quickly credential exposure follows once malicious code reaches execution, and the same pattern appears across supply chain incidents. The control problem is therefore not just package trust, but runtime behaviour and identity access around the package.Static allowlists and reputation feeds still matter, but they do not answer the question defenders actually need: what did the package try to access when it ran? That is why modern detection has to combine software supply chain signals with identity and telemetry controls aligned to the NIST Cybersecurity Framework 2.0. In practice, many security teams discover malicious package behaviour only after credentials have already been harvested from build agents or developer workstations, rather than through intentional runtime inspection.
How It Works in Practice
Effective detection starts with treating package execution as an identity and telemetry event, not just a code review event. A package may look harmless in source form, but once imported it can inherit the privileges of the process that loads it. That makes behavioural monitoring essential, especially in CI/CD runners, developer laptops, and ephemeral containers where secrets leakage and over-privileged non-human identities create immediate blast radius.Practitioners usually combine three layers:
- Runtime telemetry that records file reads, subprocess creation, DNS lookups, outbound connections, and access to credential stores.
- Package provenance checks that validate source, maintainer history, and publishing path before execution, not just before installation.
- Identity-aware containment that limits what the build job, agent, or container can reach even if the package becomes malicious.
For teams that manage agentic or automated pipelines, the package often runs inside a workload identity, so least privilege has to apply to the workload itself as well as the package. The broader lesson from incidents such as the Shai Hulud npm malware campaign is that exfiltration usually happens through normal-looking tooling, not exotic payloads. Behavioural detection should therefore alert on suspicious intent, such as credential file access followed by outbound transport, even when the package name is trusted. Teams that rely only on pre-install scanning tend to fail when the package is unpacked in a privileged build runner because the malicious action is triggered after the static gate has already passed.
Common Variations and Edge Cases
Tighter behavioural monitoring often increases alert volume and can slow build or release pipelines, so organisations have to balance coverage against developer friction. Current guidance suggests prioritising the environments where package execution can reach secrets, signing keys, or deployment credentials first.Edge cases matter. Some legitimate packages perform network calls for update checks, analytics, or plugin discovery, so a simple “any outbound traffic is suspicious” rule creates noise. Best practice is evolving toward context-aware baselines: which endpoints are expected, which files should be readable, and which child processes are normal for that package family. In contrast, a package that only appears risky because of obfuscation may still be benign; the inverse is also true, where clear code can still be malicious once executed.
Security teams also get tripped up in environments that auto-install dependencies during image builds or test setup. In those pipelines, the package inherits the identity of the automation system, so a single compromise can pivot into signing keys, artifact repositories, or cloud credentials. The Top 10 NHI Issues research is a useful reminder that excessive privilege and weak monitoring remain common failure points. Detection breaks down most often in fast-moving CI/CD environments where packages execute before telemetry is fully attached and the security team has no baseline for normal library behaviour.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Runtime package abuse often succeeds through stale or overlong credentials. |
| OWASP Agentic AI Top 10 | A03 | Autonomous package execution maps to agentic tool-use and runtime abuse. |
| NIST CSF 2.0 | DE.CM-8 | Behavioural telemetry is a continuous monitoring control for malicious package execution. |
Inspect tool-using workloads at runtime and block unexpected file, process, and network actions.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
