The record of how a dependency entered a codebase through one or more pull requests. It links package introduction to the repository, contributor, and review path, giving security teams a timeline for exposure analysis, ownership review, and targeted remediation after a compromise or policy violation.
Expanded Definition
Pull Request Lineage is the chain of evidence that shows how a dependency, package, or other code change entered a repository through one or more pull requests. In NHI and software supply chain security, it connects the artifact to the contributor, reviewers, approvals, merge path, and timing of introduction, which makes later exposure analysis and ownership review possible.
The concept is broader than commit history alone because a commit can hide the decision path that allowed it into production. Pull Request Lineage captures the governance layer around code intake, which is especially important when secrets, build scripts, or agent tooling are introduced indirectly. Definitions vary across vendors on whether lineage should include rebases, cherry-picks, bot-generated pull requests, or only the final merged PR, so teams should document their own scope explicitly. For a standards-oriented view of securing software supply chains, the NIST Cybersecurity Framework 2.0 supports traceability, change control, and recovery practices that align with this kind of evidence chain.
The most common misapplication is treating the merged commit hash as sufficient lineage, which occurs when teams do not retain PR-level metadata, review records, or dependency provenance.
Examples and Use Cases
Implementing Pull Request Lineage rigorously often adds process and data-retention overhead, requiring organisations to balance fast delivery against the cost of preserving complete review evidence.
- A security team traces a compromised dependency back to the exact pull request that introduced it, then inspects reviewer approvals and branch protection settings to determine whether policy was bypassed.
- A platform team reviews bot-authored dependency updates separately from human-authored changes, because automation can accelerate safe patching but also obscure accountability if lineage is incomplete.
- An incident responder correlates a newly discovered secret in code with the pull request that introduced it, then uses the review path to determine whether the secret was added intentionally or by mistake.
- A governance team uses lineage records to show where an AI agent or build assistant proposed a dependency change, which is useful when autonomous tooling has execution authority inside CI/CD.
- A supply chain analyst compares PR lineage with repository ownership to identify whether an external contributor introduced a package that should have triggered additional scrutiny.
For background on the scale of identity and secret exposure that makes this evidence trail valuable, see Ultimate Guide to NHIs. The broader change-control context also aligns with software integrity practices in NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
Pull Request Lineage matters because NHI compromise often begins with ordinary-looking code changes that introduce a token, service account credential, agent permission, or dependency behavior that later becomes an access path. When lineage is missing, security teams cannot reliably answer who approved the change, whether the dependency was vetted, or how far the exposure may have spread across downstream services.
NHIMG research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, while 79% have experienced secrets leaks and 77% of those incidents caused tangible damage. Those conditions make PR-level evidence critical for triage, containment, and accountable remediation. The same visibility problem also affects service accounts and automation, which is why lineage should be treated as operational evidence rather than developer convenience.
Organisations typically encounter the need for Pull Request Lineage only after a secret leak, malicious dependency, or policy violation is discovered, at which point the review trail becomes operationally unavoidable to reconstruct.
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 OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 | Traceability supports investigating how NHI-related code or secrets entered the repo. |
| NIST CSF 2.0 | PR.IR-1 | Traceable change records support security improvements and incident response recovery. |
| NIST Zero Trust (SP 800-207) | SA.L2-3 | Zero Trust emphasizes knowing what changed before granting trust to code paths. |
| NIST SP 800-63 | Identity assurance concepts inform attribution of who approved or introduced changes. | |
| OWASP Agentic AI Top 10 | A-04 | Agentic tooling can introduce changes that need auditable approval and lineage. |
Preserve PR evidence for NHI-relevant changes and review every introduction path during remediation.
Related resources from NHI Mgmt Group
- Should organisations allow pull_request_target for automated dependency workflows?
- What breaks when untrusted pull request content is executed in a workflow?
- What do security teams get wrong about pull_request_target workflows?
- Why do pull_request_target workflows create more risk than standard pull request workflows?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
