Skip to main content
The web app wraps the same scan engine the CLI uses, and adds the parts that don’t make sense in a one-shot binary:
  • Sign in with GitHub. Identity is established with a single GitHub sign-in.
  • Organizations. Repos, scans, findings, triage, and rule settings are shared per organization; invite teammates by email with admin/member roles. Every account starts with a personal organization.
  • Connect a GitHub account or organization. A separate GitHub App grants the API read-only access to repo workflows.
  • Continuous posture across every repo. One scan per repo, orchestrated client-side with bounded concurrency.
  • Monitored repos. Opt a repo in and every push to its default branch triggers an automatic scan via GitHub webhooks — no clicking required.
  • New-finding diffing & triage. Findings are tracked across scans by a stable fingerprint: see what’s NEW since the last scan, and dismiss / accept-risk / mark-false-positive findings so posture counts reflect real risk.
  • Slack notifications. When an automatic scan of a monitored repo finds new issues, get a message in your channel — quiet otherwise.
  • History and trends. Every scan is persisted and scoped to your organization, so posture is tracked over time.
  • Insights. How work moves: what arrived and left over a period, how long verdicts and fixes take, accepted-risk budget, and which rules are wasting attention.
  • Deep links back to GitHub. Each finding links to the exact file:line on the default branch.
  • Go anywhere with ⌘K. A command palette over every console destination, every repository and the whole rule catalog. ⌘K (or Ctrl+K) opens it; arrows move, Enter opens, Esc closes.

​
Pages

​
Finding your way

The top bar carries the trail: organisation / section / what you are looking at. The first two come from the URL. The third does not — only the page knows that /repositories/5eed0000-… is acme-corp/api-gateway — so pages publish it upward once they have loaded the record. Two rules keep the trail honest:
  • The record crumb is absent until it is known. While a page loads there is no third crumb — not a spinner, not the id from the URL. A trail reading “repositories / 5eed0000-…” claims a position in a hierarchy that the reader cannot use.
  • The section is only a link when something follows it. On a list page it is where you are, and linking it to itself teaches nothing. Behind a record it is where you came from, so it becomes the way back.
The left rail carries a count beside most destinations — open findings, repositories, distinct actions in use. Two of them are attention counts and render in rose rather than grey: toxic combinations, and remediation repos that failed or only partly succeeded. A badge is absent rather than zero while its data is loading, and absent if the request failed — a zero would be a claim (“nothing to see here”) that a failed request has not earned. Triage deliberately has no badge: its queue is exactly the open-findings set that Findings already counts. The same rule governs every headline figure in the console. Until a scan has actually run, the Overview’s open-findings total and its stat band read — rather than 0, and the page says whether you have no repositories yet or repositories nobody has scanned. Attacker Mind, Insights, SLSA and Triage behave the same way. A measured zero and an unmeasured one look identical on screen, and only one of them is good news. Past the rail, ⌘K searches three things at once: Identifiers match as a subsequence, so cscpe finds cicd-sec-1-ppe-checkout. Rule titles only match literally — running a subsequence matcher over a sentence matches almost everything, because prose has enough letters to spell most short queries by accident.

​
Data flow

No git clone happens — Pipefort pulls workflow YAML over the GitHub API and scans it directly, so your source code is never copied onto its servers.

​
Your data stays yours

Scans, findings, and settings are isolated per organization — you only ever see data belonging to organizations you’re a member of, even across a shared installation.

​
Next

GitHub setup

Connect a GitHub account or org so the dashboard can scan its workflows.

Rule policy

One ruleset across the org, with per-repository overrides and what each repo actually runs.

API reference

The HTTP endpoints under /api/* if you want to drive scans programmatically.