DEV Community

yutianle
yutianle

Posted on

Dependency Verification: What Pinning Buys and What It Does Not

#supplychain #dependencies #verification

Dependency Verification: What Pinning Buys and What It Does Not

Pinning dependencies to exact versions is the most widely adopted supply chain control, and it is frequently described as though it prevents a malicious package from reaching production. It does not. Exact versions make builds reproducible, and reproducibility is a prerequisite for verification rather than a substitute for it.

What pinning changes

A lock file with exact versions and content hashes makes the resolved dependency graph deterministic. The same lock file produces the same set of artefacts on a developer machine and in the pipeline, which removes version drift as a source of inconsistency.

That determinism has a security consequence. A package republished under the same version number with different content breaks the hash check rather than being installed silently. Without a lock file and hash verification, that substitution is invisible.

The limit of the control is visible in the same example. A malicious package published under a new version number is not affected by pinning, and a transitive dependency that is not pinned is resolved at install time. Teams that pin direct dependencies and ignore transitive ones have closed part of the gap.

Verification beyond the lock file

Signature verification answers a different question than hashing. A hash proves the artefact is the one that was reviewed. A signature proves which key produced the artefact, and it allows a consumer to apply a policy about which producers are acceptable.

cosign verify --certificate-identity-regexp '^https://github.com/example/.*$' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  registry.example.com/app@sha256:0000000000000000000000000000000000000000000000000000000000000000
Enter fullscreen mode Exit fullscreen mode

Provenance goes further. A build attestation records what source revision produced an artefact, by which build process, and from which inputs. SLSA describes levels of this capability, from a documented build process through to a hardened one that produces non-falsifiable provenance. OSSF Scorecard produces a related view by scoring repository practices such as branch protection and review requirements, which is useful as a triage signal for a large dependency tree.

An SBOM complements all of the above by listing what is inside an artefact. Its value depends on what it is used for. An SBOM that is generated and stored without being compared to a vulnerability feed or a policy list is an audit artefact rather than a control.

Where the process breaks

Three failure points account for most of the gap between the described process and the one that runs. The verification step is optional, so a pipeline continues when it fails. The allowed producers are defined in a list nobody updates, so a legitimate new signer is blocked and a developer disables the check. And the dependency update automation merges version bumps without distinguishing a patch bump from a change in the publishing identity.

The last point deserves attention because update automation is where pinning and verification interact. An automated update that changes a version is fine when the producer identity is verified. An automated update that accepts any publisher is a mechanism for installing whatever is published next.

References

Top comments (0)