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

At a glance

What this is: This is a 5-point analysis of GitHub security practices, centered on code provenance, developer identity assurance, and third-party dependency verification.

Why it matters: For IAM and NHI practitioners, it shows why protecting non-human identities in development pipelines requires stronger attribution, signing, and supply chain controls than 2FA alone.

By the numbers:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Beyond Identity's 5 GitHub security best practices for code provenance

Context

GitHub security is not just a developer tooling issue. It is an identity and trust problem because code changes, dependency use, and CI/CD execution all create non-human identity pathways that can be abused when provenance is weak. In this context, the article argues that 2FA is necessary but insufficient for governing code supply chains.

The core gap is that many organisations still treat source control as a collaboration layer instead of an enforcement point for NHI governance. That leaves commit authorship, build trust, and third-party code verification exposed to the same kinds of assurance problems seen elsewhere in identity systems. The starting position described here is typical for modern software teams, which means the controls are broadly relevant rather than edge cases.

Key questions

Q: How should security teams reduce supply chain risk in GitHub-based development pipelines?

A: Start by treating code provenance as an access problem, not only a quality problem. Require signed commits, restrict merge permissions, verify dependency sources, and tie developer actions to managed devices and short-lived credentials. The goal is to ensure every code change can be attributed, validated, and revoked if the trust chain breaks.

Q: What is the difference between commit signing and SBOMs for code security?

A: Commit signing proves who created or approved a change and helps preserve integrity during development. An SBOM inventories the third-party components that enter the build. Together they answer different questions: who changed the code, and what code was included. Neither is sufficient alone, because provenance and inventory solve separate trust problems.

Q: Why do GitHub controls still fail when 2FA is enabled?

A: Two-factor authentication proves a user can complete login, but it does not prove that a specific commit, dependency, or pipeline action is trustworthy. Supply chain attacks often exploit downstream trust points after authentication has already succeeded. Security teams need provenance, signing, and least privilege, not just stronger login controls.

Q: Should organisations treat developer tooling as part of NHI governance?

A: Yes, because modern developer tooling depends on tokens, keys, service accounts, and automated approvals that behave like non-human identities. If those identities are unmanaged, they can introduce code, approve changes, or pull dependencies outside policy. Treating developer tooling as NHI governance makes provenance, rotation, and revocation enforceable.

Technical breakdown

Why commit signing is a provenance control, not just a hygiene step

Commit signing ties a code change to a verified identity and creates an integrity check for the development pipeline. Without that cryptographic binding, a repository can show that code exists, but not that it originated from the expected person or service account. In NHI terms, the commit itself behaves like a non-human action with security consequences, so the trust decision must happen at the point of creation, not after merge. Signed commits also help investigators reconstruct what happened when a change set looks suspicious or inconsistent.

Practical implication: Require signed commits for high-risk repositories and treat unsigned changes as exceptions that need documented approval.

How SBOMs reduce third-party dependency blind spots

A software bill of materials gives defenders a structured inventory of third-party components, but it does not by itself prove those components are safe. The real value is provenance: teams can compare what was pulled into the build against what was expected, then investigate tampering, dependency confusion, or malicious package substitution. This matters because open-source libraries often enter software through automated build paths that operate as non-human identities. When those paths are not continuously verified, the organisation inherits downstream trust it never explicitly granted.

Practical implication: Map SBOM review to release gates and verify that dependency sources, versions, and signatures match approved baselines.

Developer identity assurance is now part of code security

The article’s Know Your Developer idea is best read as identity assurance for the software factory. Remote work, unmanaged devices, and long-lived key material all weaken confidence that a commit, push, or approval came from the intended developer. That is a classic NHI problem because developer tooling increasingly relies on tokens, keys, and automated access paths that outlive the person’s immediate task. Strong endpoint controls matter, but they only work when paired with device-bound identity, short-lived credentials, and clear attribution across the SDLC.

Practical implication: Bind developer access to managed devices and short-lived credentials so code actions remain attributable throughout the delivery chain.

Threat narrative

Attacker objective: The attacker’s objective is to smuggle malicious or vulnerable code into a trusted release path so downstream organisations execute it as legitimate software.

