Anker je codebase: zo houden Nederlandse dev-teams kwaadwillenden buiten de deur

Open-source is gebouwd op vertrouwen. Je gooit je code de wereld in, nodigt vreemden uit om bij te dragen, en hoopt dat het goed afloopt. Meestal doet het dat ook. Maar net als op zee geldt: wie niet uitkijkt, loopt vroeg of laat een kaper tegen het lijf.

De afgelopen jaren zijn er genoeg voorbeelden geweest van supply chain-aanvallen, kwaadaardige pull requests en gecompromitteerde npm-packages die duizenden projecten raakten. XZ Utils, event-stream, colors.js — de lijst is langer dan je zou willen. En nee, dit overkomt niet alleen grote projecten. Juist kleinere, actieve communities zijn aantrekkelijke doelwitten omdat ze minder capaciteit hebben om alles nauwlettend te volgen.

Maar security hoeft geen angstcultuur te worden. Met de juiste gewoontes en tools bescherm je je project zonder dat bijdragers het gevoel krijgen dat ze eerst door een douanecontrole moeten.

Begin bij de basis: toegangsbeheer is geen optie

De meest voor de hand liggende aanvalsvector is ook de meest verwaarloosde: wie heeft eigenlijk toegang tot wat? In veel Nederlandse dev-teams is dit organisch gegroeid — iemand krijgt schrijfrechten omdat ze een keer een handige fix indienden, en drie jaar later is niemand meer zeker of die persoon nog actief is.

Ga eens een middag zitten met je team en maak een eerlijke inventarisatie:

• Wie heeft maintainer- of admin-rechten in je repository?
• Zijn er bots of service accounts met te ruime permissies?
• Wanneer heb je voor het laatst inactieve contributors uit je toegangslijst verwijderd?

GitHub, GitLab en Forgejo bieden allemaal granulaire rolstructuren. Gebruik ze. Het principe van least privilege — geef iedereen alleen de rechten die ze écht nodig hebben — is niet alleen een enterprise-buzzword, het is gewoon gezond verstand.

Koppel dit aan verplichte two-factor authenticatie voor iedereen met merge-rechten. Dit is in 2024 geen discussie meer.

Branch protection: je laatste verdedigingslinie

Een open pull request-model is de levensader van open-source samenwerking. Maar zonder guardrails is het ook een uitnodiging voor ellende. Branch protection rules zijn de meest onderschatte security-maatregel die er bestaat.

Stel voor je main- of production-branch minimaal het volgende in:

• Vereis minimaal één reviewer voor elke merge — bij voorkeur iemand die de codebase goed kent
• Schakel force pushes uit zodat niemand de geschiedenis kan herschrijven
• Vereis dat CI-checks slagen voordat een PR gemerged kan worden
• Bescherm tags die gekoppeld zijn aan releases

Voor grotere projecten is het ook slim om codeowners in te stellen. Dat is een bestand in je repo dat aangeeft welke personen of teams automatisch als reviewer worden toegevoegd bij wijzigingen in specifieke bestanden of mappen. Zo vallen gevoelige onderdelen — denk aan authenticatielogica, betaalintegraties of configuratiebestanden — altijd onder de ogen van iemand die er verstand van heeft.

Dependency scanning: de zee onder je kiel in de gaten houden

Je eigen code is maar een deel van het verhaal. De meeste moderne applicaties bestaan voor een groot deel uit third-party packages, en elk van die packages is een potentieel risico. Dependabot, Renovate en Snyk zijn tools die dit automatisch bijhouden en je waarschuwen zodra een dependency een bekende kwetsbaarheid heeft.

Maar wees ook kritisch bij het toevoegen van nieuwe dependencies. Stel jezelf de volgende vragen:

• Hoe actief wordt dit package onderhouden?
• Hoeveel downloads heeft het, en wie staat erachter?
• Is de licentie compatibel met jouw project?
• Heeft het package zelf ook een dependency-auditproces?

Een handige vuistregel uit de Nederlandse developer-community: als een package je leven met drie regels code makkelijker maakt maar zelf vijftig dependencies meebrengt, is het de moeite waard om die drie regels zelf te schrijven.

