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
The score starts at 100 and subtracts points across four signal families,
each capped so no single family can zero the score on its own.
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.
Public explorer
The scores are also browsable without signing in, atpipefort.com/actions:
- Directory — every scored action, ranked riskiest-first. Search by
owner/nameor paste a GitHub repository URL; the table live-filters as you type, and a sort toggle switches between riskiest-first and A–Z. - Detail page —
pipefort.com/actions/{owner}/{name}shows the grade, the full per-family deduction breakdown with evidence (which findings, metadata, tag moves, and advisories cost how many points), links to the scored commit and releases on GitHub, and a compact version history. - On-demand scoring — an action that isn’t in the catalog yet can be scored right away from its detail page. Scoring runs in seconds; if GitHub is temporarily unreachable it falls back to the daily worker instead.
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.