What do security teams get wrong about package integrity checks?

Why Security Teams Misread Package Integrity as a Complete Control

Package signing, hash verification, and version pinning are useful supply chain checks, but they only prove that a package is the one that was published. They do not prove that the package is safe to execute in a real environment, where it may call out to remote services, read workflow secrets, or chain into other tools. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls treats integrity as one control family, not the whole security model.

The common mistake is assuming that trusted provenance equals trusted behaviour. That is especially dangerous in CI/CD, build agents, and dependency-rich applications, where a legitimate package can still become an execution path into secrets, tokens, or internal services. NHIMG’s Ultimate Guide to NHIs notes that 96% of organisations store secrets outside secrets managers in vulnerable locations, which means a seemingly harmless dependency can reach far more than its intended scope.

In practice, many security teams discover package abuse only after a trusted update has already touched credentials or moved laterally through the build environment.

How Package Integrity Checks Should Work in Practice

Integrity controls should be treated as a gate, not as runtime protection. A verified package should still execute inside a constrained environment with least-privilege permissions, short-lived secrets, and telemetry that can detect abnormal network, file, or process activity. This is where supply chain assurance connects to NHI governance, because the real exposure often comes from workflow credentials, service accounts, and API keys available at execution time.

A practical model combines three layers. First, verify provenance and integrity before installation using signing and hash checks. Second, restrict the execution context so the package cannot freely access outbound networks, cloud metadata, or high-value secrets. Third, monitor behaviour after execution begins, because a package may remain authentic while still being malicious, overreaching, or compromised post-release.

• Use dependency pinning and signature validation to reduce substitution risk.
• Run builds and installs with minimal privileges and scoped egress.
• Issue secrets just in time and revoke them when the task ends.
• Log network destinations, process spawning, and secret access attempts.
• Review the trust boundary for package managers, CI runners, and plugin ecosystems separately.

For NHI-specific threat context, the LiteLLM PyPI package breach shows why supply chain trust cannot be the final control. The broader lesson also aligns with CISA’s Secure Software Development Framework, which emphasizes secure build and deployment practices across the lifecycle.

These controls tend to break down when packages run inside highly permissive CI/CD runners with long-lived cloud credentials, because execution-time access becomes more valuable than the integrity check itself.

Where Integrity Checks Break Down and What Teams Overlook

Tighter package control often increases operational overhead, requiring organisations to balance developer velocity against runtime containment. Best practice is evolving, but there is no universal standard that says a signed package is automatically safe in every environment. The main gap is that many teams stop at provenance and never test how the package behaves once it is trusted by the runtime.

That gap is widest in build systems, internal registries, plugin frameworks, and AI-enabled developer tooling, where packages may inherit secrets from orchestrators or workflow engines. In those environments, a legitimate dependency can still exfiltrate tokens, query internal APIs, or abuse callback channels even if every checksum matches. Current guidance suggests treating package integrity as one signal in a broader risk decision, not the decision itself.

Security teams also miss the operational difference between a one-time install and an always-on execution surface. A package that is harmless during verification can become risky after an update, during plugin initialization, or when environmental secrets change. This is why behavioural monitoring, egress control, and rapid revocation matter as much as signature validation.

NHIMG’s research shows why this matters in real deployments: 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which means package abuse often becomes an identity problem after the initial compromise.

Related resources from NHI Mgmt Group

• What do security teams get wrong about AI-assisted webpage safety checks?
• What do security teams get wrong about human-in-the-loop identity checks?
• What do security teams get wrong about AI integrity and provenance?
• What do teams get wrong about PowerShell-based malware campaigns?