CI/CD security tooling: OpenSSF Scorecard, SAST, dependency scanning en SBOM

[CorneeldH]

Type: Pitch

Problem / Opportunity

CEDA publiceert open source code die door onderwijsinstellingen in productie wordt gebruikt. Op dit moment ontbreekt geautomatiseerde security tooling in de CI/CD pipeline. Het SURF Developer Platform (SDP) dekt de infrastructuur en omgeving, maar niet de applicatiecode zelf — dependency kwetsbaarheden, hardcoded secrets, en onveilige codepatronen worden nu niet systematisch gedetecteerd.

Het OSOR Handbook (EC, januari 2026) benadrukt dat open source projecten in de publieke sector gestructureerde security reviews en tooling nodig hebben. De OpenSSF Scorecard wordt specifiek genoemd als manier om security-gezondheid meetbaar te maken. Daarnaast wordt dit relevant in het kader van NIS2 supply chain security eisen.

Appetite

Medium (3-4 dagen) — meeste tools zijn plug-and-play GitHub Actions

Solution

Vier tools toevoegen als GitHub Actions workflows op organisatieniveau (via .github repo):

1. OpenSSF Scorecard

• GitHub Action: ossf/scorecard-action
• Scoort repos automatisch op branch protection, dependency updates, CI tests, code review, etc.
• Resultaat als badge op README — geeft instellingen direct vertrouwen
• Wekelijkse run + bij release

2. Static Analysis (SAST)

• Python: bandit — detecteert hardcoded credentials, onveilige deserialisatie, SQL injection patterns
• Toevoegen als stap in CI workflow, blokkert PR bij high-severity findings
• Voor R: lintr dekt een deel; voor security-specifieke checks is handmatige review voorlopig voldoende

3. Dependency scanning

• Dependabot aanzetten op organisatieniveau (GitHub-native, geen extra config nodig)
• Aanvullend: pip-audit in CI voor Python — checkt dependencies tegen bekende CVE's
• Dependabot maakt automatisch PRs voor kwetsbare dependencies

4. SBOM generatie

• Tool: cyclonedx-bom (Python) of syft (taal-agnostisch)
• Genereert volledige dependency tree in CycloneDX of SPDX formaat vanuit pyproject.toml / installed environment
• Als CI-stap bij elke release: SBOM als build artefact bijvoegen
• Relevant voor Cyber Resilience Act compliance en NIS2 supply chain transparantie

Acceptatiecriteria

• OpenSSF Scorecard draait wekelijks op minimaal de actieve repos (instroomprognose, uitval)
• Scorecard badge zichtbaar op repo README's
• bandit draait in CI op alle Python repos, blokkeert bij high-severity
• Dependabot is actief op organisatieniveau
• pip-audit draait in CI naast Dependabot
• SBOM wordt automatisch gegenereerd bij releases (CycloneDX of SPDX formaat)
• Secret scanning is actief op organisatieniveau (GitHub-native)
• detect-secrets of gitleaks als pre-commit hook gedocumenteerd in contributing guide

Risks / Rabbit holes

• Niet proberen alles in één keer perfect te maken. Start met Dependabot + bandit (laagste effort, hoogste waarde), daarna Scorecard, dan SBOM.
• R-ecosysteem heeft minder mature security tooling — accepteer dat en focus op Python eerst.
• SBOM-formaat keuze (CycloneDX vs SPDX) niet te lang over delibereren — beide zijn geaccepteerd, kies er één.

No-Gos

• Geen custom security tooling bouwen
• Geen security tooling voor de SDP-omgeving (dat is SURF's verantwoordelijkheid)
• Geen blokkerende CI checks op bestaande code in eerste iteratie — eerst baseline meten, dan thresholds instellen

Gevalideerd met

@CorneeldH, @Tomeriko96 (moet nog)

Sparring partner