Dependency Reproducibility

Full bit-for-bit reproducibility — identical artefact bytes from identical source — is achievable and expensive, and for most organisations it is not the point.

What matters is that the same commit pulls the same dependencies, which is achieved by lock files with integrity hashes plus base images and build tooling pinned by digest rather than by tag.

Why it matters

• Rollback. Rebuilding a previous commit may produce a different artefact than the one that was known good, which turns a rollback into an unknown — the opposite of what a rollback is for.
• Incident attribution. A dependency that changed silently between builds is a cause that no code diff reveals, and it is one of the harder things to discover retrospectively.
• Security. A compromised or substituted package is prevented by hash verification, and "was this artefact built from our source" becomes answerable when paired with build provenance.
• Debugging. An artefact that cannot be recreated from its commit cannot be investigated.

Implementation patterns

• Lock files with integrity hashes, committed. A version range is a reproducibility hole, and a lock file without hashes protects against drift but not against substitution.
• Base images and build tooling pinned by digest, not by tag, because tags move.
• A hermetic build with no network access to unpinned sources during the build.
• Build provenance: a signed attestation of the source, the builder and the artefact, which addresses build-system compromise rather than dependency compromise and is what makes the security claim verifiable.
• Artefacts retained, so a rollback deploys the previous artefact rather than rebuilding it.
• No ambient credentials in the build environment. A build executes untrusted dependency and script code, and a build that can reach production secrets turns any dependency into a path to them — the single highest-value hardening step in most pipelines, independent of reproducibility and motivated by the same threat.

Industry example

Developer-tools organisations such as Postman ship widely-distributed clients where a compromised build reaches a very large number of machines, which raises the stakes on provenance specifically. The practical adoption order is consistently: pin and hash dependencies, remove ambient build credentials, add provenance attestations — and only then consider full determinism.

Failure scenarios

• Version ranges in a lock-free build, so the artefact drifts.
• Base images by tag, silently updated.
• Rebuild on rollback, producing an artefact that was never tested.
• Ambient production credentials in the build environment.
• Provenance claimed without attestation, which is an assertion rather than evidence.

Trade-offs

Pinning everything means dependency updates become explicit work rather than happening automatically, which some teams experience as friction and which delays security patches unless automated updates are set up alongside.

The resolution is automated dependency update proposals with good test coverage — the pinning provides the control and the automation provides the currency. Pinning without automated updates produces an estate that is reproducible and years out of date, which trades one risk for another.

Interview question

"You need to roll back to last week's version. Walk me through how you get that artefact, and tell me what could make it different from the one that was actually running."