Ben ik kwetsbaar? Waarom een eerlijk ja of nee zo lastig is
Bijgewerkt: 30 oktober 2026
Kort antwoord: van buiten krijg je per systeem een zekerheid, geen kale ja of nee. Of een systeem echt kwetsbaar is, hangt af van vier lagen: wat de versie zegt, of de weg naar het lek openstaat, waar de software draait en of het lek aan te tonen is. Een scan van buiten ziet een deel daarvan, je eigen team van binnen een ander deel. Samen geven ze het eerlijke antwoord.
Volg de stipjes: oranje is een verzoek dat bij jouw server aankomt, paars het antwoord, groen het terugbelverzoek naar onze eigen server.
Het begint met een advies
Het NCSC publiceert beveiligingsadviezen met een inschatting van kans en schade, en leveranciers melden hun eigen lekken. Bij een kritiek lek, zeker als het al actief wordt misbruikt, wil het SOC of de securityverantwoordelijke dezelfde dag weten welke systemen geraakt zijn. Dat klinkt als een vraag met een ja of nee. Toch zitten er vier lagen tussen het advies en het antwoord.
Lees in het advies eerst drie dingen:
- Wordt het lek al misbruikt? Staat het op de lijst van actief misbruikte kwetsbaarheden (KEV), dan heeft het voorrang. Je rapport vermeldt dat bij de bevinding.
- Is er een account nodig? Dat staat in de beschrijving of in de CVSS-vector. Bij
PR:Nzijn geen rechten nodig en is het lek van buiten te misbruiken. BijPR:LofPR:Hmoet een aanvaller eerst inloggen. - Welke versies zijn geraakt, en waar zit de fix? Daarmee vergelijk je straks wat er draait.
Laag 1: wat zegt de versie?
Veel diensten noemen in hun antwoord welke software en welke versie er draait: de banner. Ligt die versie onder de fix, dan is een lek waarschijnlijk. Twee dingen maken dat minder zeker dan het lijkt.
- Backports. Linux-distributies zoals Ubuntu, Debian en Red Hat zetten een fix vaak in het bestaande versienummer. Een bijgewerkte server ziet er van buiten dan hetzelfde uit als een kwetsbare. Voor een deel van de pakketten zoeken we zelf op of de distributie de fix al heeft: OpenSSH op Ubuntu en Debian, en PHP en Apache op Ubuntu. De fixversie staat dan in je rapport.
- Geen banner. Steeds meer diensten noemen geen versie. Dan weet je van buiten alleen dat de software draait.
Daarom zegt je rapport bij elke bevinding hoe zeker die is:
| Klasse | Wat het betekent |
|---|---|
| Bevestigd | Het lek zelf is aangetoond. |
| Waarschijnlijk | De versie staat onder de fix, en dat heeft de actieve scan zelf vastgesteld. |
| Mogelijk | De versie staat onder de fix, maar dat komt alleen uit openbare bronnen. |
| Blootgesteld | De software draait, maar de versie is van buiten niet vast te stellen. |
Laag 2: staat de deur open?
Een actieve scan kan voor een deel van de lekken veilig uitproberen of ze echt te misbruiken zijn. Zo'n test volgt één weg: één pad, één methode, zonder account. Krijgt hij een dichte deur, dan zegt het antwoord iets over die deur, en niets over het lek.
| Antwoord | Wat het betekent | Wat het niet betekent |
|---|---|---|
| 401 Unauthorized | Voor deze weg moet je inloggen. | Dat het lek er niet is. Veel lekken zitten achter de login en zijn zonder account niet te testen. |
| 403 Forbidden | Een filter, WAF of regel houdt dit verzoek tegen, soms alleen omdat het van een scanner komt. | Dat het lek weg is. Een filter beschermt deze ene weg, het lek zelf zit er nog. |
| 404 Not Found | Op dit pad staat het kwetsbare onderdeel niet. | Dat het nergens staat. Het kan op een ander pad, een andere poort of een andere hostnaam draaien. |
| 405 Method Not Allowed | Deze methode, bijvoorbeeld POST, wordt hier geweigerd. | Dat elke route naar het lek dicht is. |
Een dichte deur is wel degelijk winst: misbruik wordt er lastiger door. Maar het lek is pas weg na de fix. Daarom verandert een test zonder treffer niets aan je rapport. De bevinding blijft staan met de zekerheid die bij de versie hoort. Geen treffer is geen vrijspraak.
Is er volgens het advies een account nodig, of zit de dienst achter een login? Dan zegt een scan van buiten er weinig over. Controleer zo'n lek van binnen, met de versie op de server zelf of met een test waarbij wel wordt ingelogd.
Laag 3: waar draait de software?
Steeds meer applicaties draaien in een container. Een container brengt zijn eigen bibliotheken mee, los van het besturingssysteem van de server. Dat heeft gevolgen voor de vraag of je geraakt bent:
- Het besturingssysteem patchen is niet genoeg. Een lek in een bibliotheek in het image los je op door het image opnieuw te bouwen op een bijgewerkte basis en de container te vervangen.
- De kernel is wel gedeeld. Een container gebruikt de kernel van de server. Een lek in de kernel los je dus op de server zelf op.
- Van buiten zie je vaak de proxy. Staat er een reverse proxy of load balancer voor de app, dan hoort de banner die je van buiten ziet bij die proxy en niet bij de app erachter. De versie van de app zelf blijft dan onzichtbaar.
- Je inventaris ziet niet alles. Een inventarisagent op de server ziet de pakketten van het besturingssysteem, maar niet altijd wat er in de images zit. Laat die apart controleren, bijvoorbeeld in de pipeline die de images bouwt.
Laag 4: is het lek aan te tonen?
Bij een deel van de lekken kan een veilige test het lek zelf aantonen. Soms aan een herkenbaar antwoord, soms doordat een kwetsbaar systeem terugbelt naar onze eigen terugbelserver. Dat is bewijs, en in je rapport heet het Bevestigd. Hoe dat werkt, lees je in Terugbellen als bewijs.
Niet voor elk lek bestaat zo'n test. Lekken die alleen te bewijzen zijn door een systeem te laten vastlopen of door echt in te breken, proberen we niet uit. Dan blijft de versie de aanwijzing, en zegt je rapport eerlijk Waarschijnlijk of Mogelijk. Belt een systeem niet terug, dan beweren we niets.
Van buiten en van binnen: samen het antwoord
| Vraag | Van buiten (Exposure Watch) | Van binnen (je eigen team) |
|---|---|---|
| Wat is vanaf internet bereikbaar? | Elke host en dienst in je scan-scope | Wat in de inventaris staat, niet wat vergeten is |
| Welke versie draait er? | Wat de banner zegt, met een zekerheid | De exacte pakketversie |
| Zit de fix er al in? | Voor een deel van de Linux-pakketten | Ja, via de pakketbeheerder |
| Wat zit er in de containers? | Niet te zien | Met een controle van de images |
| Lekken achter de login? | Nee, we scannen zonder account | Met een account of een interne pentest |
| Is het lek aan te tonen? | Voor een deel van de lekken, met een veilige test | Met een pentest |
Van buiten zie je wat een aanvaller ziet, en dus waar je moet beginnen. Van binnen zie je wat er echt draait. Een advies is pas afgehandeld als beide kanten kloppen. Lees ook het verschil tussen een pentest en een scan.
Opgelost? Leg het vast in je rapport
Bevestigt je team dat een lek al is opgelost, bijvoorbeeld omdat de fixversie op de server staat of de leverancier de backport bevestigt? Markeer die CVE dan in je rapport als opgelost, met een korte notitie waarom. Dat kan per CVE of voor meerdere tegelijk. Verandert de software op die dienst, dan vervalt de markering vanzelf. Zo zegt je rapport nooit meer dan je weet, en schrijf je een leverancier niet aan over een lek dat al dicht is.
Zo pak je een nieuw advies aan
- Lees in het advies of het lek actief wordt misbruikt en of er een account voor nodig is.
- Kijk in je rapport welke systemen de software draaien en hoe zeker elke bevinding is. Begin bij Bevestigd, dan Waarschijnlijk.
- Controleer van binnen de exacte pakketversie, ook in je containers.
- Patch, bouw images opnieuw en vervang de containers. Zet tot die tijd waar het kan een filter voor de kwetsbare weg.
- Markeer wat aantoonbaar is opgelost, en laat een nieuwe scan zien wat er van buiten nog openstaat.
Weten welke van jouw systemen van buiten zichtbaar zijn, en hoe zeker elk lek is?
Begin met de gratis scan op de voorpagina: die is passief en stuurt niets naar je systemen. Of maak een gratis account, verifieer je domein en start een actieve scan.