GitHub code provenance controls are still too weak for supply chain risk

At a glance

What this is: This is a GitHub code provenance and supply chain risk analysis arguing that commit signing, origin validation, and third-party dependency verification remain necessary because 2FA alone does not secure trusted code paths.

Why it matters: For IAM, IGA, PAM, and NHI practitioners, the lesson is that software delivery now depends on identity assurance for developers, commits, and dependencies, not just account authentication.

Context

GitHub code provenance is the ability to show where code came from, who changed it, and whether it was altered in transit. In supply chain terms, that matters because trust breaks down when commits, dependencies, or CI/CD handoffs are accepted without strong origin evidence.

Beyond Identity's analysis argues that 2FA is not a code-integrity control. The governance gap is identity assurance for the people and systems introducing code, plus traceability for third-party libraries and build inputs.

For identity programmes, this is a developer and software supply chain problem with clear IAM and NHI implications. Developer identity, signed commits, and dependency provenance are part of the same control surface when organisations need to trust what reaches production.

Key questions

Q: What breaks when GitHub commits are not digitally signed?

A: Commit integrity becomes difficult to prove, attribution gets weak, and malicious or accidental changes can blend into ordinary development activity. Teams lose a reliable audit trail for incident review and may ship code that no one can confidently tie back to a verified source.

Q: Why does 2FA not solve software supply chain risk?

A: 2FA authenticates the login event, but supply chain risk appears when code is accepted, transformed, or reused later in the pipeline. A strong login control does not verify commit origin, third-party dependency integrity, or whether malicious code was introduced after authentication.

Q: How should teams detect weak provenance in GitHub-based delivery pipelines?

A: Look for unsigned commits, unknown contributors, unverified dependency sources, and merge paths that bypass normal review discipline. Those signals show where trust depends on process memory instead of cryptographic evidence and controlled source validation.

Q: How should security teams implement code provenance in developer workflows?

A: They should require cryptographic signing, verified identity binding, and branch protection that blocks unsigned or untrusted commits. Provenance checks need to happen before merge, because downstream scanning can detect defects but cannot prove origin. The control objective is to make authorship auditable at the point of entry.

Technical breakdown

Why GitHub 2FA does not prove code provenance

Two-factor authentication proves a user completed login, but it does not prove that a commit came from the expected developer, that the code was reviewed, or that a dependency was safe. Provenance requires a chain of evidence from author identity to commit signature to trusted build inputs. Without that chain, attackers can insert malicious code through legitimate-looking development activity and still satisfy basic platform authentication. The problem is structural: authentication answers who logged in, while provenance answers whether the code itself is attributable and intact.

Practical implication: treat 2FA as a baseline account control, not a substitute for commit signing and source validation.

How signed commits change the trust model

A digitally signed commit binds a change to a verified identity and lets reviewers distinguish expected contributions from unknown or altered ones. That matters because codebases are mutable, review windows are short, and change attribution is often lost when multiple people touch the same files quickly. Signed commits do not prevent every malicious change, but they create an audit trail that supports integrity checks and incident investigation. In GitHub-style workflows, that auditability is what turns a code review into a verifiable control rather than a procedural checkbox.

Practical implication: require signed commits for sensitive repositories and block merge paths that cannot prove author identity.

Why third-party code needs provenance controls too

Modern software inherits risk through packages, libraries, and transitive dependencies. A software bill of materials helps inventory those components, but inventory alone does not verify whether the code came from the expected source or whether it was tampered with upstream. Provenance controls need to extend to dependency validation, maintainer trust, and build integrity so that trusted code paths stay trustworthy after ingestion. This is where supply chain security and identity governance intersect most clearly: the organisation is not only authenticating users, it is authenticating the integrity of what those users import and ship.

Practical implication: validate third-party dependencies as part of release governance, not only during vulnerability scanning.

Threat narrative

Attacker objective: The attacker wants malicious code to enter trusted builds and reach downstream systems under the appearance of normal provenance.

1. Entry occurs when an attacker inserts or modifies code through a trusted development or dependency path rather than by breaking into a production system directly.
2. Credential or identity weakness lets the malicious change appear legitimate if the contributor, maintainer, or build source is not strongly verified.
3. Impact follows when signed or trusted code is distributed downstream, giving the attacker code execution, data access, or broad supply chain reach through normal software delivery channels.

