They often assume a clean manifest means a clean environment. In reality, package managers can resolve transitive code dynamically and execute scripts during installation. A scan can confirm what should have been installed, but it cannot prove what actually ran or what secrets the code reached.
Why This Matters for Security Teams
Dependency scanning is often treated as proof that software supply chain risk is under control, but that assumption is too narrow. A manifest only describes intended dependencies at one point in time. It does not show whether install-time scripts executed, whether a registry served a different artifact, or whether a package reached out to services it should never have touched. That gap matters because dependency compromise often becomes an identity and secret exposure problem, not just a code quality issue.
NHIMG research shows that 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage, which is why dependency hygiene has to be treated as an access problem as much as a code problem. The NIST Cybersecurity Framework 2.0 reinforces this broader view by tying software risk to asset visibility, governance, and continuous monitoring rather than point-in-time checks alone. A package that looks clean on paper can still behave like an untrusted workload after installation.
In practice, many security teams discover dependency abuse only after a package has already executed, exfiltrated tokens, or altered build output, rather than through intentional pre-release review.
How It Works in Practice
Effective dependency scanning starts with recognising what the scanner can and cannot prove. It can inventory declared dependencies, flag known vulnerable versions, and sometimes identify malicious package names. It cannot reliably attest to runtime behaviour, transitive resolution changes, or install scripts that execute with build-agent privileges. That is why current guidance suggests pairing scanning with provenance checks, build isolation, and secret containment.
For software teams, the practical control set usually includes:
- Lockfiles and deterministic builds so dependency resolution is reproducible.
- Policy checks that block unexpected major version shifts, new registries, or unapproved sources.
- Build-time isolation so install scripts cannot reach long-lived secrets or internal services.
- Package provenance and signing verification where supported, to confirm origin as well as version.
- Secret scanning across source, build logs, and artifacts, because compromise often lands on credentials first.
That is the point where NHI governance becomes relevant. The Ultimate Guide to NHIs shows how broadly credentials are exposed across code and CI/CD, and the LiteLLM PyPI package breach is a useful reminder that package compromise can quickly turn into credential theft. Standards bodies take a similar view: the NIST Cybersecurity Framework 2.0 pushes teams toward continuous governance and detection, not static verification alone.
These controls tend to break down in polyglot build pipelines with many indirect dependencies because transitive resolution, native extensions, and post-install hooks are difficult to inspect consistently.
Common Variations and Edge Cases
Tighter dependency controls often increase build friction, requiring organisations to balance delivery speed against stronger provenance and runtime isolation. That tradeoff is especially visible in environments that pull from multiple package ecosystems, generate dependencies dynamically, or allow developer-controlled scripts during installation.
There is no universal standard for this yet, but best practice is evolving toward layered assurance rather than relying on a single scanner. Signed packages help with authenticity, but they do not stop a trusted package from abusing install-time access. SBOMs improve visibility, but they are snapshots, not behavioural evidence. Sandboxing reduces blast radius, but it may not be practical for every legacy build or performance-sensitive pipeline.
Security teams should be especially careful in CI/CD systems where build agents already hold cloud tokens, artifact signing keys, or deployment credentials. A dependency scan may report no known CVEs, while the real risk is that the package executed code that touched secrets before the scan even finished. In those cases, the right question is not only “Is this dependency vulnerable?” but “What could this dependency reach if it behaves unexpectedly?”
That distinction matters most when package installs are allowed network access, when repos are mirrored without integrity validation, or when organisations equate clean metadata with safe execution.
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 CSA MAESTRO 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-01 | Dependency scans miss secret exposure, a core non-human identity risk. |
| NIST CSF 2.0 | DE.CM-8 | Continuous monitoring is needed because dependency risk is behavioural, not static. |
| CSA MAESTRO | M2 | Build pipelines are autonomous workloads that need runtime guardrails beyond scanning. |
Inventory package-facing secrets and block long-lived credentials from build and install paths.
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
