Sårbarhetsskanning vs. penetrationstest

En vanlig missuppfattning är att sårbarhetsskanning och penetrationstest är utbytbara. Det stämmer inte alls. De fyller olika funktioner och bör användas i kombination.

Automatiserad sårbarhetsskanning i praktiken

Verktyg som Nessus, Qualys, OpenVAS och Nuclei skannar mot databaser med kända sårbarheter. I en modern CI/CD-pipeline integrerar man DAST-verktyg (Dynamic Application Security Testing) som OWASP ZAP direkt i deployment-processen, så att en ny release inte kan gå live om kritiska sårbarheter upptäcks.

Från Opsios driftserfarenhet: de flesta fynd från automatiserad skanning är faktiskt åtgärdbara inom minuter – en saknad header, en TLS-konfiguration som tillåter äldre chiffer, en exponerad statusendpoint. Problemet är inte att det är svårt att fixa, utan att ingen tittar på rapporten. Det är därför vi förespråkar att skanningsresultat integreras direkt i ärendehanteringssystem med tydliga SLA:er.

Penetrationstest – det manuella komplettet

Där automatiserad skanning hittar det uppenbara hittar en penetrationstestare det subtila: en IDOR-sårbarhet (Insecure Direct Object Reference) där en inloggad användare kan se andra användares data genom att ändra ett ID i URL:en. Eller en race condition i betalflödet som gör det möjligt att använda en rabattkod flera gånger.

Den här typen av logikfel finns inte i någon CVE-databas. De är unika för din applikation och kräver en människa som förstår affärslogiken.

Vi rekommenderar penetrationstest minst årligen, och alltid efter:

• Större arkitekturförändringar
• Ny betalnings- eller autentiseringsfunktionalitet
• Migrering till ny infrastruktur
• Förvärv eller integration av extern kod

Regulatoriska krav: GDPR, NIS2 och branschstandarder

GDPR artikel 32

GDPR kräver "lämpliga tekniska och organisatoriska åtgärder" för att säkerställa en säkerhetsnivå som är lämplig i förhållande till risken. Integritetsskyddsmyndigheten (IMY) har i flera tillsynsbeslut pekat på att avsaknad av regelbundna säkerhetstest utgör en brist i detta avseende. Dokumenterade testresultat fungerar som bevisunderlag vid en eventuell granskning.

NIS2-direktivet

NIS2, som trädde i kraft i EU under 2024–2025, breddar kretsen av organisationer som omfattas av cybersäkerhetskrav dramatiskt. Direktivet kräver bland annat riskanalys, incidenthantering och verifiering av säkerhetsåtgärder – alltså säkerhetstest i praktiken. Ledningen bär personligt ansvar, och sanktionsavgifterna kan bli betydande.

ISO 27001 och SOC 2

Båda ramverken förutsätter dokumenterad och regelbunden säkerhetsgranskning. ISO/IEC 27001 Annex A innehåller specifika kontroller för teknisk sårbarhetsbedömning (A.8.8) och penetrationstest (A.8.34 i 2022-versionen). SOC 2 Trust Services Criteria kräver löpande övervakning och testning av säkerhetskontroller.

Molnsäkerhet och regelefterlevnad

Vanliga angreppstyper och vad säkerhetstest avslöjar

OWASP Top 10 – fortfarande relevant

OWASP Top 10 uppdateras med jämna mellanrum och ger en bra bild av de vanligaste sårbarhetstyperna i webbapplikationer. De mest frekventa fynden vi ser i Opsios säkerhetsgranskning av kundmiljöer:

Broken Access Control – överlägset vanligast. Användare kan komma åt data eller funktioner de inte borde ha tillgång till. Ofta subtilt och svårt att fånga med enbart automatik.

Injection – SQL-injection har blivit ovanligare tack vare ORM-ramverk, men NoSQL-injection, LDAP-injection och template injection ökar.

Security Misconfiguration – exponerade admin-gränssnitt, standardlösenord, verbose felmeddelanden, saknade säkerhetsheaders. Trivialt att åtgärda, men lika trivialt att missa.

