After moving a release job to trusted publishing, which supply-chain attacks does it still not stop?
answer
- it authenticates the publisher, not the payload
- trigger and registration became the soft spots
- the minted credential is live in-job
- blast radius shrunk, not removed
- merged malicious code publishes cleanly
basics
~20 sTrusted publishing authenticates which workflow published, not what it published. A malicious change merged to the release branch, a compromised step using the credential inside the job, or an owner re-pointing the registration all still produce a legitimate release.
solid answer
~50 sIt removes one thing: a durable, portable, stealable publish secret. Everything that does not depend on stealing that secret survives. Content is unchecked - a malicious commit merged into the release branch publishes cleanly under the correct identity, and consumers see a perfectly valid release. Anything running inside the release job can use the minted credential during its short life, so a compromised third-party build step no longer exfiltrates a token for later but can still push its own artifact right now. The trust anchor moved to the registration and the trigger: whoever can edit the trusted publisher configuration, or cause the authorised workflow to run on code they control, can publish. So the controls that now carry the weight are branch and tag protection, review on the release path, an approval-gated environment, and treating the steps that run in the release job as trusted code.
go deeper
Remember the boundary as a sentence: it proves where a release came from, not that the release is safe. Do not describe it as making a package trustworthy.
Be able to explain why a compromised step inside the release job is still a problem, and how the credential's short life and narrow scope change the attacker's economics without removing the path.
Demonstrate a residual-risk register: name each attack the control does not cover and the specific control that does, and argue why the release job should be small and its trigger protected.
Own the framing that an authentication control on the release path shifts attacker effort rather than ending it, and be ready to say where you would spend the next unit of effort once the credential problem is gone.
## Ask what the control actually authenticates Trusted publishing answers exactly one question: *did this upload come from the workflow the project owner authorised?* Everything a senior engineer needs to say about its limits follows from taking that sentence literally. It says nothing about the artifact's contents, nothing about whether the change deserved to ship, and nothing about who caused the workflow to run. ## What still gets you **Malicious or compromised source, merged.** The release job faithfully builds whatever is on the release ref. If an attacker gets a change merged - a subverted contribution, a maintainer under coercion, a compromised maintainer laptop - the resulting release is authentic in every technical sense. The identity is correct. This is the single most important limit to state, because it is where people over-claim: publish-time authentication is not source integrity. **A compromised step inside the release job.** Consider a Python geospatial-analytics library on PyPI whose release job invokes several third-party build steps. Under the old model the interesting prize was the long-lived upload token sitting in the environment: read it once, publish from anywhere, whenever. Under trusted publishing there is no such token - but the minted credential is live inside that job, and any step in it can reach the same environment. The attacker's window shrinks from *forever and anywhere* to *this run, from inside this job*, and the credential is scoped to one package rather than the account. That is a large reduction in blast radius and not a removal: the compromised step can still upload its own artifact under the legitimate identity, right now. This is the arithmetic worth being explicit about, because it explains why pinning and minimising what runs in the release job stays a live concern after the migration. **Whoever controls the trigger.** If the authorised workflow runs on every push to the default branch, then whoever can push to that branch can cause a publish. If it runs on any tag, then whoever can create a tag can. Trusted publishing pushed the credential out of reach and left the *trigger* as the soft spot, which is why branch and tag protection, required review, and an approval-gated environment are not optional extras after the migration - they are now the primary access control on publishing. **Whoever controls the registration.** A project owner at the registry can add or change a trusted publisher. An attacker who takes over such an account can point the package at a repository they control and publish legitimately. The root of trust moved from a secret to an account, so the strength of that account's authentication is now load-bearing. **Stale or over-broad configuration.** A registration left pointing at a repository that was renamed, transferred or deleted can, in the worst case, become satisfiable by someone who claims the freed name. A registration that names only the repository, not the workflow, lets anyone who can add a file publish. **Everything after publication.** Trusted publishing has nothing to say about a version already in the wild, about a consumer resolving it, or about the resolution behaviour that decides which version a build picks up. ## The corresponding control set | Residual risk | Control that actually addresses it | |---|---| | Malicious change merged | Review on the release path, protected refs, two-person rule for releases | | Compromised step in the release job | Minimal release job, no untrusted code beside the publish step, pinned dependencies of the job itself | | Anyone able to trigger a release | Tag and branch protection, environment approval gates | | Registration re-pointed | Phishing-resistant multi-factor and limited ownership on the registry side | | Over-broad registration | Pin workflow, ref and environment, not just the repository | ## How to answer this in an interview A weak answer treats trusted publishing as a security upgrade with no stated threat model - *we moved to OIDC, so the supply chain is secure*. A strong answer names the class of attack it closes (theft and reuse of a durable publish credential), names what remains (content, trigger, registration, in-job execution), and says which control now carries each remaining risk. The framing that lands: *it made the credential worthless to steal, so the attacker's cheapest path is now to get code into the release, or to get the release to run.* Then you talk about what defends those. The same discipline applies to any authentication control on a delivery path. Ask what it authenticates, take the answer literally, and enumerate everything the sentence does not cover. That enumeration is the residual risk register, and having one is what distinguishes an engineer who deployed a control from one who understands it.
- If a compromised build step can still use the minted credential, what did the migration actually buy?Three things: the attacker must be present in a specific job at release time rather than anywhere at any time; the credential expires in minutes rather than persisting until someone revokes it; and it reaches one package rather than the whole account. The attack goes from silent and open-ended to noisy, narrow and time-boxed.
- How would you reduce the risk from third-party steps in the release job itself?Make the job that holds the credential as small as possible - build and test elsewhere, and let the publishing job only take an already-built artifact and upload it. Fewer steps run beside the credential, and the ones that do are code you have reviewed. Splitting build from publish is the structural fix; hardening a large release job is the weaker one.
- A team says trusted publishing means they no longer need branch protection on the release branch. What do you say?The opposite is true. Once the credential cannot be stolen, causing the authorised workflow to run is the cheapest way to publish, and the branch or tag that triggers it is what decides who can do that. Removing protection there hands publish rights to anyone with write access.
saying these in an interview costs you the question
- Claims trusted publishing prevents malicious code in a release
- Says nothing in the job can use the minted credential
- Treats branch protection as redundant afterwards
- Ignores that a registry owner can re-point the publisher
- Presents it as a complete supply-chain solution