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 Pull Request Checks Leave Dependency Security Gaps
pull request checks are useful, but they only inspect the code path that is reviewed and merged. Dependency risk is broader than that path because many packages are resolved outside the pull request itself, including local development installs, clean CI checkout steps, bootstrap scripts, and global tooling. That means the control can look strong while the real acquisition path stays partly invisible. For dependency security, visibility and timing matter as much as review discipline. In practice, teams often discover this gap only after a package has already been installed through a route the pull request never touched.
When dependency checks are treated as the main control, organisations can overestimate how early they are seeing malicious or compromised packages. The problem is not just that a scanner may miss something; it is that the scanner may be watching the wrong moment in the lifecycle. If the dependency is fetched before threat intelligence or detection rules are updated, the review gate can still pass even though the package is already present. That is why dependency security needs to cover acquisition, installation, and post-install verification, not just review-time analysis. For teams mapping identity-bound software supply paths, OWASP Non-Human Identity Top 10 is relevant because package managers, build agents, and automation often act with machine-level trust and credentials.
Teams also miss that pull request checks are only as current as the signals they consume. A package that looks benign at review time can become suspicious later, or a harmful package may have no known reputation yet. The control therefore helps with known-bad detection, but it does not fully manage unknown or fast-moving dependency abuse. Dependency security that stops at the pull request boundary is incomplete because it assumes review is the same thing as control, when it is really only one checkpoint in a longer supply path.
How Dependency Risk Actually Surfaces During Build and Install Paths
Dependency security breaks when the place you inspect is not the place where the dependency is resolved. In modern software delivery, packages may be pulled from registries during local development, CI jobs, container builds, package manager bootstrap routines, or post-clone install hooks. A pull request may record the intended version, but the actual installed artifact can still differ because of lockfile drift, transient registry changes, script execution, or indirect transitive resolution. The review gate can verify what was requested, while the runtime or build system consumes what was available at install time.
That distinction matters because malicious or compromised packages often exploit trust in the installation process rather than the review process. A dependency may be introduced through a legitimate update, a transitive chain, a scoped namespace collision, or a dependency that becomes risky only after publication. Pull request checks are strongest when the problem is already known and the package metadata is present in intelligence feeds. They are weaker when the package is novel, recently changed, or pulled in by automation that never creates a clear review artifact.
- Local installs can bypass central review if developers are allowed to resolve packages directly.
- Clean CI checkouts can fetch dependencies in a fresh environment that does not mirror what reviewers saw.
- Bootstrap and install scripts can introduce behaviour after the pull request has been approved.
- Global tool installs can create unmanaged software paths outside the application dependency manifest.
That is why dependency security needs controls at both review time and acquisition time. Review still matters, but it should be paired with package provenance checks, deterministic installs, inventory of build-time trust paths, and detection that can evaluate what was actually fetched. Without those layers, the organisation may trust the approval record more than the resolved artifact. This guidance breaks down when software is built in highly dynamic pipelines where the installed dependency set changes faster than policy and tooling can record it.
Where Pull Request-Only Thinking Fails in Real Projects
Tighter dependency review often increases friction, so organisations must balance developer speed against assurance that the reviewed artifact is the one actually installed. The tradeoff becomes sharper in polyglot repositories, ephemeral build systems, and environments where teams use multiple package managers, because each path can resolve dependencies differently. If the same project uses application manifests, build scripts, container layers, and global tooling, a pull request gate sees only part of the picture.
One common edge case is transitive dependency risk. The direct package in the pull request may be well understood, but its nested dependencies can change independently or be pulled from sources that the reviewer never inspected. Another is private or internal package mirrors, where trust in the mirror becomes part of the security model. If the mirror is stale, unsynchronised, or insufficiently monitored, the pull request approval does not prevent the wrong artifact from entering the build. There is also a governance gap when teams assume “approved in review” means “safe to execute,” even though installation scripts, lifecycle hooks, and automation credentials can still make the runtime behaviour unsafe.
Guidance is not fully consistent across industries on exactly where to place the strongest dependency gate, but there is broad agreement that review alone is not a complete supply-chain control. The practical answer is to treat pull request checks as one checkpoint, then add installation-time validation and continuous dependency visibility. Organisations that rely only on review often learn too late that the real control boundary is the resolver, not the pull request.
Risk and Threat Considerations
Relying only on pull request checks creates a dependency exposure problem rather than a simple tooling gap. The risk is that malicious, compromised, or newly published packages can be installed through routes that never appear in review, leaving the organisation with a false sense of coverage. This is especially important where build agents, developer laptops, and bootstrap scripts hold trust to fetch and execute dependencies automatically.
Failure mechanism: The weakness materialises when dependency resolution happens outside the reviewed change set, or when detection depends on intelligence that is not yet available at install time. Attackers and abusive publishers exploit the gap by placing harmful code in packages that are fetched before scanners, policy engines, or reviewers can classify them.
Impact: The result can be unreviewed code execution, contaminated builds, compromised build credentials, polluted artifacts, and downstream trust in software that was never actually protected by the pull request gate.
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 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 15 — Service Provider Management | Dependency trust extends into third-party packages and supply paths. |
| 16 — Application Software Security | PR-only checks leave application dependency verification incomplete. | |
| Recommendation — Track third-party dependency sources and require approval for trusted acquisition paths. Add software composition and dependency controls beyond pull request review. | ||
| NIST CSF 2.0 | ID.SC-4 — Suppliers and Third Parties Are Identified, Prioritized, and Assessed Using a Cyber Supply Chain Risk Management Process | Dependency security depends on supplier and package-source risk assessment. |
| PR.DS-6 — Integrity Verification | Installed artifacts must be verified, not just reviewed in pull requests. | |
| Recommendation — Assess dependency suppliers and registry sources as part of cyber supply chain risk management. Verify dependency integrity at install and build time, not only during code review. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Automation and build systems often fetch dependencies using machine credentials. |
| Recommendation — Inventory and restrict machine credentials that can install or publish dependencies. | ||
Practitioner Guidance
What to prioritise: Treat dependency acquisition paths as first-class control surfaces, not as implementation details. The first question is whether developers, CI jobs, or bootstrap workflows can install packages without passing through the same visibility and policy checks as the pull request.
What to verify: Confirm that the package resolved during install is the package the organisation expected to approve. That means checking the resolver, the lockfile behaviour, the registry source, and whether scripts or global tools can alter what executes after review.
Decision rule: If a dependency can be introduced, updated, or executed outside the reviewed change path, pull request checks should be treated as partial assurance only. Escalate to stronger provenance, inventory, and installation controls rather than assuming the review gate is sufficient.
Practitioner takeaway: The control failure is not that review is useless, but that it is too narrow to govern every place dependency trust is established.
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?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
