Kort sagt: Pentest eller sårbarhetsskanning är ingen antingen–eller-fråga utan en fråga om ordningsföljd. En sårbarhetsskanning hittar automatiserat kända luckor och felkonfigurationer, snabbt och billigt, men med falsklarm och blinda fläckar. Ett penetrationstest prövar riktat vad en angripare faktiskt kunde uppnå. Ett bug bounty-program öppnar granskningen för externa forskare och lönar sig först när skanningar och pentest hör till rutinen. För de flesta SMF är ordningen: skanna regelbundet, åtgärda fynden, låt testa riktat, inrätta en rapporteringspunkt för sårbarheter.
Varför frågan ställs på nytt efter PHP2Shell
Den som efter PHP2Shell granskar sin webbplats med en onlineskanner kan få förvirrande resultat. En skanner rapporterar kanske en kritisk lucka trots att hostingleverantören har bekräftat patchen. En annan rapporterar ingenting fast servern fortfarande använder en gammal PHP-version, eftersom versionsuppgiften är dold.
Orsaken ligger i arbetssättet. Många skannrar härleder sårbarheten ur den visade versionen. Distributioner installerar dock backporter utan att ändra versionsnumret; enligt rapporter visar till exempel Ubuntu 24.04 efter uppdateringen fortfarande 8.3.6. Varför det är så förklarar Varför php -v visar samma nummer efter uppdateringen. Det pålitliga beviset ger paketets changelog, se Kontrollera PHP-version och patchstatus på rätt sätt.
Det är inget argument mot skannrar utan ett för att känna till deras gränser och kombinera dem med andra metoder.
Pentest eller sårbarhetsskanning: de tre metoderna i jämförelse
| Kriterium | Sårbarhetsskanning | Penetrationstest | Bug bounty |
|---|---|---|---|
| Vem granskar? | Automatiserat verktyg | Anlitade fackfolk | Externa forskare, ofta via en plattform |
| Vad hittas? | Kända luckor, föråldrade versioner, felkonfigurationer | Utnyttjbara sårbarheter, logikfel, kedjor | Det forskare hittar och rapporterar, ofta något ovanligt |
| Djup | Bred men ytlig | Djup inom den överenskomna omfattningen | Varierande, beroende på deltagare |
| Falsklarm | Vanliga | Sällsynta, fynden beläggs | Många rapporter som måste bedömas |
| Planerbarhet | Hög, kan upprepas fritt | Hög, fast tidsperiod och omfattning | Låg, rapporter kommer löpande |
| Förutsättningar i företaget | Någon som bedömer resultaten | Avstämd omfattning, testmiljö eller underhållsfönster | Mogen process för bedömning, åtgärd och belöning |
| Typisk användning | Löpande, till exempel månatligen eller efter ändringar | Före start, efter större ändringar, regelbundet | Som komplement vid mogna, exponerade applikationer |
Ingen av metoderna ersätter de andra. Skanningen visar mycket på kort tid, pentestet visar vad som verkligen räknas och bug bounty hittar det som ingen har tänkt på.
Vid skannrar lönar det sig dessutom att titta närmare på typen av skanning. En skanning utifrån ser bara det som varje besökare ser och måste ofta gissa versioner utifrån serverns svar. En autentiserad skanning, där verktyget med egna inloggningsuppgifter läser av de installerade paketen på servern, ger betydligt tillförlitligare resultat, särskilt för PHP:s faktiska paketstatus. Den förutsätter dock att ni inrättar en begränsad åtkomst för det och skyddar den väl. För beroendena i egna PHP-applikationer finns i sin tur egna granskningsverktyg, till exempel composer audit för paket från Composer.
Den rimliga ordningen för SMF
- Förteckning och skanning: Först veta vilka webbplatser och servrar som finns, sedan skanna regelbundet. Ta inte över fynd ogranskade utan bedöm dem.
- Åtgärda grunderna: Undanröj föråldrad programvara, saknade uppdateringar och uppenbara felkonfigurationer. Att sätta ett pentest på opatchade system slösar budget.
- Riktat penetrationstest: För de viktigaste applikationerna, till exempel webbshop, kundportal eller gränssnitt, med tydligt överenskommen omfattning och eftertest.
- Kodgranskning vid egenutveckling: Den som driver egna PHP-applikationer kompletterar testet med en genomgång av källkoden. Hur det går till beskriver Säkerhetskodgranskning för PHP-projekt.
- Rapporteringspunkt för sårbarheter: En policy för hur externa kan rapportera luckor och en security.txt-fil enligt RFC 9116 under
/.well-known/security.txtmed kontakt och utgångsdatum. - Bug bounty när grunderna sitter: Först när rapporter bedöms pålitligt och luckor åtgärdas i god tid.
För att detta ska bli ett varaktigt förlopp lönar det sig att titta på Sårbarhetshantering för medelstora företag.
Vad ingen av metoderna klarar
Ingen granskningsmetod bevisar att ett system är säkert. Den visar bara vad som hittades vid en viss tidpunkt med vissa metoder. En ren pentestrapport från våren säger ingenting om en lucka som PHP2Shell, som blir känd i oktober.
Lika lite besvarar skanning eller pentest frågan om en server redan är komprometterad. För det krävs en spårsökning på själva systemet: processer, filer, cronjobb, konton, anslutningar. Det är en egen uppgift med egna metoder.
Låt bara granska system som ni är behöriga till och klargör vid hostade system leverantörens regler i förväg. Ett penetrationstest kräver ett skriftligt uppdrag med omfattning, tidsperiod och kontaktpersoner.
När ni inte behöver något externt test
För en enkel företagswebbplats utan formulär med känsliga data, hos en hostingleverantör som installerar uppdateringar pålitligt, räcker ofta en regelbunden skanning med kritisk bedömning av resultaten. Ett penetrationstest vore här oftast oproportionerligt. Viktigare är aktuell programvara, starka åtkomster och säkerhetskopior.
Ett externt test lönar sig för webbshoppar, portaler, egenutvecklingar, gränssnitt mot interna system och överallt där kunder eller standarder kräver ett oberoende underlag.
Hur hjälper PHP SOS konkret?
- Vi inrättar regelbundna skanningar och bedömer resultaten, inklusive falsklarm på grund av backporter.
- Vi hjälper till att åtgärda grunderna innan pengar går åt till ett pentest.
- Tillsammans med specialiserade partner genomför vi säkerhetsrevisioner och penetrationstester med avstämd omfattning och eftertest.
- Vi stöder uppbyggnaden av en rapporteringspunkt för sårbarheter och en security.txt.
Slutsats
Skanning, pentest och bug bounty är trappsteg, inga konkurrenter. Den som börjar med regelbundna skanningar, åtgärdar grunderna och därefter låter testa riktat får mest säkerhet för sin budget. Bug bounty är kronan på verket för organisationer vars plikt redan sitter.
Vanliga frågor
Vad är skillnaden mellan pentest och sårbarhetsskanning?
En sårbarhetsskanning kontrollerar automatiserat om kända luckor eller felkonfigurationer är synliga. Ett penetrationstest går längre: Fackfolk försöker inom en överenskommen ram faktiskt utnyttja och kedja samman sårbarheter och bedömer följderna.
Visar en skanner om min server är patchad mot PHP2Shell?
Bara begränsat. Många skannrar läser av den visade PHP-versionen. Installerar distributionen en backport förblir numret ofta detsamma, och skannern rapporterar en lucka som för länge sedan är stängd. Omvänt kan ett nytt nummer visas medan gamla processer fortfarande körs.
Är ett bug bounty-program något för små företag?
Oftast ännu inte. Bug bounty förutsätter att rapporter bedöms snabbt och att luckor åtgärdas i god tid. En bra början är en enkel policy för rapportering av sårbarheter med en security.txt-fil.
Får jag själv granska min webbplats med en skanner?
Era egna system som regel ja, om ni är behöriga till det. Ligger webbplatsen hos en hostingleverantör, klargör i förväg om skanningar är tillåtna eller ska aviseras. Främmande system granskar ni bara med skriftligt tillstånd från driftansvarig.
Hur ofta bör ett pentest göras?
Någon fast regel finns inte. Vanligt är ett test före start av en ny applikation, efter större ändringar och med regelbundna intervall som bestäms av er risk och i förekommande fall krav från kunder eller standarder.