Repository navigation
Feature: Clarify goals of unpinned-tools #2024
Description
Pre-submission checks
- I am not reporting a bug (crash, false positive/negative, etc). These must be filed via the bug report template.
- I have looked through both the open and closed issues for a duplicate request.
What's the problem this feature will solve?
unpinned-tools mixes different threat models, which was briefly discussed in #1775 (comment).
If I had to categorize the threat models into different tiers:
| Tier | Example | Adversary | Protection |
|---|---|---|---|
| T1 | 8daa57c044... |
Math | Math |
| T2 | Unpublish protection | Platform | Social contract |
| T3 | v1.2.3 |
Author | Social contract |
| T4 | v1 |
Author | SemVer |
| T5 | latest, main |
Author | Author |
Currently unpinned-tools only protect against accidental breaking changes. Outside of that, you have different degrees of remedies available. Which varies widely. I have collected some below.
Internally checked with checksum (T1)
astral-sh/setup-uvsecurego/gosec(not configurable)zizmorcore/zizmor-action
Hardcoded to mutable reference (T3)
Hardcoded to mutable reference (T4)
Hardcoded to latest (T5)
with.version defaults to latest (T5), accepts mutable reference (T3)
appleboy/ssh-actionoven-sh/setup-bun(validates checksum, but tags are not locked)trufflesecurity/trufflehog
env.WRANGLER_VERSION defaults to 4 (T4), accepts mutable reference (T3)
with.override_version defaults to "" (T5), accepts hash (T1)
Describe the solution you'd like
The goals of the unpinned-tools audit should be clearly defined.
- Is anything other than
latestfine (i.e. T1-T4)? - Should it only alert if there's a remedy?
apt?- Indirect dependencies (
pipx,npx, ...)?
Additional context
Practically I would say it should alert only if its on latest (implicit / explicit) and the user can do something about it. There's a slight mismatch with the security model in unpinned-tools and unpinned-uses, but there's not much you can do about it if you want to use most workflows / avoid alert fatigue.
I have not taken other audit rules into account.
Unsure if this fits better as an issue or discussion. Please move as appropriate.
Activity
woodruffw commentedon May 16, 2026
Hi @vetleledaal, thanks for opening an issue.
Yeah, I think this would be a good fit for a discussion: at the moment the primary goal of
unpinned-toolsis limited just to flagging a small subset of "mutable pointer" risks, specifically the risk associated with an action that pulls the "latest" version of a binary by default. There are lots of other flavors of that risk though, as you note (like versions themselves being mutable, not pinning to hashes intrinsically or extrinsically, etc.)In general, I'd like to see this audit be generalized to cover those kinds of cases, and getting user/community feedback on what they'd fine useful on that topic (in terms of value/minimizing alert fatigue) would be very valuable.