- 34 GitHub Actions workflow checks parse
.github/workflows/*.yml(one,forbidden-uses, is driven by your.pipefort.ymlpolicy). - 7 online supply-chain audits verify the integrity of pinned actions (known-vulnerable, impostor-commit, ref/version-mismatch, typosquat, archived-action, stale-action-ref, ref-confusion) — run automatically when a GitHub token is available, forced with
--audit-pins, disabled with--offline. - 17 GitHub repository-configuration checks call the GitHub API for branch protection, default workflow permissions, secret scanning, and Dependabot.
- 11 GitLab CI workflow checks parse
.gitlab-ci.ymland.gitlab-ci/**/*.yml. - 5 GitLab project-configuration checks call the GitLab API for protected branches, merge policy, public-pipeline visibility, and approvals.
GitLab CI workflow checks
The GitLab rule IDs are parallel to the GitHub ones — same OWASP category, different IDs (e.g.cicd-sec-1-gl-mr-target for the merge-request-target
analog of cicd-sec-1-ppe-checkout). Findings tagged -gl- only fire on
.gitlab-ci.yml / .gitlab-ci/*.yml. The two structural rules
best-prac-1-pipe-to-shell and cicd-sec-9-download-without-checksum
share their ID across both platforms.
GitLab project-settings checks
These read the GitLab project configuration over the API (CLI:--git at a
GitLab host with --gitlab-token; the web app uses its connected GitLab token)
and surface under the Repository-configuration group.
The two auto-fixable settings (
merge-without-pipeline, public-pipelines) are
remediated by the CLI’s --fix-settings-gl flag.
v1 limitations
include:graph traversal is not performed — the scanner inspects only the literal.gitlab-ci.ymland.gitlab-ci/*.ymlcontents, not files referenced from another project or URL.- Approval-rule auditing (
cicd-sec-1-gl-no-approvals) needs the GitLab Premium approvals API; on Free tier it is skipped rather than firing.
Confidence and personas
Every finding carries a confidence (HIGH/MEDIUM/LOW) alongside its
severity: severity says how bad the issue would be, confidence says how sure
the check is that the finding is real. Deterministic checks (a missing
permissions: block either exists or doesn’t) are HIGH; heuristic ones
(typosquat edit distance, secret-name patterns) are MEDIUM. Filter with the
CLI’s --min-confidence flag; the web app badges medium/low-confidence
findings and offers a “High confidence only” toggle.
Rules are also tiered into personas for noise control: regular (the
default — high-signal security checks), pedantic (adds hygiene nits like
missing timeouts and job-level continue-on-error), and auditor (adds
everything, e.g. self-hosted-runner usage). Select with the CLI’s --persona
flag. The web app runs all tiers and relies on rule settings
for per-rule control.
Workflow file checks
Online pinned-action audits
These audit the integrity of pinned actions and need network access. They run automatically whenever a GitHub token is supplied —--github-token, $GITHUB_TOKEN, or $GH_TOKEN on the CLI, and the web app’s scan always runs them with its installation token. Without a token the scan stays offline unless you force the pass with --audit-pins (subject to GitHub’s low anonymous rate limit); --offline disables it unconditionally. Typosquat matching is itself offline but ships in the same pass.
Repository configuration checks
These read GitHub-side settings and surface under a “Repository configuration” group in the UI (CLI:<repository settings> file label). They need the expanded GitHub App permissions described in GitHub App permissions; the CLI needs --github-token (or $GITHUB_TOKEN, or gh auth token).
Branch protection (CICD-SEC-1)
Actions runtime (CICD-SEC-4, CICD-SEC-5)
Dependency hygiene (CICD-SEC-3)
Credential hygiene (CICD-SEC-6)
Auto-fix on repo-settings rules is powered by the CLI’s
--fix-settings flag and the web app’s per-finding Fix button — see Auto-fix.
Rulesets
The CLI’s--ruleset flag (and the web app’s ruleset selector) controls which checks contribute to the final list. Filtering is by framework membership, not by category prefix — see SLSA framework overview for a rule-by-rule mapping.
all(default) — every check listed above.owasp— every rule tagged with the OWASP framework.slsa— every rule tagged with any SLSA v1.2 framework (Build or Source).slsa-build-l1/slsa-build-l2/slsa-build-l3— rules for that specific Build level (and only that level — to find every rule a repo needs to satisfy L3, run withslsaand look at the heatmap).slsa-source-l2/slsa-source-l3/slsa-source-l4— rules for that specific Source level. (L1 is “Version Controlled” — trivially satisfied for any GitHub repo.)
Enabling and disabling individual rules
The web app lets you toggle any individual rule on or off without changing the ruleset — per user, with optional per-repository overrides. See Rule settings for the model and the UI. The CLI’s filtering is limited to the coarser--ruleset choice above; multi-tenant
preferences depend on the database and are web-only.
How the checks run
Each workflow check parses a workflow file and returns findings. The CLI and the web app run the exact same checks, so they always agree for the same file. Repository-configuration checks are a separate pass: Pipefort reads the relevant GitHub settings over the API and produces findings from them. These carry a synthetic file label (<repository settings>) with no line number, so they render apart from per-file findings.
See Auto-fix for which workflow categories the CLI’s --fix flag rewrites. Repository-configuration findings have no auto-fix — they’re flagged for manual remediation via GitHub’s UI.