Server-Side Request Forgery (SSRF) – särskilt relevant i molnmiljöer där metadata-endpoints (som AWS IMDS) kan exponera credentials om SSRF-skydd saknas.

Specifikt för molnbaserade webbplatser

Webbplatser som körs i AWS, Azure eller GCP har en ytterligare attackyta: IAM-felkonfigurationer, exponerade S3-buckets, publikt tillgängliga databaser. En säkerhetsgranskning som bara tittar på applikationslagret missar infrastrukturlagret – och tvärtom. Det är därför vi på Opsio alltid förespråkar en fullstacksstrategi för säkerhetstest.

Managerade molntjänster

Hur du bygger en löpande säkerhetstestprocess

Engångstester ger en ögonblicksbild. Hotbilden förändras dagligen. Nya CVE:er publiceras, beroenden uppdateras, utvecklare gör ändringar. En mogen säkerhetsprocess ser ut ungefär så här:

Nivå 1: Automatiserat i CI/CD

• SAST-verktyg (SonarQube, Semgrep) körs vid varje pull request
• Beroendeskanners (Dependabot, Snyk, Trivy) flaggar sårbara paket
• DAST-skanning mot staging-miljön innan deploy till produktion
• Container image scanning om ni kör Kubernetes

Nivå 2: Veckovis/månadsvis

• Fullständig sårbarhetsskanning av produktionsmiljön
• Granskning av nya och ändrade firewall-regler och IAM-policyer
• Genomgång av skanningsrapporter med tydlig ägarskap och SLA

Nivå 3: Kvartalsvis/årligen

• Manuellt penetrationstest av extern specialist
• Red team-övning för mer mogna organisationer
• Uppdatering av hotmodell baserat på nya attackmönster
• Revision av säkerhetspolicyer och rutiner

Nivå 4: Kontinuerligt (SOC/NOC)

• 24/7-övervakning av loggar, nätverkstrafik och anomalier
• Automatiserade varningar vid misstänkt aktivitet
• Incidentrespons med definierade eskaleringsvägar

Den sista nivån är där många organisationer tappar bort sig. Att ha verktyg som genererar larm är enkelt. Att ha kompetenta analytiker som kan skilja falska positiver från verkliga hot – dygnet runt – är svårt och dyrt att bygga internt.

Managerad DevOps och säkerhet

Verktyg vi rekommenderar

Det finns ingen brist på säkerhetsverktyg. Utmaningen är att välja rätt kombination och faktiskt agera på resultaten.

För sårbarhetsskanning:

• Nuclei – öppen källkod, snabbt, enormt community med templates
• OWASP ZAP – gratis DAST-verktyg, bra för CI/CD-integration
• Qualys/Nessus – kommersiella alternativ med djupare rapportering

För penetrationstest:

• Burp Suite Professional – industristandard för manuell webbtestning
• Metasploit – för infrastruktur- och nätverkstestning
• ffuf/Gobuster – för discovery och fuzzing

För löpande övervakning:

• AWS Security Hub / Azure Defender / Google SCC – molnleverantörernas egna verktyg
• Wazuh – öppen källkod SIEM/EDR
• Datadog Security Monitoring – om ni redan använder Datadog för observability

Enligt Datadog State of Cloud har adoptionen av integrerade säkerhetsverktyg i molnplattformar ökat markant, men verktyg utan process ger falsk trygghet.

Vad händer efter testet? Åtgärdsprocessen

Det mest värdelösa dokumentet i IT-säkerhet är en penetrationstestrapport som ingen agerar på. Vi har sett det otaliga gånger: en dyr rapport landar, folk nickar bekymrat på ett möte, och sedan händer ingenting.

En fungerande åtgärdsprocess kräver:

1. Klassificering – Varje fynd graderas efter CVSS eller en intern risknivå (kritisk/hög/medel/låg)

2. Ägarskap – Varje fynd tilldelas en ansvarig person, inte ett team

3. SLA – Kritiska fynd: 24–72 timmar. Höga: 1–2 veckor. Medel: 30 dagar. Låga: nästa sprint.

4. Verifiering – Åtgärden testas, inte bara markeras som klar