Voeg ook een package-lock.json of equivalent toe aan je versiebeheer en pin dependencies op specifieke versies in productieomgevingen. Zo voorkom je dat een automatische update plotseling kwaadaardige code binnensluist.

Geheimen zijn geen geheimen als ze in je repo staan

Het klinkt absurd, maar het gebeurt elke week: API-sleutels, wachtwoorden en tokens die per ongeluk gecommit worden. GitHub heeft inmiddels een ingebouwde secret scanning-functie die dit probeert te onderscheppen, maar voorkomen is beter dan genezen.

Gebruik tools als git-secrets of gitleaks als pre-commit hook. Die scannen je commits lokaal voordat ze de repository bereiken. Combineer dit met een .env-bestand dat nooit in versiebeheer belandt (en ja, check je .gitignore nog een keer).

Voor teams die secrets delen, zijn tools als HashiCorp Vault, Doppler of de ingebouwde secrets-functionaliteit van GitHub Actions een stuk veiliger dan een gedeeld Google Doc of een Slack-berichtje.

Community-veiligheid zonder paranoia

Een gezonde open-source community is inclusief en toegankelijk. Te veel security-overhead schrikt bijdragers af en creëert een sfeer van wantrouwen. De kunst is om een balans te vinden.

Een paar praktische manieren om dat te doen:

Maak je security-beleid transparant. Een SECURITY.md-bestand in je root legt uit hoe mensen kwetsbaarheden kunnen melden, wat je verwacht van bijdragers, en hoe jij als maintainer reageert. Dit laat zien dat je security serieus neemt zonder dat je elke nieuwe contributor als verdachte behandelt.

Gebruik geautomatiseerde checks als eerste filter. Linter-regels, type checks en geautomatiseerde tests vangen een groot deel van de problemen op voordat een mens ernaar hoeft te kijken. Dit versnelt het reviewproces en vermindert de kans dat iets kwaadaardigs door de mazen glipt.

Bouw een cultuur van peer review. In Nederlandse dev-teams werkt dit vaak goed via een roulatiesysteem waarbij verschillende teamleden verantwoordelijk zijn voor reviews in een bepaalde week. Zo spreidt je de kennis en voorkom je dat security afhankelijk is van één persoon.

Reageer snel op meldingen. Als iemand een kwetsbaarheid meldt — via je SECURITY.md, een issue of een directe boodschap — reageer dan binnen 48 uur. Ook al heb je de fix nog niet, een snelle bevestiging laat zien dat je het serieus neemt en houdt de melder betrokken.

Audit logs en incident response: voor als het toch misgaat

Met de beste wil van de wereld kan het fout gaan. Zorg dat je weet wat er is gebeurd als dat moment komt. Schakel audit logging in op je platform, zodat je kunt zien wie wanneer wat heeft gewijzigd. GitHub Enterprise en GitLab hebben dit ingebouwd; voor zelfgehoste oplossingen zijn er plugins en middleware die dit afhandelen.

Stel ook — desnoods op papier — een eenvoudig incident response-plan op. Wie bel je als er een kwaadaardige commit door de reviews glipt? Hoe trek je snel een release terug? Hoe communiceer je naar je gebruikers? Het hoeft geen ISO-gecertificeerd document te zijn, maar even nadenken voordat de brand uitbreekt scheelt enorm in de stress op het moment zelf.

Varen met een goede bemanning

Security is uiteindelijk geen technisch probleem, het is een cultuurprobleem. De beste tools ter wereld helpen niet als je team ze niet gebruikt of als de sfeer in je community zo gespannen is dat niemand durft te melden wat ze zien.

Bouw aan een omgeving waar mensen zich veilig voelen om fouten te melden, waar reviews gezien worden als samenwerking en niet als controle, en waar security een gedeelde verantwoordelijkheid is in plaats van het probleem van één maintainer.

Dan hoef je niet bang te zijn voor kapers. Want je vaart met een crew die zelf de uitkijk houdt.