Why do git dependencies create supply-chain risk that registry scanning misses?

Why registry scanning misses the real risk in git dependencies

Git dependencies shift trust from a package registry to a source repository, so the security question is no longer just “is the published artifact known bad?” The build can fetch whatever the repository contains at resolution time, including installer logic, nested references, or changes that never passed through registry review. That creates a gap between package visibility and actual build input.

Registry scanning is still useful, but it has a narrower view of the problem. It can inspect a published version, detect known malicious packages, and surface obvious exposure in public registries, yet it will not fully capture source-level compromise, tampered install steps, or repository content that is pulled directly into a build from outside the registry path. Provenance and dependency controls close that gap.

Git dependencies also weaken the assumptions behind many software composition tools. If the dependency is resolved from a commit, branch, tag, or submodule, the build may consume content that changes outside the cadence of registry publication. That means the most important security property is not just “what name and version was installed,” but “what exact source state was trusted and how was it verified?”

Where the exposure comes from

The exposure comes from the resolution path. A registry scan usually evaluates the package object that was published, but a git-based dependency may bring in code directly from a repository, along with build scripts or metadata that execute during install. If an attacker can alter the source, compromise the maintainer, or abuse a token that controls the repository, the malicious content can reach the build without ever appearing as a suspicious registry artifact.

Lifecycle management matters here because the dangerous state often begins with stale access, unrevoked credentials, or weak offboarding around the repository path rather than the registry itself. Git config credential exposure and CI/CD pipeline exploitation both show how access to source-adjacent systems can let attackers alter what gets built long before a registry control would notice.

Another blind spot is that registry scanning tends to reason about a package at rest, while git dependencies are often evaluated in motion. A source repo can contain install hooks, configuration files, generated assets, or references to additional code that are only activated during dependency resolution. In practice, this is why the trust decision must extend beyond the package index to the commit, the maintainer, and the build path.

Why provenance beats package-only visibility

Provenance answers a different question than malware scanning. It asks where the code came from, who controlled it, and whether the build consumed the exact source that was intended. That matters because a clean registry record does not prove the repository was clean, and a clean repository at one point in time does not prove the same state was used when the build ran.

For that reason, provenance checks are the control that actually reduces git dependency risk. They make source drift, branch tampering, and dependency substitution harder to hide, especially when paired with pinned references, signed commits or tags, and repeatable builds. SLSA is directly relevant because it focuses on build provenance and artifact integrity, which are the missing assurances when dependency resolution happens outside a registry boundary.

NIST SSDF (SP 800-218) also applies because secure development practices should verify third-party input, protect the build pipeline, and preserve integrity evidence for what entered the software. In other words, registry scanning tells you something about the package catalog, while provenance tells you something about the supply path that created the build.

Practitioner Guidance

What to prioritise: Treat git dependencies as source-trust decisions, not just package-selection decisions. If your build can pull code from a repository, branch, or tag, require pinned references and provenance evidence before you rely on registry scan results.

What to verify: Confirm that the resolved commit, the repository owner, and any install-time actions are observable in your build records. If you cannot prove what exact source state was consumed, assume registry scanning left part of the risk uncovered.

Common mistake: Teams often trust a clean registry report and stop there. That is a false sense of coverage when the dependency path can execute source-controlled logic outside the registry’s review boundary.

Practitioner takeaway: Use registry scanning for package reputation, but use provenance, pinning, and build integrity controls for the actual trust decision, because git dependencies can fail safe-looking package checks while still delivering attacker-controlled source into the build.

Related resources from NHI Mgmt Group

• Why do exposed model registry tokens create supply-chain risk?
• Why do vulnerable dependencies create such a large software supply chain risk?
• Why do transitive dependencies create more software supply chain risk than direct packages alone?
• Why do third-party dependencies create more supply chain risk than first-party code?