5. Dokumentation – Allt loggas för efterlevnad och framtida referens

Cloud FinOps och kostnadsoptimering

Vanliga misstag vi ser

"Vi har en WAF, vi behöver inte testa." En Web Application Firewall (WAF) stoppar kända attackmönster, men en skicklig angripare kringgår WAF-regler rutinmässigt. WAF är ett skyddslager, inte en ersättning för säkerhetstest.

"Vi testade förra året." Webbplatsen du testade förra året är inte samma webbplats som körs idag. Varje commit, varje beroendeuppdatering, varje infrastrukturförändring kan introducera nya sårbarheter.

"Vår utvecklare kollar säkerheten." Utvecklare som granskar sin egen kod har samma blindfläckar som när man korrekturläser sin egen text. Externt perspektiv är inte en lyx – det är en nödvändighet.

"Vi har inga känsliga data." Varje webbplats med ett inloggningsformulär hanterar credentials. Varje webbplats med ett kontaktformulär samlar personuppgifter. Och en komprometterad server kan användas som språngbräda för attacker mot andra mål.

Opsios perspektiv: vad vi ser i produktion

I vårt SOC/NOC i Karlstad och Bangalore ser vi dygnet runt hur hotbilden utvecklas i realtid. Några observationer som färgar våra rekommendationer:

• Automatiserade attacker är normen, inte undantaget. Inom minuter efter att en ny CVE publiceras ser vi skanningsförsök mot kundmiljöer.
• Supply chain-attacker ökar – komprometterade npm-paket, poisoned Docker images, och bakdörrar i tredjepartsbibliotek. Beroendeskanners är inte valfritt.
• Molnspecifika attacker mognar – SSRF mot metadata-tjänster, IAM-eskalering och lateral movement mellan molntjänster kräver testning bortom traditionell webbtestning.
• Grundläggande hygien saknas oftare än avancerade skydd – MFA som inte är aktiverat, standardlösenord på admin-gränssnitt, opatched servrar. Det glamorösa hotet säljer tidningsrubriker, men det banala hotet orsakar de flesta incidenterna.

Molnmigrering med inbyggd säkerhet

Vanliga frågor

Hur ofta bör vi genomföra säkerhetstest?

Automatiserad sårbarhetsskanning bör köras veckovis eller vid varje deploy. Manuella penetrationstest rekommenderas minst en gång per år, samt efter större förändringar i arkitekturen. NIS2-direktivet förutsätter regelbunden och dokumenterad säkerhetsverifiering.

Vad är skillnaden mellan sårbarhetsskanning och penetrationstest?

Sårbarhetsskanning är automatiserad och identifierar kända sårbarheter (CVE:er, felkonfigurationer). Penetrationstest utförs av en kvalificerad testare som simulerar riktiga attackkedjor och hittar logikfel, behörighetsbrister och affärslogikproblem som automatik missar. Båda behövs – de ersätter inte varandra.

Räcker det med ett säkerhetstest för att uppfylla GDPR?

Nej. GDPR artikel 32 kräver "lämpliga tekniska och organisatoriska åtgärder" – säkerhetstest är en viktig del, men du behöver också dokumenterade rutiner, incidenthantering, åtkomstkontroll och löpande uppföljning. Testresultat bör arkiveras som bevisunderlag vid tillsyn från IMY.

Vad kostar ett penetrationstest?

Kostnaden varierar beroende på scope. En enkel webbapplikation kan hamna på 50 000–150 000 SEK, medan en komplex miljö med API:er, mobilappar och intern infrastruktur lätt överstiger 300 000 SEK. Automatiserad sårbarhetsskanning som löpande tjänst är betydligt billigare och ger daglig insyn.

Kan vi genomföra säkerhetstest själva eller behöver vi extern hjälp?

Automatiserad skanning kan och bör drivas internt som en del av CI/CD-pipelinen. Penetrationstest kräver däremot specialistkompetens och ett utifrånperspektiv – en extern testare har inte samma blindfläckar som teamet som byggt applikationen. En kombinerad modell fungerar bäst: intern automation plus extern granskning.