OpenSSF Scorecard

De OpenSSF Scorecard is een gangbare set geautomatiseerde checks voor de beveiligingshouding van een opensourcerepository. fremforge draait hem wekelijks op elke repository in je organisatie en toont het resultaat als kolom op /<org>/_admin/repos-overview.

De checks

De checks van Scorecard bestrijken buildbeveiliging, de omgang met kwetsbaarheden en de volwassenheid van een project. De belangrijkste:

• Branch-Protection: is de standaardbranch beschermd met verplichte reviews en statuschecks?
• Code-Review: welk deel van de recente merges had een code review?
• Pinned-Dependencies: zijn de afhankelijkheden in CI vastgepind op specifieke versies of SHA’s?
• Token-Permissions: gebruikt CI tokens met zo min mogelijk rechten?
• Signed-Releases: zijn release-artefacten cryptografisch ondertekend?
• SAST: draait het project een statische analyser in CI?
• Vulnerabilities: bevat de afhankelijkheidsboom bekende CVE’s?
• Maintained: zijn er recente commits of activiteit in issues?

Elke check geeft een score van 0 tot 10. De totaalscore is het gewogen gemiddelde. Een perfecte 10 is zeldzaam; “goed” ligt tussen 7 en 9.

Hoe fremforge hem draait

Scorecard is geen CI-workflow per repository. Hij draait wekelijks op geïsoleerde platforminfrastructuur: er komt geen workflowbestand in je repository’s, en je verbruikt er geen runnerminuten voor. Zo werkt het:

1. Eén keer per week zet fremforge elke actieve tenant in de wachtrij voor een scan. Tenants met een lopende run worden overgeslagen.
2. Een scan wordt uitgevoerd door een alleen-lezen bot per tenant, die je repository’s kan lezen maar er niet naar kan schrijven.
3. De scan haalt de repository’s van de tenant op en vergelijkt per repository de huidige HEAD van de standaardbranch met de HEAD die bij de vorige scan is vastgelegd. Repository’s waarvan de HEAD niet is verschoven, worden overgeslagen: de score kan niet veranderd zijn, dus er valt niets opnieuw te berekenen.
4. Elke gewijzigde repository wordt ondiep gekloond naar een tijdelijke werkmap op geïsoleerde platforminfrastructuur, de binary scorecard --local draait op die lokale checkout, en de resulterende score-JSON wordt opgeslagen (met de nieuwe HEAD-referentie).
5. Runs die vastzitten door een gecrashte worker worden teruggezet naar mislukt, zodat de tenant bij de volgende wekelijkse ronde opnieuw in de wachtrij komt.

fremforge slaat het resultaat op per (tenant, repo) en toont de totaalscore als kolom op de pagina Repositories (/<org>/_admin/repos-overview). Klik op een rij voor de details per check.

De ingest-API /scorecard/results bestaat nog voor een externe of door een workflow aangestuurde push, maar is niet langer de standaardroute: dat is de wekelijkse scan op het platform hierboven.

De score interpreteren

De score is een richtinggevend signaal, geen compliance-poort. Een repository met een score van 6,5 die een onderhouden bibliotheek met branchbescherming en SAST bevat, staat er veel beter voor dan een repository met score 8 die toevallig goed scoort op cosmetische checks.

We raden het niet aan om “Scorecard-score < X” in een regel te verwerken die merges blokkeert. De juiste plek voor die poort is:

• Branch-Protection faalt → los het op via /<org>/_admin/security/policies/repository-rules#org-baseline (al een apart signaal).
• SAST faalt → kijk op /<org>/_admin/code-security (al een apart signaal).

Gebruik Scorecard om het verschil tussen vergelijkbare repository’s te bekijken: als acme/api 8,5 scoort en acme/web 6,5, waar zit dan het verschil, en is dat bewust?

Waar de scan draait: een opmerking over dataresidentie

De scorecard-binary zelf is open source (Apache-2.0). De scan draait op geïsoleerde, netwerkmatig afgeschermde platforminfrastructuur van fremforge (T Cloud Public, eu-de), niet op je CI-runners. Hij wordt uitgevoerd door een alleen-lezen bot per tenant, die je repository’s kan lezen maar er niet naar kan schrijven.

Wat dit betekent voor je gegevens:

• De kloon is tijdelijk. De scan kloont elke gewijzigde repository ondiep naar een tijdelijke werkmap, draait scorecard --local op die lokale checkout en verwijdert de werkmap als de run klaar is. De broncode wordt nooit in duurzame opslag bewaard en verlaat het platform nooit richting het publieke internet: de bot haalt hem op uit de eigen Forgejo van je tenant via het interne netwerk, en de scorecard-binary draait met --local (geen uitgaande aanroepen naar API’s in GitHub-stijl voor de checks die wij draaien).
• Alleen de JSON met checkresultaten wordt bewaard. Per (tenant, repo) slaan we de scores per check op plus de gescande HEAD-referentie: geen broncode, geen bestandsinhoud, geen fragmenten uit commits.
• Het blijft in eu-de. Zowel de kloon als de scan draaien binnen het platform in de EU, in lijn met het uitgangspunt van fremforge om geen Amerikaanse subverwerkers te gebruiken.

Dit is anders dan het eerdere model, waarin scorecard als workflow op je eigen CI-runners draaide. De scan draait nu op infrastructuur van fremforge; de eigenschappen hierboven, residentie en een alleen-lezen bot, houden die grens strak.

Zie ook

• Branchbescherming: bepaalt de score voor Branch-Protection.
• SBOM’s: bepalen de scores voor Dependencies en Vulnerabilities.