Skip to main content
The app.pipefort.com/slsa page scores every connected repository against SLSA v1.2. Build-track results come from the workflow YAML scan; Source-track results come from the repository-settings audit (branch protection, required reviews, etc.).

​
Page structure

  1. Head — the level distribution for each track (one stacked bar per track, showing how many repos sit at each level), plus three figures: Controls passing across every repo and both tracks, At target (repos at Build L3), and Regressed — repos whose level is lower than it used to be, on either track. See How a regression is dated.
  2. Ladder — every repository, weakest first, with each track’s level badge and a completion bar per level. Repos that have never been scanned sort to the top with a red tint: an unknown level is missing evidence, not a pass. A repo carries a note when it is at target, has regressed, or has no scan.
  3. Highest-leverage gaps — the controls blocking the most repositories from their next level, ranked by repos unblocked, each marked auto-fix or manual. A control failing two levels above where a repo stands is not listed, because fixing it moves nothing.
  4. Controls grid — rows are SLSA controls grouped by level, columns are repositories. Cells show pass / fail / not scanned for that (repo, rule) pair and link to the repo’s detail page. Switch tracks with build / source at the top of the panel.

​
”Scan all” button

Top-right of the page. Runs a scan across every repository with ruleset=slsa — only SLSA-tagged rules contribute to the resulting findings. The default ruleset for ad-hoc scans elsewhere in the app is still all; this view is the only place that defaults to slsa.

​
Level computation

A repository “passes” SLSA Build level L when no enabled SLSA-Build rule tagged for level L (or below) has fired. The Source track works the same way.
  • A scan that has never run shows the repo at Build L0 / Source L1 (Source L1 is “Version Controlled” — trivially satisfied by any GitHub repository).
  • An L2 finding drops the Build level to L1; an L1 finding drops it to L0. Build levels rise from there as more rules pass.
  • Source L4 (“Two-Party Review”) needs the GitHub App’s extended permissions enabled. If the settings audit is skipped (e.g. missing scopes), the repo shows at Source L1.

​
How a regression is dated

A repository that has fallen carries a note reading, for example, build L2 → L1 · Aug 11. The date is the day the finding that holds the level down first appeared — not the day of the scan that noticed it. Three rules govern when the console will say a level regressed:
  • A level is capped by a tier, not by a rule. If two rules are tagged for the same level and both fire, the level only recovers when both are fixed — so the fall is dated from the earlier of the two, and the level it fell from is the one implied by the next failing tier up, not the track’s ceiling.
  • The repository must have been scanned before the finding appeared. On a first scan everything appears at once, and none of it is a fall.
  • A level that cannot be dated is not reported. If any finding holding the level down has no recorded appearance — it predates the transition log — the note and the Regressed count both leave it out rather than guess.
Because the date comes from the transition log rather than a comparison of the last two scans, a level that fell months ago and has been steady since is still reported, and still carries the day it actually fell.

​
Filtering by level

The Rule Settings page lets you disable any individual rule globally or per repo. The SLSA dashboard respects those toggles — a disabled rule never counts as a fail.