Breaches seen in the wild

• Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.
• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Code provenance is now an identity assurance problem, not just a developer workflow problem. GitHub-style controls often focus on authentication at login, but software supply chain risk is created later, when code is accepted, merged, packaged, and reused. That means the governance question is whether the organisation can prove who introduced a change and whether the change stayed intact through the pipeline. The practitioner implication is that code provenance must be treated as an identity control surface.

Signed commits create the minimum viable trust boundary for modern development. Without signatures, attribution depends on process memory, ticket trails, or informal review, none of which scale well under release pressure. Signed commits do not eliminate insider risk or compromised developer accounts, but they make silent code substitution much harder and preserve evidence when something goes wrong. The implication is that provenance controls should be mandatory wherever release integrity matters.

Third-party libraries turn software supply chains into delegated trust chains. Once code is imported, the organisation inherits the authorisation and integrity assumptions of an outside maintainer ecosystem. That is why SBOM visibility alone is incomplete: inventory tells you what entered the tree, but not whether the source remains trustworthy. The practitioner implication is that dependency governance has to include provenance validation, not only vulnerability management.

Developer identity assurance belongs inside the same programme that governs NHI trust. Long-lived keys, unmanaged developer endpoints, and weak attribution all expand the blast radius of a compromised contribution path. The point is not that developers are NHIs, but that the organisation is making machine-enforced trust decisions about code flows that behave like delegated non-human execution. The implication is that identity, endpoint, and software integrity teams need a shared control model.

GitHub 2FA requirements are a floor, not a provenance strategy. Two-factor authentication reduces account takeover risk, but it does not prove commit origin, dependency integrity, or pipeline trust. The broader lesson is that identity security for software delivery has to shift from session authentication to source assurance. The implication is that reviewers should ask whether every accepted change can be attributed, validated, and traced end to end.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Ultimate Guide to NHIs — What are Non-Human Identities

What this signals

Code provenance should now be treated as part of identity governance. The practical shift is from trusting a logged-in developer to trusting a verified chain from author identity to commit signature to build input. That change matters because software delivery breaks in the handoff between identities, not only at the login screen.

Commit signing is the control that makes review enforceable. When a merge request cannot be tied to a verified corporate identity, review is only a procedural exercise. Teams that want stronger assurance should move provenance checks into the release gate, where attribution and integrity can still be verified before production.

For practitioners

• Enforce signed commits on critical repos Require digitally signed commits for repositories that feed production releases, and block merge paths that cannot map changes to verified corporate identities.
• Validate commit origin before merge Confirm that code is originating from trusted developers and not from unknown sources by combining signature checks, branch protection, and reviewer accountability.
• Treat developer identity as a control domain Extend continuous identity protection, endpoint patching, and device trust checks to developer workstations that can introduce code into the pipeline.
• Inventory and verify third-party dependencies Use a software bill of materials to identify imported libraries, then verify that each dependency came from the alleged author before release.
• Reduce long-lived key exposure in development Eliminate loosely managed private key material on BYOD and unmanaged systems so contributor credentials cannot outlive the trust granted to them.

Key takeaways

• GitHub supply chain risk persists when teams rely on authentication alone and do not verify who introduced code or whether it stayed intact through the pipeline.
• The article points to commit signing, origin validation, and dependency verification as the practical controls that change trust from assumed to evidenced.
• Security teams should align developer identity, source provenance, and third-party code governance so that release integrity is visible before code reaches production.

Key terms

• Code provenance: Code provenance is the verifiable history of where code came from and who or what created it. In security practice, it combines authorship, timestamps, signatures, and build lineage so teams can prove a change was trusted before it reached production.
• Commit signing: Commit signing is the process of attaching a cryptographic signature to a code change so it can be verified later. It is useful only when the signature is tied to a trusted identity and enforced by repository policy, otherwise it becomes weak evidence rather than strong assurance.
• Software Bill of Materials: A software bill of materials is an inventory of the components and dependencies used in an application. It helps teams identify what they shipped, but it becomes most useful when paired with source verification, signature checks, and policy enforcement for third-party code.
• Developer Identity Assurance: Developer identity assurance is the practice of verifying that engineering actions come from the intended person on a trusted device with valid credentials. It matters because modern development depends on tokens, keys, and automation that can behave like non-human identities if left unmanaged.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.