CI/CD Pipeline Security Interview Questions: Supply Chain Security

Floating tags like latest can be republished or updated by the maintainer (or an attacker who compromises the package) at any time, meaning a build that passed review today could pull a different, malicious artifact tomorrow. Pinning to a cryptographic digest ensures the exact bytes that were reviewed are the ones used in every subsequent build, which is the core idea behind supply-chain integrity in CI/CD. The other options describe unrelated concerns: caching, cost, and compatibility are not guaranteed by digest pinning.

Git tags are mutable references: whoever has write access to the repository, including an attacker who compromises a maintainer account, can force-push a tag like v4 to a different commit. A full-length commit SHA identifies one exact snapshot of the content and cannot be repointed, so a workflow pinned to a SHA keeps running the code that was reviewed even if the tag is later moved. The statement is therefore true.

A dependency-confusion attack exploits a pipeline that resolves package names against a public registry before (or instead of) a private one. A lockfile records the exact resolved versions and integrity hashes of every dependency from a prior trusted build; restoring from the lockfile and failing when it is out of sync with the manifest ensures the pipeline fetches the same vetted package versions rather than resolving names dynamically and pulling a newly published malicious package. Branch protection, artifact storage, and parallel test execution do not address dependency resolution or supply-chain integrity.

The key point is that a Git tag is just a movable pointer, so its meaning can change after you reviewed it. Whoever controls the repository, including an attacker who has compromised it, can repoint v4 to new code, and a workflow referencing @v4 will pull that code without any change to the workflow file. A 40-character commit SHA names one specific snapshot of the source tree and cannot be redirected to different content, which is why pinning to a SHA is the recommended mitigation for third-party actions.

Under SLSA v1.0, Build Level 1 only requires that build provenance exists — it may be self-reported by the build script itself, so an attacker who controls the build can forge it. Build Level 2 introduces the requirement that provenance is produced by a hosted/managed build service in a way the build's users cannot tamper with, making the attestation non-falsifiable by the party running the build. The claim that build provenance attestations must be cryptographically signed by the build platform's key management service describes a possible implementation mechanism for non-falsifiability, but cryptographic signing by a KMS is not itself the stated Level 2 requirement. The claim that builds must be fully isolated from one another, running in separate hardened environments with no shared infrastructure describes a Build Level 3 requirement (hardened, isolated builds). The claim that all transitive build dependencies must be pinned and verified against a cryptographically locked dependency manifest concerns dependency/source integrity, which SLSA addresses through separate source-level tracks, not the build-level distinction between L1 and L2.

An SBOM is the inventory that answers the question 'what is inside this artifact?' It is generated from the actual build so it reflects the real dependency graph, including transitive dependencies and base images. This lets responders scope exposure to a CVE across deployed artifacts without rebuilding or guessing, which is the core reason pipelines emit SBOMs alongside build outputs.

Supply-chain hardening is about provenance and least privilege. Pinning dependencies and actions to an immutable commit SHA stops an attacker who repoints a mutable tag (a common attack) from injecting code into your build. Signed provenance/attestations let downstream consumers verify an artifact really came from your trusted build, the core idea behind SLSA. The two distractors are the opposite of hardening: broad token permissions widen the blast radius of any compromised step (least privilege is the rule), and unrestricted egress lets a malicious step exfiltrate secrets or pull attacker-controlled payloads. 'Make it never fail' and 'let it reach anything' are convenience choices that trade away security.

Each adjacent pair is a true data or trust dependency. The source must be pinned before dependencies are resolved from the lockfile, because the lockfile belongs to that commit. Dependencies must be present before the hermetic build runs. The build produces the image digest, which is the subject that the SBOM and provenance attestation must reference, so attestations come after the build. The signature covers the digest and its attestations, so signing comes after both are generated. Admission verification can only check a signature that exists, so it follows signing and precedes scheduling. Rollout of the image happens last, once it has passed verification.

pull_request_target runs in the context of the base repository, so it has access to repository secrets even for a pull request from a fork — unlike the normal pull_request trigger. The fatal combination here is then checking out and running the PR's own code (github.event.pull_request.head.sha) with npm install && npm test: an attacker opens a PR with a malicious package.json script or test that reads secrets.DEPLOY_KEY from the environment and ships it to an attacker server. GitHub's own guidance is to never check out or execute untrusted PR code in a pull_request_target workflow that holds secrets. Pinning checkout, using npm ci, or the runner image are red herrings — the bug is executing untrusted code with secret access.

In keyless Sigstore signing, cosign obtains an ephemeral key pair and sends the public key plus an OIDC identity token to Fulcio, the certificate authority that verifies the identity and issues a short-lived certificate binding that identity to the key. The signature is then recorded as an entry in Rekor, an append-only transparency log built on a Merkle tree, so verifiers can later confirm the signature existed while the certificate was valid. Cosign is the client tool that drives this flow rather than either service, so it is not the answer to either blank.