Pentest vs sårbarhetsscanning – så väljer du rätt metod
Group COO & CISO
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
Pentest vs sårbarhetsscanning – så väljer du rätt metod
Penetrationstest och sårbarhetsscanning är inte utbytbara – de löser fundamentalt olika problem. Sårbarhetsscanning är en automatiserad process som identifierar kända svagheter i bredd, medan penetrationstest är en manuell, målinriktad insats där en säkerhetsexpert simulerar en verklig attack. Organisationer som bara använder den ena metoden har en blind fläck i sitt säkerhetsarbete. Den här artikeln förklarar skillnaderna i syfte, metodik, kostnad och regelverk – och hur du kombinerar dem för faktisk motståndskraft.
Viktiga slutsatser
- Sårbarhetsscanning är automatiserad och ger bredd – pentest är manuellt och ger djup
- En mogen säkerhetsstrategi kräver båda metoderna, inte en av dem
- NIS2 och GDPR ställer krav som i praktiken förutsätter regelbunden testning av båda typerna
- Sårbarhetsscanning bör köras kontinuerligt, pentest minst årligen eller vid större förändringar
- Automatiserade scanners hittar kända sårbarheter – pentestare hittar logikfel och attackkedjor som verktyg missar
Vad är sårbarhetsscanning?
Sårbarhetsscanning (vulnerability scanning) är en automatiserad process där specialiserade verktyg systematiskt genomsöker nätverksenheter, servrar, applikationer och molnresurser efter kända säkerhetsproblem. Verktygen – exempelvis Qualys, Nessus eller Rapid7 InsightVM – jämför konfigurationer och programvaruversioner mot databaser med tiotusentals kända sårbarheter (CVE:er).
Processen är snabb. En fullständig scanning av ett medelstort företagsnätverk kan slutföras på timmar. Det gör det möjligt att köra scanningar veckovis eller till och med dagligen, vilket ger löpande insyn i säkerhetsläget.
Vad scanning är bra på:
- Hitta saknade säkerhetsuppdateringar och patchar
- Identifiera felkonfigurationer (öppna portar, standardlösenord, TLS-problem)
- Ge en bred överblick av hela attackytan
- Prioritera åtgärder baserat på CVSS-poäng
Vad scanning inte gör:
- Verifierar inte om en sårbarhet faktiskt går att exploatera i er specifika miljö
- Hittar inte logikfel i applikationer (exempelvis felaktig behörighetshantering)
- Kan inte kedja ihop flera lågrisk-sårbarheter till en kritisk attackväg
- Genererar falskt positiva resultat som kräver manuell granskning
Från Opsios SOC ser vi regelbundet att organisationer litar blint på scannerrapporter utan att förstå kontexten. En sårbarhet med CVSS 9.8 i ett system som bara är nåbart från ett isolerat VLAN är inte samma sak som en CVSS 6.5 i en internetexponerad applikation. Prioritering kräver mänsklig bedömning.
Vill ni ha expertstöd med pentest vs sårbarhetsscanning – så väljer du rätt metod?
Våra molnarkitekter hjälper er med pentest vs sårbarhetsscanning – så väljer du rätt metod — från strategi till implementation. Boka ett kostnadsfritt 30-minuters rådgivningssamtal utan förpliktelse.
Vad är penetrationstest?
Penetrationstest (pentest) är en kontrollerad, manuell attack mot era system – utförd av erfarna säkerhetsexperter, ofta kallade etiska hackare. Målet är att ta reda på vad en verklig angripare faktiskt kan åstadkomma, inte bara vilka sårbarheter som teoretiskt existerar.
En pentestare arbetar metodiskt: rekognosering, identifiering av attackytor, exploatering av sårbarheter och – avgörande – eskalering. Det är i eskaleringsfasen som verkligt värde uppstår: kan en initial fotfäste i en webbapplikation leda till åtkomst till databaser, interna system eller domänadministratörsrättigheter?
Typer av penetrationstest:
| Typ | Beskrivning | Typiskt användningsfall |
|---|---|---|
| Black box | Testaren har ingen förhandsinformation om miljön | Simulerar extern angripare utan insiderskunskap |
| Grey box | Testaren har begränsad information (t.ex. användaruppgifter) | Simulerar komprometterad medarbetare eller partnertillgång |
| White box | Testaren har fullständig åtkomst till källkod och arkitekturdokumentation | Djupgående kodgranskning och arkitekturanalys |
| Red team | Fullskalig attack-simulering med social engineering, fysisk åtkomst m.m. | Testar organisationens samlade försvarsförmåga |
Pentest tar tid – från ett par dagar för en avgränsad webbapplikation till flera veckor för en komplex företagsmiljö. Resultatet är inte en lista med CVE:er utan en narrativ rapport som beskriver attackvägar, konsekvenser och prioriterade åtgärder.
Grundläggande skillnader i praktiken
Den enklaste sammanfattningen: scanning berättar vad som _kan_ vara fel, pentest visar vad en angripare _faktiskt kan göra_.
| Aspekt | Sårbarhetsscanning | Penetrationstest |
|---|---|---|
| Metod | Automatiserad, verktygsdriven | Manuell, expertdriven |
| Syfte | Identifiera kända sårbarheter | Verifiera exploaterbarhet och konsekvenser |
| Frekvens | Kontinuerligt / veckovis / månadsvis | Årligen eller vid större förändringar |
| Tidsåtgång | Timmar | Dagar till veckor |
| Kostnad | Låg till måttlig (verktygslicens + drift) | Betydande (specialistkompetens) |
| Falskt positiva | Vanligt förekommande | Sällsynt – fynd verifieras manuellt |
| Komplexitet i fynd | Enskilda sårbarheter | Attackkedjor och logikfel |
| Krav på kompetens | Drift/säkerhetsteam kan hantera | Kräver specialiserade pentestare |
| Rapportformat | Automatgenererad lista med prioritering | Narrativ rapport med kontext och rekommendationer |
Ett konkret exempel
Tänk er en e-handelsplattform. Sårbarhetsscannern hittar att Apache-versionen är utdaterad (CVE med känd exploit) och att TLS 1.0 fortfarande är aktiverat. Bra fynd – patcha och avaktivera.
Men pentestaren hittar något annat: genom att kombinera en IDOR-sårbarhet (Insecure Direct Object Reference) i order-API:t med en felkonfigurerad JWT-validering kan en autentiserad användare läsa andra kunders orderhistorik inklusive personuppgifter. Inget av detta dyker upp i en automatiserad scanning. Det kräver en människa som förstår applikationslogik.
Det är exakt den typen av fynd som gör skillnaden mellan ett dataintrång och en åtgärdad sårbarhet.
Regelverk och efterlevnad
NIS2-direktivet
NIS2, som trädde i kraft i EU under 2024–2025, ställer skärpta krav på riskhantering och incidentrapportering för väsentliga och viktiga entiteter. Direktivet nämner uttryckligen "testning och revision av säkerheten" som en del av de tekniska åtgärder organisationer ska vidta. I praktiken innebär det att både regelbunden sårbarhetsscanning och periodisk penetrationstestning förväntas – inte som engångsinsatser utan som integrerade delar av säkerhetsarbetet.
GDPR och IMY
GDPR artikel 32 kräver "förfaranden för att regelbundet testa, undersöka och utvärdera effektiviteten hos de tekniska och organisatoriska åtgärder som ska säkerställa behandlingens säkerhet." Integritetsskyddsmyndigheten (IMY) har i flera tillsynsbeslut påpekat bristande säkerhetstestning som en faktor vid sanktionsavgifter. Att inte testa är inte längre en fråga om ambitionsnivå – det är en regelverksfråga.
PCI DSS
PCI DSS är det regelverk som är mest explicit: kvartalsvis extern och intern sårbarhetsscanning (ASV-scanning) samt årligt penetrationstest krävs för organisationer som hanterar kortdata. Molnsäkerhet
SOC 2 och ISO 27001
Båda ramverken kräver att organisationer demonstrerar kontinuerlig säkerhetstestning. SOC 2 Trust Services Criteria och ISO/IEC 27001 Annex A (kontroll A.8.8) pekar specifikt på sårbarhetshanteringsprocesser.
Hur du kombinerar metoderna effektivt
Frågan "pentest eller scanning?" är felställd. Svaret är alltid båda – men med rätt timing och prioritering.
En praktisk modell
Kontinuerligt (veckovis–månadsvis):
- Automatiserad sårbarhetsscanning av hela infrastrukturen
- Integration med SIEM/SOAR för automatisk prioritering
- Patchhanteringsprocess kopplad till scannerresultat
Kvartalsvis:
- Riktad scanning av internetexponerade system
- Granskning av scannerresultat i relation till hotbilden
- Validering av att tidigare identifierade sårbarheter är åtgärdade
Årligen (minst):
- Fullständigt penetrationstest av kritiska system
- Externt pentest av internetexponerad yta
- Internt pentest med utgångspunkt i komprometterad klientmaskin
Vid förändring:
- Pentest före lansering av ny applikation eller större release
- Scanning efter infrastrukturförändringar (ny molnmiljö, nätverksförändring)
- Red team-övning vid betydande organisatorisk förändring
Opsios perspektiv
I vår SOC/NOC i Karlstad och Bangalore ser vi dagligen resultaten av både scanning och pentest. Det vanligaste felet vi stöter på är organisationer som kör scanning regelbundet men aldrig agerar på resultaten – eller som beställer ett pentest, får en rapport, och sedan lägger den i en byrålåda.
Värdet i båda metoderna ligger i åtgärdscykeln efteråt. En sårbarhetsskanning utan remediering är bara dokumentation av risk. Ett pentest utan uppföljning är en dyr rapport.
Vi rekommenderar att koppla scannerresultat direkt till er ärendehantering och att penetrationstestrapporter resulterar i en tidssatt åtgärdsplan med tydlig ansvarig. Managerade molntjänster
Vanliga misstag att undvika
1. Behandla scanning som "tillräckligt"
Vi ser detta ofta i organisationer som vill kryssa i en ruta för regelefterlevnad. Scanning ger en falsk trygghet om den inte kompletteras med manuell testning som utvärderar verklig exploaterbarhet.
2. Köpa pentest av lägstbjudande
Ett penetrationstest är bara så bra som pentestaren. En erfaren testare med branschspecifik kunskap hittar saker som en junior konsult med standardmetodik missar. Begär CV:n på teamet, fråga efter certifieringar (OSCP, OSCE, CREST) och be om exempelrapporter.
3. Testa bara utifrån
Externt pentest är viktigt, men insiderhot och lateral rörelse inom nätverket är ofta de mest förödande attackvektorerna. Kombinera externt och internt perspektiv.
4. Glömma molnmiljöerna
Traditionell scanning och pentest fokuserar ofta på on-premise-infrastruktur. Men felkonfigurerade S3-buckets, överdimensionerade IAM-roller i AWS och öppna Azure Storage-konton är bland de vanligaste fynden i moderna penetrationstest. Se till att era molnmiljöer (eu-north-1, Sweden Central) ingår i testomfattningen. Molnmigrering
5. Ingen baseline
Utan en dokumenterad baseline vet ni inte om säkerhetsläget förbättras eller försämras mellan tester. Spåra antal kritiska och högrisk-sårbarheter över tid.
Att välja rätt leverantör
| Kriterium | Vad du ska leta efter |
|---|---|
| Certifieringar | OSCP, OSCE, CREST, CE H – inte bara företagscertifieringar |
| Metodik | Tydlig koppling till OWASP Testing Guide, PTES eller NIST SP 800-115 |
| Rapportkvalitet | Narrativa beskrivningar med kontext, inte bara verktygsutdata |
| Scope-definition | Noggrann avgränsning innan test påbörjas – inklusive Rules of Engagement |
| Efterarbete | Erbjuder re-test efter åtgärder, inte bara en engångsrapport |
| Molnkompetens | Erfarenhet av AWS, Azure och GCP – inklusive container- och serverless-miljöer |
Kostnadsperspektivet
Exakta siffror varierar kraftigt beroende på miljöns storlek och komplexitet, men de relativa proportionerna är tydliga:
Sårbarhetsscanning är billig i drift. Verktygslicenser (Qualys, Nessus, Rapid7) kostar från några tusen till tiotusentals kronor per månad beroende på antal IP-adresser. Den löpande kostnaden är i huvudsak arbetstid för att granska och åtgärda fynd.
Penetrationstest är en engångskostnad per test, och priset speglar den tid och expertis som krävs. Ett avgränsat webbapplikationstest kan kosta väsentligt mindre än ett fullskaligt internt och externt infrastrukturtest med red team-komponenter.
Ur ett FinOps-perspektiv: investera i kontinuerlig scanning som hygien, och pentest som strategisk insats vid rätt tillfällen. Det är mer kostnadseffektivt än att köra dyra pentest kvartalsvis utan att ha grundläggande scanning på plats. Cloud FinOps
Vanliga frågor
Kan sårbarhetsscanning ersätta penetrationstest?
Nej. Scanning hittar kända sårbarheter med hjälp av signaturdatabaser, men missar logikfel, felkonfigurerade åtkomstkontroller och komplexa attackkedjor. Pentest krävs för att verifiera hur en verklig angripare kan utnyttja kombinationer av svagheter. De två metoderna kompletterar varandra – ingen av dem gör den andras jobb.
Hur ofta bör vi genomföra penetrationstest?
Minst årligen, men även vid större infrastrukturförändringar, ny applikationsrelease eller efter en incident. Organisationer som omfattas av NIS2 eller PCI DSS bör följa de specifika frekvenskrav som respektive regelverk anger. I högrisk-miljöer – finans, vård, kritisk infrastruktur – är halvårsvisa tester motiverade.
Vad kostar ett penetrationstest jämfört med sårbarhetsscanning?
Sårbarhetsscanning kostar avsevärt mindre eftersom processen är automatiserad – i praktiken handlar det om en verktygslicens och arbetstid för uppföljning. Penetrationstest kräver erfarna säkerhetsexperter under dagar till veckor och prissätts därefter. Den exakta kostnaden beror på scope, komplexitet och typ av test.
Vilka regelverk kräver pentest respektive scanning?
PCI DSS kräver uttryckligen kvartalsvis scanning och årligt pentest. GDPR artikel 32 kräver regelbunden testning av säkerhetsåtgärder – i praktiken förväntar sig IMY båda metoderna. NIS2-direktivet skärper kraven ytterligare. SOC 2 och ISO 27001 förutsätter dokumenterade sårbarhetshanteringsprocesser.
Kan vi köra pentest mot molnmiljöer i AWS eller Azure?
Ja, men med villkor. AWS tillåter pentest mot egna resurser utan förhandsgodkännande för de flesta testtyper. Azure har liknande policyer. Avgörande är att tydligt avgränsa testet så att det riktas mot era egna arbetsbelastningar – inte molnleverantörens underliggande infrastruktur. Dokumentera scope och följ leverantörens acceptable use policy.
Relaterade artiklar
Om författaren
Group COO & CISO at Opsio
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
Editorial standards: This article was written by a certified practitioner and peer-reviewed by our engineering team. We update content quarterly to ensure technical accuracy. Opsio maintains editorial independence — we recommend solutions based on technical merit, not commercial relationships.
