uses: owner/repo@ref) is a
piece of code you run in CI. Pipefort gives each one a persistent risk score
(0–100) and a letter grade (A–F), shown in the Actions used section on
each repository page. The score is intrinsic to a specific
version of an action — keyed to the exact commit it resolves to — so it
reflects the action’s own hygiene, not a one-off guess.
What the grade means
| Grade | Score | Read it as |
|---|---|---|
| A | 90–100 | Clean, well-maintained, trusted publisher |
| B | 80–89 | Solid, with minor concerns |
| C | 70–79 | Some risk worth a look |
| D | 60–69 | Notable concerns |
| F | < 60 | High risk — review before relying on it |
The four signal families
- Static analysis — Pipefort runs its own scan engine over the action
repository’s
.github/workflows/*files. High-severity findings in the action’s own CI are the main signal here; medium findings count lightly and this family is capped so it can’t dominate the score on its own. - Publisher & repository metadata — whether the repo is archived, how recently it was pushed, how old and popular it is, and whether the owning organization is a verified GitHub org.
- Version hygiene (tag stability) — if an exact SemVer release tag
(
v1.2.3) has been observed pointing at more than one commit over time — a sign the publisher rewrites releases — the version is penalized. Floating tags (v4,v4.1) are expected to move and never deduct. - Known advisories — published GHSA security advisories affecting the action, with a heavy penalty when the specific version you reference falls inside a vulnerable range.
Intrinsic score vs. how you pin it
The stored score describes the action version itself. How your repository references it is a separate axis: pinning to a full commit SHA is safest, a tag is next, and a mutable branch (@main) is riskiest because it can
change under you.
Each usage in the Actions-used table carries a pin-type badge (SHA / tag /
branch). The repository aggregate shown in the section header combines the
per-action scores and then applies a small penalty for branch-pinned usages —
so the repo-level grade reflects both what you use and how you pin it.
”Pending analysis”
Scores are computed by a background worker, and popular actions are pre-scored before launch — so most actions show a grade immediately. When you reference an action Pipefort hasn’t scored yet, its row shows Pending analysis and the repository aggregate is marked provisional. The worker picks it up and the grade appears — usually within a day — with no need to re-scan; just reload the repository page.Freshness
Scores are refreshed on a monthly (30-day) cadence, and the entire catalog is re-scored whenever Pipefort’s scoring formula is versioned up — so grades track both the action’s evolving posture and improvements to the algorithm.Limitation
In this version, the static-analysis family scans an action’s workflow files only. It does not analyze the action’s runtime code — the JavaScript, Docker image, or composite steps declared in itsaction.yml. Deeper runtime
analysis is planned; today’s grade is strongest as a signal of an action’s
maintenance, provenance, and known-vulnerability status.