Repository-level inventory tells you where a package exists now, but not how it got there or whether it was later removed. PR-level visibility shows introduction history, ownership, and persistence, which are the details needed to judge exposure, prioritize response, and explain why a risky dependency was accepted in the first place.
Why PR-Level Visibility Changes the Security Question
Repository inventories answer the narrow question of current usage, but security teams usually need to know when a dependency first appeared, who introduced it, and whether it persisted through review. That context changes how you assess exposure, because a package that appears in a repository today may have been accepted through a specific pull request, inherited through reuse, or later removed and reintroduced. PR-level visibility also improves accountability when a dependency becomes controversial or is linked to a vulnerability, because ownership and intent are easier to establish.
For teams managing supply-chain risk, this distinction matters because the control problem is not just presence, but provenance. A repo-level snapshot can support reporting, yet it often fails to explain acceptance decisions or reveal the change path that created the dependency relationship. NIST’s control families on software inventory, change management, and configuration awareness are most useful when they can be tied to the actual change event, not only the end state. In practice, many security teams discover the real source of dependency exposure only after they have already reviewed the repository and still cannot explain how the package arrived there.
How PR-Level Package Visibility Works in Practice
PR-level visibility maps dependency introductions to the change record that added them. That usually means linking package metadata to the pull request, commit, reviewer, and merge history so teams can answer practical questions: was the dependency added once, copied across multiple repositories, upgraded later, or removed and reintroduced under a different change? This is materially different from counting current repository usage, because current usage hides the sequence of decisions that shaped the dependency graph.
That sequence matters for several reasons. First, it helps security teams separate inherited exposure from locally introduced exposure. Second, it lets reviewers see whether a dependency was added with obvious justification, hidden inside a broad refactor, or accepted before policy checks were mature. Third, it supports faster triage when a package becomes high risk, because the team can identify the exact changes and owners associated with the introduction rather than starting from a static repo list.
PR-level data also improves governance. If an organisation requires approval for new external dependencies, the pull request is the place where control evidence should exist. If the package later disappears from the repository, the PR history still provides the audit trail. If the package persists across branches or duplicated repositories, PR-level links can show whether that persistence reflects deliberate reuse or uncontrolled copy-paste. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it treats inventory, change control, and accountability as connected control outcomes rather than isolated checks.
Where this guidance breaks down is in environments that do not preserve reliable pull request history, where dependencies are injected outside normal development workflows, or where generated code and build automation introduce packages without a clear human approval trail.
When Repository Counts Are Enough, and When They Are Not
Tighter visibility usually increases operational overhead, so teams need to balance completeness against the cost of collecting and maintaining provenance data.
Repository-level visibility can be sufficient for simple questions such as “where is this package still present right now?” or for broad exposure estimation when the team already has strong approval controls and low repository churn. It is also useful for reporting the current attack surface across many codebases. The limitation is that it does not distinguish between an actively chosen dependency and one that survived from an older change, which makes it weak evidence for accountability or remediation planning.
The edge cases matter. Monorepos can make a dependency look centralized even when ownership is split across teams. Forks and vendored code can obscure whether the package was introduced through a normal PR or copied in by another route. Automated dependency update tools can create many small changes that are easy to count but hard to interpret unless PR metadata is preserved. Consensus is still emerging on how much historical detail is necessary for every program, but there is broad agreement that provenance becomes essential once dependency risk must be explained, defended, or audited rather than merely enumerated.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-2 — Software and Hardware Inventory | PR-level visibility strengthens inventory provenance for dependencies. |
| PR.IP-12 — Change Management | Pull requests are the change record for dependency acceptance and review. | |
| ID.GV-1 — Organizational Context | Ownership and acceptance history support governance accountability for dependencies. | |
| Recommendation — Link dependency records to change events so inventory reflects introduction history, not just current presence. Tie package approval to PR review evidence so dependency changes remain traceable and controlled. Assign clear ownership for dependency approval and retain the evidence needed to justify acceptance decisions. | ||
| CIS Controls v8 | 16 — Application Software Security | Dependency provenance is part of secure software change control and review. |
| 1 — Inventory and Control of Enterprise Assets | Current repository inventory alone is incomplete without introduction context. | |
| 8 — Audit Log Management | PR history provides the audit trail needed to explain dependency acceptance. | |
| Recommendation — Require PR-level review evidence for new dependencies before merge and track exceptions explicitly. Maintain dependency inventory with source-of-introduction details so current presence is tied to provenance. Preserve pull request and merge records so dependency decisions can be audited after the fact. | ||
Practitioner Guidance
What to prioritise: Treat dependency provenance as a control requirement, not a reporting enhancement, when your teams approve third-party code or investigate risky packages. If you cannot link a package to the change that introduced it, you have inventory, but not decision evidence.
What to verify: Check whether the PR record preserves the dependency name, version, review context, approver, and merge date. A useful record lets an analyst reconstruct why the package entered the codebase and whether later cleanup changed the risk picture.
Decision rule: Use repository-level counts for surface area reporting, but use PR-level visibility for acceptance decisions, exception handling, and incident response. If the question is “is it present?”, repo data may be enough; if the question is “who accepted it and why?”, it is not.
Practitioner takeaway: The most valuable dependency evidence is the change history that explains intent, because security decisions are made at introduction time even though exposure is often discovered much later.
Related resources from NHI Mgmt Group
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
