OpenSSF Scorecard

The OpenSSF Scorecard is an industry-standard set of automated checks for security posture of an open-source repo. fremforge runs it against every repo in your org on a weekly schedule and surfaces the result as a column on /<org>/_admin/repos-overview.

The checks

Scorecard’s checks span build security, vulnerability hygiene, and project maturity. The headline ones:

• Branch-Protection — is the default branch protected with required reviews + status checks?
• Code-Review — what fraction of recent merges had a code review?
• Pinned-Dependencies — are CI dependencies pinned to specific versions / SHAs?
• Token-Permissions — does CI use least-privilege tokens?
• Signed-Releases — are release artifacts cryptographically signed?
• SAST — does the project run a static analyser in CI?
• Vulnerabilities — does the dependency tree contain known CVEs?
• Maintained — is the repo seeing recent commits / issues activity?

Each check returns a score 0–10. The overall score is the weighted average. A perfect 10 is rare; “good” is in the 7–9 range.

How fremforge runs it

Scorecard is not a per-repo CI workflow. It runs weekly on isolated platform infrastructure — no workflow file lands in your repos, and you don’t spend any runner minutes on it. The mechanism:

1. Once a week, fremforge enqueues each active tenant for a scan. Tenants with an in-flight run are skipped.
2. A scan is driven by a read-only, per-tenant bot that can read your repos but cannot write to them.
3. The scan lists the tenant’s repos and compares each repo’s current default-branch HEAD against the HEAD recorded for the last scan. Repos whose HEAD hasn’t moved are skipped — the score can’t have changed, so there’s nothing to recompute.
4. For each changed repo, the scan shallow-clones it into a transient working directory on isolated platform infrastructure, runs the scorecard --local binary against the local checkout, and stores the resulting score JSON (including the new HEAD reference).
5. Runs left stuck by a crashed worker are swept back to a failed state so the tenant is re-enqueued on the next weekly fire.

fremforge stores the result per (tenant, repo) and renders the overall score as a column on the Repos page (/<org>/_admin/repos-overview). Click a row to see per-check details.

The /scorecard/results ingest API still exists for any external or workflow-driven push, but it is no longer the default path — the weekly platform-side scan above is.

Interpreting the score

The score is a directional signal, not a compliance gate. A repo with a score of 6.5 that includes a maintained library with branch-protection and SAST is in much better shape than a repo with score 8 that just happens to score well on cosmetic checks.

We do not recommend wiring “Scorecard score < X” into any merge-blocking rule. The right place for that gate is:

• Branch-Protection failing → fix it on /<org>/_admin/repo-defaults/branch-protection (already a separate signal).
• SAST failing → check /<org>/_admin/code-security (already a separate signal).

Use Scorecard to look at the gap between similar repos: if acme/api scores 8.5 and acme/web scores 6.5, where’s the gap and is it intentional?

Where the scan runs — data-residency note

The scorecard binary itself is open-source (Apache-2.0). The scan runs on isolated, network-fenced fremforge platform infrastructure (T Cloud Public, eu-de) — not in your CI runners. It is driven by a read-only, per-tenant bot that can read your repos but cannot write to them.

What this means for your data:

• The clone is transient. The scan shallow-clones each changed repo into a transient working directory, runs scorecard --local against that local checkout, and deletes the working directory when the run finishes. The source is never persisted to durable storage and never leaves the platform to the public internet — the bot fetches from your tenant’s own Forgejo over the internal network, and the scorecard binary runs --local (no outbound calls to GitHub-style APIs for the checks we run).
• Only the check-result JSON is retained. What we store per (tenant, repo) is the per-check scores plus the scanned HEAD reference — no source code, no file contents, no commit snippets.
• It stays in eu-de. Both the clone and the scan execute inside the EU-resident platform, consistent with fremforge’s no-US-sub-processor posture.

This is a change from the earlier model, where scorecard ran as a workflow inside your own CI runners. The scan now runs on fremforge infrastructure; the residency and read-only-bot properties above are how we keep that boundary tight.

See also

• Branch protection — drives the Branch-Protection score.
• SBOMs — drives the Dependencies + Vulnerabilities scores.