Kort gezegd: Pentest of kwetsbaarhedenscan is geen of-of-vraag, maar een vraag van volgorde. Een kwetsbaarhedenscan vindt geautomatiseerd bekende lekken en verkeerde configuraties, snel en goedkoop, maar met valse alarmen en blinde vlekken. Een penetratietest toetst gericht wat een aanvaller werkelijk zou kunnen bereiken. Een bug-bountyprogramma opent de toetsing voor externe onderzoekers en loont pas als scans en pentests routine zijn. Voor de meeste mkb-bedrijven is de volgorde: regelmatig scannen, bevindingen verhelpen, gericht laten testen, een meldpunt voor kwetsbaarheden inrichten.
Waarom de vraag na PHP2Shell opnieuw wordt gesteld
Wie na PHP2Shell zijn website met een online scanner controleert, kan verwarrende resultaten krijgen. Een scanner meldt mogelijk een kritiek lek, hoewel de hoster de patch heeft bevestigd. Een andere meldt niets, hoewel de server nog een oude PHP-versie gebruikt, omdat de versieaanduiding is verborgen.
De reden ligt in de werkwijze. Veel scanners leiden de kwetsbaarheid af uit de getoonde versie. Distributies installeren echter backports zonder het versienummer te wijzigen; volgens berichten toont bijvoorbeeld Ubuntu 24.04 na de update nog steeds 8.3.6. Waarom dat zo is, legt Waarom php -v na de update hetzelfde nummer toont uit. Het betrouwbare bewijs levert de pakket-changelog, zie PHP-versie en patchstatus juist controleren.
Dat is geen argument tegen scanners, maar voor het kennen van hun grenzen en het combineren met andere methoden.
Pentest of kwetsbaarhedenscan: de drie methoden vergeleken
| Criterium | Kwetsbaarhedenscan | Penetratietest | Bug bounty |
|---|---|---|---|
| Wie toetst? | Geautomatiseerd hulpmiddel | Opgedragen vakmensen | Externe onderzoekers, vaak via een platform |
| Wat wordt gevonden? | Bekende lekken, verouderde versies, verkeerde configuraties | Misbruikbare kwetsbaarheden, logicafouten, koppelingen | Wat onderzoekers vinden en melden, vaak ongebruikelijke zaken |
| Diepgang | Breed, maar oppervlakkig | Diep binnen de afgesproken omvang | Wisselend, afhankelijk van de deelnemers |
| Valse alarmen | Vaak | Zelden, bevindingen worden onderbouwd | Veel meldingen die moeten worden beoordeeld |
| Planbaarheid | Hoog, willekeurig herhaalbaar | Hoog, vaste periode en omvang | Laag, meldingen komen doorlopend binnen |
| Voorwaarden in het bedrijf | Iemand die resultaten beoordeelt | Afgestemde omvang, testomgeving of onderhoudsvenster | Volwassen proces voor beoordeling, herstel en beloning |
| Typische inzet | Doorlopend, bijv. maandelijks of na wijzigingen | Vóór de start, na grotere wijzigingen, regelmatig | Aanvullend bij volwassen, blootgestelde toepassingen |
Geen van de methoden vervangt de andere. De scan toont veel in korte tijd, de pentest toont wat werkelijk telt, en bug bounty vindt waaraan niemand heeft gedacht.
Bij scanners loont bovendien een tweede blik op de soort scan. Een scan van buitenaf ziet alleen wat elke bezoeker ziet en moet versies vaak uit antwoorden van de server raden. Een geauthenticeerde scan, waarbij het hulpmiddel met eigen inloggegevens de geïnstalleerde pakketten op de server uitleest, levert duidelijk betrouwbaardere resultaten, juist bij de werkelijke pakketstatus van PHP. Ze vereist echter dat u daarvoor een beperkte toegang inricht en goed beveiligt. Voor de afhankelijkheden van eigen PHP-toepassingen bestaan weer eigen controlemiddelen, zoals composer audit voor pakketten uit Composer.
De zinvolle volgorde voor het mkb
- Inventaris en scan: eerst weten welke websites en servers er zijn, dan regelmatig scannen. Bevindingen niet ongecontroleerd overnemen, maar beoordelen.
- Basis verhelpen: verouderde software, ontbrekende updates en duidelijke verkeerde configuraties wegnemen. Een pentest op niet-gepatchte systemen inzetten verspilt budget.
- Gerichte penetratietest: voor de belangrijkste toepassingen, zoals shop, klantportaal of koppelingen, met duidelijk afgesproken omvang en hertest.
- Codecontrole bij eigen ontwikkelingen: wie eigen PHP-toepassingen beheert, vult de test aan met een doorlichting van de broncode. Hoe dat verloopt, beschrijft Security-codereview voor PHP-projecten.
- Meldpunt voor kwetsbaarheden: een beleid voor hoe externen lekken kunnen melden, en een security.txt-bestand volgens RFC 9116 onder
/.well-known/security.txtmet contact en vervaldatum. - Bug bounty, als de basis zit: pas wanneer meldingen betrouwbaar worden beoordeeld en lekken vlot worden verholpen.
Om daar een duurzaam proces van te maken, loont een blik op Kwetsbaarhedenbeheer voor het mkb.
Wat geen van de methoden levert
Geen toetsmethode bewijst dat een systeem veilig is. Ze toont alleen wat op een tijdstip met bepaalde methoden is gevonden. Een schoon pentestverslag van het voorjaar zegt niets over een lek zoals PHP2Shell dat in oktober bekend wordt.
Evenmin beantwoorden scan of pentest de vraag of een server al is gecompromitteerd. Daarvoor is een sporenonderzoek op het systeem zelf nodig: processen, bestanden, cronjobs, accounts, verbindingen. Dat is een eigen taak met eigen methoden.
Laat alleen systemen toetsen waarvoor u bevoegd bent, en stem bij gehoste systemen vooraf de regels van de aanbieder af. Een penetratietest vraagt een schriftelijke opdracht met omvang, periode en contactpersonen.
Wanneer u geen externe test nodig hebt
Voor een eenvoudige bedrijfswebsite zonder formulieren met gevoelige gegevens, bij een hoster die updates betrouwbaar installeert, volstaat vaak een regelmatige scan met kritische beoordeling van de resultaten. Een penetratietest zou hier meestal onevenredig zijn. Belangrijker zijn actuele software, sterke toegangen en back-ups.
Een externe test loont bij shops, portalen, eigen ontwikkelingen, koppelingen met interne systemen en overal waar klanten of normen een onafhankelijk bewijs verlangen.
Hoe helpt PHP SOS concreet?
- Wij richten regelmatige scans in en beoordelen de resultaten, inclusief de valse alarmen door backports.
- Wij helpen de basis te verhelpen voordat er geld naar een pentest gaat.
- Samen met gespecialiseerde partners voeren wij beveiligingsaudits en penetratietests uit met afgestemde omvang en hertest.
- Wij ondersteunen bij de opbouw van een meldpunt voor kwetsbaarheden en een security.txt.
Conclusie
Scan, pentest en bug bounty zijn trappen, geen concurrenten. Wie met regelmatige scans begint, de basis verhelpt en dan gericht laat testen, krijgt voor zijn budget de meeste veiligheid. Bug bounty is de kroon voor organisaties van wie de plicht al zit.
Veelgestelde vragen
Wat is het verschil tussen pentest en kwetsbaarhedenscan?
Een kwetsbaarhedenscan controleert geautomatiseerd of bekende lekken of verkeerde configuraties herkenbaar zijn. Een penetratietest gaat verder: vakmensen proberen binnen een afgesproken kader kwetsbaarheden daadwerkelijk te misbruiken en te koppelen, en beoordelen de gevolgen.
Stelt een scanner vast of mijn server tegen PHP2Shell is gepatcht?
Slechts beperkt. Veel scanners lezen de getoonde PHP-versie uit. Installeert de distributie een backport, dan blijft het nummer vaak gelijk en meldt de scanner een lek dat allang is gedicht. Omgekeerd kan een nieuw nummer worden getoond terwijl oude processen nog draaien.
Is een bug-bountyprogramma iets voor kleine bedrijven?
Meestal nog niet. Bug bounty veronderstelt dat meldingen snel worden beoordeeld en lekken vlot worden verholpen. Een goede instap is een eenvoudig beleid voor het melden van kwetsbaarheden met een security.txt-bestand.
Mag ik mijn website zelf met een scanner controleren?
Uw eigen systemen in de regel wel, als u daartoe bevoegd bent. Staat de website bij een hoster, stem dan vooraf af of scans zijn toegestaan of moeten worden aangekondigd. Vreemde systemen toetst u alleen met schriftelijke toestemming van de beheerder.
Hoe vaak moet een pentest plaatsvinden?
Een vaste regel bestaat niet. Gebruikelijk is een test vóór de start van een nieuwe toepassing, na grotere wijzigingen en met regelmatige tussenpozen die uw risico en eventueel eisen van klanten of normen bepalen.