Skip to main content

​
Two views

The same references, rolled up two ways. The view switch in the toolbar picks which question you are asking:
  • by repository (default) — which repository is worst at depending on third-party actions, and why.
  • by action — which repositories a given action reaches, and how each of them pins it.

​
By repository

Answers “which repository is worst, and why” — and shows the arithmetic rather than just the grade. The left column ranks every repository weakest-first: its grade and score, the score of its weakest action, and how many references sit on a mutable branch. The right column is the working behind the selected repository’s grade:
  • Scored references — every action score that fed the aggregate, with the minimum ringed in red.
  • Min-weighted base — 0.6 × min + 0.4 × mean, printed with the actual numbers. The weakest reference carries 60% of the base, so one bad action outweighs five good ones.
  • Pin penalty — −5 per branch reference, capped at −15. This is a usage modifier: it belongs to the repository, not to the action, because the same commit can be referenced well or badly.
  • The result — base minus penalty, clamped to 0–100, and its letter grade.
What would move it re-runs each lever through the same formula rather than estimating: SHA-pinning every branch reference, replacing the weakest action, and the ceiling if every reference were an A pinned by SHA. References in this repository lists each action as written, what it is pinned by, and its score. Selecting one opens its deduction ledger inline — the same ledger the public action report shows, including the family caps. Caps are the point: once a family is at its cap, the next finding in it changes the grade by zero.

​
By action

The inverse rollup, and the one an advisory forces you to answer: if this action turns out to be malicious, where does it reach? The per-repository ranking cannot answer that without opening every repository in turn. The left column ranks every action riskiest-first, with unscored actions last — an action nobody has analysed is not the same as a safe one. Each row carries its grade, the refs seen across the org, and how many repositories use it. Filter it three ways, which matters once an organization is past a screenful:
  • the search box — matches the action name, any ref it is pinned at, and the names of the repositories that use it. Typing a repository name lists the actions it pulls in, which is the by-repository question asked from this end.
  • not SHA-pinned — only actions that at least one repository references by tag or branch.
  • unscored — only actions Pipefort has not analysed yet.
The repository ranking has the same search box, and it works the same way in reverse: type an action name to see which repositories depend on it. When a filter hides whatever was selected, the detail pane moves to the first row still showing rather than displaying something you can no longer see. The right column is the selected action:
  • Reach — how many repositories use it, how many references that is, and how many of those are pinned to a SHA.
  • Where it is used — one row per repository, each linking to its own page, with a chip per reference coloured by how it is pinned: green for a SHA, amber for a tag, red for a branch.
  • The deduction ledger — the same one the public action report shows, when the action has been scored.
The risk report link goes to Pipefort’s own page for the action, not to GitHub. The catalog stores an action’s owner and name but no repository URL, so a github.com/... link would be constructed rather than known — and would 404 for any action whose catalog row is incomplete.
The grade belongs to the action; the pin state belongs to the repository. The same commit can be referenced well or badly, which is why the pin chips are per repository and the grade above them is not. An A-grade action referenced by a mutable tag is still a way in.

​
Where the data comes from

The inventory is built from each repository’s most recent scan — it reflects your current state, not your history. A repo appears only once it has been scanned, so scan a repository first if you don’t see it. Rescanning a repo updates its contribution automatically. An action shows Pending analysis instead of a grade when Pipefort has seen it but hasn’t scored it yet. Scoring runs asynchronously and usually catches up within minutes.

​
Filtering and export

Search by action name, filter to a single repository, and sort by riskiest, most-used, or alphabetically. CSV and JSON export what’s currently on screen, filters included. CSV is one row per action with the repository list flattened into a cell — convenient for a spreadsheet or an audit. JSON keeps the per-repository drill-in nested, including each ref and its pin type.