We vonden 35 kwetsbaarheden in onze eigen site

Wat we aantroffen

Op 4 augustus 2026 draaiden we een routinecontrole op deze website — de site die u nu leest. Eén commando, composer audit, dat de onderdelen waar de site op draait vergelijkt met een openbare lijst van bekende kwetsbaarheden.

De uitkomst: 35 bekende kwetsbaarheden, verdeeld over 13 onderdelen. Waaronder een lek waarmee iemand ongevraagd databasecommando's had kunnen laten uitvoeren, en een ander waarmee de verzendmodule van e-mail te misbruiken was.

Geen daarvan is door ons gemaakt. Het zijn allemaal onderdelen van anderen — bouwstenen die vrijwel elke moderne website gebruikt, gemaakt en onderhouden door open source-projecten. Precies daarom is dit geen verhaal over slordige code. Het is een verhaal over iets wat elke website heeft en bijna niemand controleert.

Waarom het er twee maanden stond

Dit is het deel dat ongemakkelijk is om op te schrijven.

Bij elke wijziging aan deze site draaien vier geautomatiseerde controles. Ze kijken of de code werkt, of hij consistent geschreven is, of er logische fouten in zitten en of alle tests slagen. Slaagt er één niet, dan gaat er niets naar productie. Dat systeem werkt en heeft ons vaak behoed voor domme fouten.

Geen van die vier keek naar de onderdelen waar onze code op leunt. Ze controleerden ons eigen werk, niet het fundament eronder.

Er was zelfs wél iets dat het gezien had. Een externe scan had de kwetsbaarheden gesignaleerd en er netjes een taak van gemaakt. Die taak bleef twee maanden staan terwijl er ondertussen gewoon doorgewerkt en uitgerold werd.

Daar zit de les die verder reikt dan software: een melding is geen controle. Iets wat waarschuwt maar niets tegenhoudt, verdwijnt in de stapel. Iets wat tegenhoudt, wordt opgelost.

Wat we eraan gedaan hebben

De eerste ronde loste 24 van de 35 kwetsbaarheden op. De patch daarvoor lag er al — dat was juist de taak die twee maanden had gewacht. Maar omdat hij zo lang had stilgelegen, was hij zelf ook achterhaald: in de tussentijd waren er elf nieuwe bijgekomen. Die zijn in een tweede ronde opgelost.

De uitkomst is nu nul. Maar de echte wijziging is een andere: diezelfde controle draait nu automatisch bij elke aanpassing, en hij blokkeert. Wordt er morgen een kwetsbaarheid ontdekt in een onderdeel dat wij gebruiken, dan gaat er niets meer live tot hij verholpen is.

Dat is ongemakkelijker in het dagelijks gebruik — een release kan nu stranden op iets dat een ander veroorzaakt heeft. Dat is precies de bedoeling.

Hoe u dit van uw eigen software weet

U hoeft hiervoor niet technisch te zijn. Deze vier vragen aan wie uw software onderhoudt leveren binnen een dag antwoord op:

• Wordt er automatisch gecontroleerd op bekende kwetsbaarheden in de onderdelen die we gebruiken? Voor de meeste platformen bestaat daar een standaardcommando voor dat in seconden draait. Het antwoord "we letten daarop" is geen ja.
• Blokkeert die controle een release, of maakt hij alleen een melding? Dit is de kern. Vraag door tot u het verschil hoort.
• Wanneer is het voor het laatst gedraaid, en wat kwam eruit? Een datum en een aantal. Bij ons was dat 4 augustus 2026 en 35.
• Hoe lang duurt het voordat een gemelde kwetsbaarheid verholpen is? Niet "snel". Een afspraak: kritiek binnen een week, de rest bij de eerstvolgende release.

Een leverancier die hier direct antwoord op geeft, heeft het geregeld. Eentje die uitwijkt naar "onze hosting doet dat" of "daar hebben we een firewall voor", beantwoordt een andere vraag. Een firewall beschermt de deur; dit gaat over wat er binnen op de plank ligt.

Waar deze controle niet over gaat

Eerlijk over de grenzen, want dit gereedschap is smaller dan het klinkt.

composer audit en zijn tegenhangers vergelijken alleen met een lijst van kwetsbaarheden die al ontdekt en gepubliceerd zijn. Ze zeggen niets over fouten in uw eigen maatwerk, niets over zwakke wachtwoorden, niets over een medewerker die op een phishingmail klikt, en niets over een lek dat nog niemand gevonden heeft.

Het is dus geen beveiligingsgarantie. Blijkt een onderdeel niet meer bij te werken, dan is dat trouwens het enige vervangingssignaal met een harde deadline. Verder is dit de goedkoopste, meest geautomatiseerde bodem die er bestaat — en juist daarom is het onverdedigbaar om hem niet te leggen. Wij hadden vier andere controles draaien en deze niet, en dat is precies hoe zoiets twee maanden onopgemerkt blijft.

Wat dit zegt over hoe wij werken

We hadden dit stuk ook kunnen schrijven zonder het eigen aandeel te noemen. Dan had er gestaan dat we beveiliging serieus nemen en dat we scannen op kwetsbaarheden — allebei waar, en allebei nietszeggend.

Dit is nuttiger: het commando is openbaar, de uitkomst is controleerbaar, en de fout was van ons. U kunt vandaag nog vragen wanneer het bij uw eigen software voor het laatst gedraaid is. Als het antwoord uitblijft, weet u genoeg — en dat weten is meer waard dan welke belofte over beveiliging dan ook.