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 was introduced, who introduced it, and which review and approval steps allowed it into the repository. It is narrower than generic software provenance because it focuses on the pull request path inside a codebase, not the full supply chain from source publisher to build output.
In practice, lineage connects the package, the pull request, the contributor, and the review record so teams can answer basic trust questions after a policy violation, dependency compromise, or risky upgrade. It is especially useful when a repository accepts many third-party libraries over time and ownership becomes diffuse. A common misunderstanding is to treat dependency metadata as sufficient on its own; lineage adds the human and workflow context that package manifests do not provide. Where teams already track software bills of materials or commit history, pull request lineage complements those records by showing the decision path that brought the dependency in.
Examples and Use Cases
Security and engineering teams use pull request lineage to reconstruct how a dependency change happened and whether the review path was appropriate. It is most valuable when the question is not just what entered the codebase, but how it was approved.
- A dependency is added in a feature branch, then merged through a normal review process, and lineage shows the exact pull request that approved it.
- A package update later proves malicious, and lineage helps identify which contributor introduced it and whether the review was cursory or bypassed.
- An internal policy requires approved maintainers for high-risk libraries, and lineage provides the audit trail needed to verify that the rule was followed.
- A legacy repository contains many old dependencies, and lineage helps teams separate inherited packages from recently introduced ones during remediation.
- A security team is tracing exposure after a vulnerable package disclosure, and lineage narrows the investigation to the specific pull requests that added or upgraded the package.
The main tradeoff is completeness versus effort. Lineage is most reliable when repositories enforce consistent pull request hygiene, because ad hoc merges, rebases, or missing review metadata can weaken the record.
Security Implications
When pull request lineage is missing or unreliable, organisations lose the ability to explain why a dependency exists and who accepted the risk of adding it. That creates gaps in ownership, slows incident response, and makes it harder to distinguish intentional adoption from accidental or unauthorised inclusion.
Weak lineage can also hide policy violations. A dependency may have entered through an emergency fix, a rushed approval, or a review that did not examine its source, licence, or trust history closely enough. In those cases, the issue is not only the package itself but the fact that the repository lacks a clear control record showing how it was admitted. Practitioners should expect lineage failures to surface as unclear approvers, inconsistent review notes, missing links between dependency change and pull request, or uncertainty about whether a dependency was reintroduced after prior removal.
For security teams, the operational consequence is slower containment. If a compromised or risky dependency appears across many repositories, lineage helps determine where the exposure started and which changes must be reversed first.
Domain and Governance Relevance
Pull request lineage matters most in software supply chain governance because it turns dependency introduction into an auditable decision path rather than an opaque event. That makes it useful for ownership, review accountability, and exception handling when teams need to justify why a package was accepted despite risk.
For identity and access governance, the concept is indirect but still relevant when pull request approval rights are tightly controlled. If only specific maintainers may approve high-risk dependency changes, lineage becomes part of the control evidence showing whether those privileges were used appropriately. It also supports post-incident review when a repository’s effective trust boundary was expanded by a contributor or workflow that should not have had that level of change authority.
The governance value is practical rather than theoretical: lineage gives teams a durable record for dispute resolution, audit questions, and cleanup after compromised accounts, unsafe reviews, or policy drift.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST IR 8596 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Pull request lineage depends on who was allowed to approve dependency changes. |
| 16 — Application Software Security | Lineage supports tracing how third-party code entered the repository. | |
| 18 — Penetration Testing and Security Assessments | Lineage helps validate whether risky dependency changes were properly controlled. | |
| Recommendation — Restrict approval rights for dependency changes and review lineage records for anomalous access paths. Track dependency introductions through pull requests to support software security review and remediation. Test whether dependency admission paths leave an auditable trail for security review and response. | ||
| NIST CSF 2.0 | GV.OV-01 — Risk Management Strategy | Lineage provides evidence for governance decisions about accepted dependency risk. |
| ID.IM-01 — Improvements | Lineage supports lessons learned after unsafe dependency introduction or compromise. | |
| PR.PS-03 — Software, Data, and Hardware Integrity | The concept preserves integrity evidence for dependency changes entering codebases. | |
| Recommendation — Use pull request lineage to document how dependency risk was accepted and reviewed. Feed lineage gaps into improvement actions after dependency-related incidents. Preserve pull request lineage as integrity evidence for dependency introduction and review. | ||
| MITRE ATT&CK | T1195 — Supply Chain Compromise | Lineage helps trace compromised dependencies introduced through the code review path. |
| Recommendation — Map dependency-introduction records to supply-chain compromise investigations and containment. | ||
| NIST IR 8596 | IR-4 — Incident Analysis | Lineage shortens investigation of how a risky dependency entered the repository. |
| Recommendation — Use lineage to reconstruct the dependency entry path during incident analysis. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Inventory and Ownership | Lineage is relevant when repositories contain non-human identities that approve or introduce changes. |
| Recommendation — Record which non-human identities and maintainers introduced dependency changes and who owns them. | ||
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 September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
