Nearly everything a CI job pulls in at run time — shared build steps, container images, tool installers, dependency version ranges — is referenced by a mutable name. Why is that a code-execution risk, and what does pinning to a digest or commit change?

## Names versus things Start with the distinction that the whole answer rests on. `v3`, `main`, `1.4`, `^2.0.0` and `https://tools.example.com/install.sh` are **names**. They are resolved at the moment the build runs, by asking a remote party what that name means today. `sha256:9f2b…` and a 40-character commit hash are **things**: the reference is a cryptographic digest of the content, so there is exactly one byte sequence that satisfies it and any substitution is detectable by construction. Every build has a list of names it resolves. A representative one: - reusable build steps or shared pipeline templates, referenced by tag or branch - the container image the job runs inside, and the base image in the build - language dependencies, resolved through version ranges against a public index - tool installers fetched over HTTPS and piped into a shell - files fetched from an internal artifact store by a floating "latest" alias ## Why this is specifically a code-execution risk It is tempting to file mutable references under "reproducibility". They are a reproducibility problem, but the security problem is sharper: each of those resolved items is *executed* inside the job. Dependencies run install hooks; the base image supplies the interpreter; the shared build step is a program; the installer is a shell script. So control over any one of those names is control over code running with your build's credentials. The delivery mechanism that makes this dangerous is that nothing in your repository changes. A tag is repointed upstream, or an account is compromised and a package version republished, and the next scheduled build simply picks it up. There is no commit to review, no diff to notice, and the change lands identically on every consumer at once — which is what makes attacking a widely-used name economically attractive. ## What pinning actually buys, and what it does not Pinning converts "whatever is behind this name" into "exactly these bytes". Concretely: - an upstream tag move, silent republish or account takeover no longer changes your build - the resolved input becomes part of your reviewed history: a change to what runs is a diff - builds become far more reproducible as a side effect, which is what lets you compare two builds at all What pinning does **not** buy is trust in the pinned content. If you pin to a version that was already malicious, you have faithfully frozen the malware. Pinning is an integrity control — it answers "is this the same thing I decided on?" — and it must be paired with a separate decision about whether the thing was ever any good. ## The real cost: pins go stale This is where candidates who have only read about it stop, and the interviewer usually pushes. A pinned reference receives no upstream security fix. An organisation that pins comprehensively and then never updates has traded a supply-chain risk for a known-vulnerability risk, and after a year the second one is usually worse. So pinning is only half a policy. The other half is an update process: something that regularly proposes raising each pin, runs the pipeline against the new content, and presents the bump as a normal reviewable change. That is the point — the update becomes a diff someone approves, rather than an invisible event. Teams that adopt pinning without automating the refresh predictably abandon it. A second cost is friction on transitive references. Pinning your direct dependencies while their own dependencies float only closes the outer door; lockfiles exist to record the entire resolved graph, which is why a committed lockfile is the equivalent control in the package ecosystem. ## Applying it proportionally Not every name deserves the same treatment. A workable ordering: 1. **Anything third-party that executes in a job with credentials** — shared build steps, installers, images that run the build. Pin these first; the blast radius is immediate. 2. **Dependencies of shipped artifacts** — pin via a committed lockfile so the resolved graph is recorded and reviewed. 3. **Internal, already-trusted references** — pin for reproducibility; the security argument is weaker because you control the publisher. For the installer case specifically, when a digest is unavailable the equivalent is to download, verify a recorded checksum, and only then execute: ```bash curl -fsSL -o install.sh https://tools.example.com/install.sh echo "9f2b0c…c41 install.sh" | sha256sum -c - sh ./install.sh ``` ## The sentence to land in an interview "A mutable reference means a third party can change what my build executes without a commit in my repository. A digest makes that change either visible or impossible — and it obliges me to run an update process, because a pin that never moves is a vulnerability that never gets patched."