What breaks when organisations rely only on pull request checks for dependency security?

PR checks only see changes that pass through review, so they miss local installs, clean CI checkouts, global tool installs, and bootstrap workflows that resolve dependencies at install time. They also depend on threat intelligence already being available. That leaves a gap where a malicious package can be installed before scanners or reviewers know it is dangerous.

Why This Matters for Security Teams

pull request checks are useful, but they are not a complete dependency-security control. They only inspect code paths that are visible at review time, while dependency resolution often happens later during local installs, clean CI checkouts, bootstrap scripts, or global tool execution. That means a package can be fetched, executed, or pinned after the review gate has already passed. NHI Mgmt Group’s research on the LiteLLM PyPI package breach shows how quickly dependency abuse can turn into credential theft when trust is placed too early in the workflow.

This matters because dependency risk is not just about known vulnerabilities. It also includes malicious typosquats, dependency confusion, compromised maintainer accounts, and install-time scripts that behave differently outside the PR diff. The NIST Cybersecurity Framework 2.0 reinforces that continuous monitoring and secure software supply chain practices must extend beyond a single review event. In practice, many security teams discover dependency abuse only after a build agent, developer laptop, or release pipeline has already executed the package.

How It Works in Practice

A PR check sees the proposed change set, but dependency security has to cover the full acquisition path: how packages are resolved, where they are cached, and what runs during installation. Current guidance suggests treating the package manager, CI runner, and developer workstation as security-relevant execution environments, not just delivery mechanisms. That means validating lockfiles, enforcing source allowlists, and checking for install scripts, transitive updates, and version drift outside the PR.

In operational terms, teams usually need four layers:

• Pre-merge checks for dependency manifest changes and lockfile diffs.
• Install-time controls that inspect fetched artifacts, signatures, hashes, and provenance.
• Runtime or pipeline policy that blocks untrusted registries, post-install hooks, and unsigned packages.
• Threat-intelligence updates that feed scanners before the next build starts, not after the fact.

This is where the gap becomes visible: a PR may approve a harmless manifest change, while a clean CI checkout still resolves a newer malicious transitive dependency, or a local developer install executes a bootstrap script that never appears in review. The best practice is evolving toward layered controls aligned with software supply chain security, not PR-only gatekeeping. NHI Mgmt Group’s guidance on the Ultimate Guide to NHIs is relevant here because package managers, CI services, and automation tokens are all non-human identities that can be over-privileged and difficult to monitor. These controls tend to break down when organisations rely on ephemeral build agents with unrestricted internet egress because the package source, execution context, and identity are all changing at runtime.

Common Variations and Edge Cases

Tighter dependency controls often increase build friction, requiring organisations to balance developer velocity against supply chain assurance. That tradeoff is real, especially when teams manage polyglot repositories, monorepos, or rapid-release pipelines where lockfile churn is frequent.

There is no universal standard for this yet, but current guidance suggests treating different workflows differently. A trusted internal package mirror may be appropriate for production builds, while developer sandboxes may allow broader access with stronger detection. Clean CI checkouts are a common blind spot because they do not inherit a developer’s local cache, so they can resolve a different dependency graph than the one reviewed in the PR. Global tool installs are another edge case: they often bypass repository-level controls entirely and can execute code during setup.

For teams using automated dependency update bots, the risk is not the PR itself but false confidence in the PR as the only enforcement point. Review still matters, but it should complement provenance checks, signed artifacts, and policy enforcement at install time. When organisations have weak inventory of package sources or no visibility into hidden bootstrap scripts, PR checks alone will miss the most dangerous path: the one that runs before human review ever sees the change.

Related resources from NHI Mgmt Group

• What breaks when organisations rely only on posture checks for NHI security?
• What breaks when security teams rely only on pull request scanning for AI-generated code?
• What breaks when security teams rely on package version checks alone for dependency risk decisions?
• What breaks when organisations rely on package version checks without verifying what code actually runs during dependency installation?