1. Entry occurs when an attacker abuses weak commit provenance or compromised developer access to insert malicious code into a trusted repository or build path.
2. Escalation follows when unsigned or weakly attributed changes are merged, allowing the attacker’s code to inherit the organisation’s normal release trust.
3. Impact occurs when the altered package or application is distributed to downstream users, turning a single trust failure into widespread supply chain exposure.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Commit provenance is an NHI control, not a developer preference. The article correctly points to signed commits, but the deeper issue is that source control events now carry the same trust weight as privileged administrative actions. If a commit can change production behaviour, then the identity behind that commit must be governed like any other high-impact non-human actor. Practitioners should treat commit provenance as part of the access control model, not as a code-quality add-on.

Ephemeral build trust is the next frontier for supply chain defence. CI/CD systems increasingly consume credentials, tokens, and signed artefacts on behalf of people and services, which means the real attack surface is the handoff between human intent and machine execution. A short-lived session does not help if the pipeline accepts unverified inputs. Teams need controls that bind artefacts, identities, and approvals together across build, test, and release stages.

Third-party code verification must extend beyond inventory management. SBOMs are useful, but an inventory without provenance and policy enforcement only tells you what you shipped after the fact. Organisations should expect attackers to target dependency trust, package sources, and maintainer identities, because those are the weakest links in modern delivery chains. The practical conclusion is straightforward: inventory is necessary, but trust enforcement is what reduces blast radius.

Developer identity assurance and NHI governance are converging. The article’s focus on continuous identity protection reflects a broader trend where developers, bots, build agents, and automation all act through the same trust fabric. That makes lifecycle management, device assurance, and credential hygiene inseparable. Security teams should stop separating software supply chain controls from identity governance, because the same failure mode now spans both domains.

Code provenance is becoming part of Zero Trust for software delivery. Zero Trust is no longer only about runtime access to applications and infrastructure. It now has to cover who can create, modify, approve, and distribute code artefacts, and whether those actions are attributable and policy-bound. Practitioners should align code signing, device trust, and least privilege so a compromised path cannot masquerade as legitimate engineering activity.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• Start with 52 NHI Breaches Analysis to see how weak identity controls and exposed credentials turn routine development paths into breach paths.

What this signals

Ephemeral access alone does not solve supply chain trust. When code changes, dependency pulls, and build actions are all executed by non-human identities, the programme problem becomes provenance and revocation, not merely authentication strength. Teams that already rely on OWASP Non-Human Identity Top 10 controls should extend those policies into source control and CI/CD, because that is where code trust is created and broken.

Code provenance is becoming a board-relevant identity metric. If a commit cannot be tied to a verified identity and a dependency cannot be traced to an approved source, the organisation has an identity assurance gap inside its delivery chain. The practical signal is that secrets management, device posture, and release approval now need to be measured together rather than as separate security domains.

Developer workflows are now part of the identity attack surface. With 32.4% of security budgets already going to secrets management and code security, per The State of Secrets in AppSec, the remaining gap is not awareness but enforcement. Security teams should prepare for tighter control over managed devices, signed artefacts, and pipeline service accounts, because those controls are what reduce blast radius when trust fails.

For practitioners

• Require signed commits for high-risk repos Enforce cryptographic commit signing on repositories that feed production, and block merges when authorship cannot be tied to a verified corporate identity.
• Add provenance checks to dependency intake Validate package origin, maintainer identity, and signature status before dependencies enter the build, then compare them against the approved SBOM baseline.
• Bind developer access to managed devices Use continuous device posture checks, short-lived credentials, and endpoint controls so development actions remain attributable and revocable.
• Treat CI/CD as a privileged NHI environment Inventory tokens, keys, runners, and service accounts in the pipeline, then apply least privilege and rotation controls to each non-human identity.

Key takeaways

• GitHub security failures often begin as identity failures, because unsigned code and weakly attributed changes break the trust chain before production is ever reached.
• Supply chain defence requires both provenance and inventory, since commit signing and SBOMs solve different parts of the same code-trust problem.
• Security teams should extend NHI governance into developer tooling, CI/CD, and dependency intake to reduce the blast radius of compromised code paths.

Key terms

• Code Provenance: Code provenance is the ability to trace a code change or dependency back to a trusted source, author, and approval path. In practice, it combines signing, attribution, and build traceability so defenders can verify what entered the pipeline and whether it matched policy.
• Commit Signing: Commit signing is a cryptographic method for proving that a code change came from a specific verified identity. It strengthens integrity, but it only works when organisations also control keys, devices, and merge permissions across the full delivery chain.
• 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

GitHub commit signing, developer identity assurance, and NHI governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is working to secure software delivery paths and provenance controls, it is worth exploring.

This post draws on content published by Beyond Identity: 5 GitHub Security Best Practices. Read the original.