Gestructureerd security review proces voor code publicatie

[CorneeldH]

Type: Pitch

Problem / Opportunity

Het OSOR Handbook (hoofdstuk 3.4) identificeert drie security-overwegingen specifiek voor organisaties die open source publiceren:

1. Security review vóór publicatie: gestructureerde controle dat code geen kwetsbaarheden of onbedoelde informatielekken bevat
2. Voorkomen van publicatie van interne data: scheiding van code en data, geen credentials/configuratie/paden in repositories
3. Beheer van bijdragen van derden: duidelijk proces voor review van externe contributions

CEDA publiceert al code op GitHub, maar zonder een gedocumenteerd security review proces. Naarmate meer repos actief worden en externe bijdragen toenemen (incubator-projecten, instellingen die PRs indienen), wordt dit een risico.

Dit is onderscheidend van issue #1 (geautomatiseerde tooling): deze issue gaat over het proces en de menselijke review die daaromheen nodig is.

Appetite

Small (1-2 dagen) — dit is voornamelijk documentatie en procesafspraken

Solution

Een security-review-checklist.md toevoegen aan de .github repo met:

1. Pre-publicatie checklist (bij nieuwe repos of eerste open source release):

• Geen hardcoded credentials, API keys, tokens, of wachtwoorden in code of git history
• Geen interne paden, hostnamen, of IP-adressen
• Geen gebruikersdata, testdata met echte persoonsgegevens, of database dumps
• Configuratiebestanden gebruiken environment variables of aparte (gitignored) config files
• .gitignore bevat patronen voor data bestanden, credentials, en IDE-specifieke bestanden
• Dependencies zijn up-to-date en bevatten geen bekende kwetsbaarheden (Dependabot/pip-audit, zie issue Verkeerde link op startpagina #1)
• Git history bevat geen gevoelige informatie (indien wel: history herschrijven vóór publicatie met git filter-repo)

2. Review protocol voor externe contributions:

• Elke externe PR wordt door minimaal één CEDA-teamlid gereviewd
• Review checkt naast functionaliteit ook: geen nieuwe dependencies met bekende kwetsbaarheden, geen credentials, geen onveilige patronen
• Bij contributions die security-gevoelige code raken (authenticatie, data ingestion, configuratie): twee reviewers

3. Periodieke security review:

• Kwartaallijkse scan van alle actieve repos tegen de pre-publicatie checklist
• Review van Dependabot alerts en actie op openstaande kwetsbaarheden
• Documentatie van bevindingen en genomen acties

4. Proces voor incubator-projecten:

• Voordat code van een incubator-project (instelling → CEDA) wordt opgenomen in de cedanl organisatie: doorlopen van de volledige pre-publicatie checklist
• Specifiek: git history van het instellingsproject controleren op credentials of persoonsgegevens
• Indien nodig: schone fork maken met opgeschoonde history

Acceptatiecriteria

• security-review-checklist.md aanwezig in .github repo
• Checklist geïntegreerd in PR template (verwijzing, niet volledige checklist)
• Afspraak over twee-reviewer vereiste voor security-gevoelige code
• Proces voor incubator-onboarding gedocumenteerd
• Eerste kwartaal-review ingepland

Risks / Rabbit holes

• Proces niet te bureaucratisch maken. Het moet lightweight genoeg zijn dat het daadwerkelijk wordt gevolgd.
• Niet verwarren met SDP security — dit gaat puur over de applicatiecode en git repositories, niet over de deployment-omgeving.

No-Gos

• Geen penetration testing of red-teaming — dat is een ander niveau van security review
• Geen formeel security audit rapport per repo — de checklist is voldoende voor de huidige schaal
• Geen externe security consultant inhuren in deze fase

Gevalideerd met

@CorneeldH, @Tomeriko96 (moet nog)

Sparring partner