Sårbarhetstest: så skyddar du företaget i praktiken
Group COO & CISO
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
Sårbarhetstest: så skyddar du företaget i praktiken
Sårbarhetstest är en systematisk process där ni identifierar, verifierar och prioriterar säkerhetsbrister i er IT-infrastruktur innan en angripare gör det. Genom att kombinera automatiserad skanning med manuell exploatering får ni beslutsunderlag baserat på verklig risk – inte teoretiska scenarion. För svenska organisationer som omfattas av NIS2-direktivet och GDPR är regelbundna sårbarhetstest inte valfritt utan ett regulatoriskt krav.
Viktiga slutsatser
- Sårbarhetstest kombinerar automatiserad skanning med manuell verifiering för att eliminera false positives och ge beslutsunderlag med verklig riskvärdering
- NIS2-direktivet och GDPR ställer explicita krav på regelbundna säkerhetstester – bristande efterlevnad kan ge kännbara sanktioner
- Kontinuerliga tester i CI/CD-pipeline fångar sårbarheter innan de når produktion, vilket är billigare än att åtgärda dem efter driftsättning
- Kombinationen av sårbarhetsskanning, penetrationstest och konfigurationsgranskning ger en komplett bild av organisationens riskyta
Vad sårbarhetstest faktiskt innebär
Begreppet "sårbarhetstest" används ofta som paraplyterm för allt från automatiserad skanning till fullskaliga red team-övningar. Det skapar förvirring. Låt oss vara precisa.
Ett sårbarhetstest i sin grundform är en strukturerad process i tre steg:
1. Identifiering – Automatiserade verktyg skannar infrastruktur, applikationer och konfigurationer mot kända sårbarhetsdatabaser (CVE, NVD).
2. Verifiering – Säkerhetsspecialister validerar fynd manuellt, eliminerar false positives och bedömer exploaterbarhet i er specifika kontext.
3. Prioritering – Varje verifierad sårbarhet värderas utifrån CVSS-poäng, affärspåverkan och hur exponerad den är mot potentiella angripare.
Det som skiljer ett kvalificerat sårbarhetstest från en enkel skanningsrapport är steg två och tre. Verktyg som Nessus, Qualys eller OpenVAS producerar hundratals fynd – men utan kontextuell bedömning är listan bara brus. Från Opsios SOC ser vi dagligen hur organisationer drunknar i skanningsrapporter utan att veta vilka tio sårbarheter som faktiskt utgör akut risk.
Sårbarhetstest vs. penetrationstest vs. sårbarhetsskanning
Dessa tre begrepp blandas ihop konstant. Här är den praktiska skillnaden:
| Aspekt | Sårbarhetsskanning | Sårbarhetstest | Penetrationstest |
|---|---|---|---|
| Metod | Helautomatiserad | Automatiserad + manuell verifiering | Primärt manuell exploatering |
| Djup | Bred yta, känt mönster | Bred yta med kontextuell analys | Djup exploatering av specifika mål |
| False positives | Hög andel | Låg efter verifiering | Minimal – bara bekräftade fynd |
| Frekvens | Dagligen/veckovis | Månadsvis/kvartalsvis | Kvartalsvis/årligen |
| Kostnad | Låg (verktygsbaserad) | Medel | Hög (specialistkompetens) |
| Resultat | Lista med potentiella CVE:er | Prioriterad åtgärdslista med riskvärdering | Bevisad exploatering med attack-narrativ |
De flesta organisationer behöver alla tre, i olika kadens. Sårbarhetsskanning körs automatiserat i CI/CD-pipeline. Sårbarhetstest genomförs regelbundet med manuell analys. Penetrationstest utförs vid större releaser eller som del av compliance-cykeln.
Vill ni ha expertstöd med sårbarhetstest: så skyddar du företaget i praktiken?
Våra molnarkitekter hjälper er med sårbarhetstest: så skyddar du företaget i praktiken — från strategi till implementation. Boka ett kostnadsfritt 30-minuters rådgivningssamtal utan förpliktelse.
Varför svenska företag inte har råd att skippa sårbarhetstest
Hotbilden har förändrats fundamentalt
Ransomware-grupper opererar idag som professionella organisationer med affiliate-program och kundsupport. De skannar internet automatiserat efter kända sårbarheter och slår till inom timmar efter att en ny CVE publiceras. Enligt CNCF:s årliga undersökningar har komplexiteten i molnbaserade arkitekturer – med Kubernetes-kluster, mikrotjänster och serverless-funktioner – skapat en attackyta som är kvalitativt annorlunda jämfört med traditionell infrastruktur.
Från Opsios NOC i Karlstad och Bangalore ser vi detta i realtid. Exponeringstiden – tiden mellan att en sårbarhet publiceras och att den exploateras – har krympt dramatiskt. Det som för fem år sedan var veckor är idag timmar för kritiska sårbarheter. Utan kontinuerlig testning och övervakning är ni reaktiva per definition.
Regulatoriska krav driver testning
NIS2-direktivet, som trädde i kraft i EU och implementeras i svensk lag, ställer explicita krav på riskbedömning och säkerhetstestning för organisationer som klassificeras som väsentliga eller viktiga entiteter. Artikel 21 specificerar att lämpliga tekniska och organisatoriska åtgärder ska inkludera policies on risk analysis and information system security, vilket i praktiken innebär strukturerade säkerhetstester.
GDPR artikel 32 kräver a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures – en formulering som Integritetsskyddsmyndigheten (IMY) har tolkat som krav på regelbundna sårbarhetstest i sina tillsynsbeslut.
ISO/IEC 27001:2022, kontroll A.8.8 (Management of technical vulnerabilities), specificerar att organisationer ska obtain information about technical vulnerabilities of information systems in use och evaluate the organization's exposure. SOC 2 Trust Services Criteria ställer liknande krav.
Organisationer som inte kan visa dokumenterade, regelbundna sårbarhetstest har en svag position vid tillsyn – oavsett om det gäller IMY, NIS2-tillsynsmyndigheten eller en SOC 2-revision.
Metoder och verktyg i praktiken
Automatiserad sårbarhetsskanning
Grunden i varje testprogram är automatiserad skanning. Verktygen delas in i tre kategorier:
Nätverksskanning – Verktyg som Nessus Professional, Qualys VMDR eller OpenVAS skannar intern och extern infrastruktur mot CVE-databaser. De identifierar saknade patchar, öppna portar, svaga protokoll och felkonfigurationer.
Applikationsskanning (DAST) – Dynamic Application Security Testing-verktyg som OWASP ZAP, Burp Suite eller Acunetix testar webbapplikationer runtime genom att simulera angrepp mot endpoints.
Kodanalys (SAST/SCA) – Static Application Security Testing och Software Composition Analysis integreras i CI/CD-pipeline för att fånga sårbarheter i egen kod och tredjepartsbibliotek innan driftsättning. Verktyg som Snyk, Semgrep eller SonarQube är branschstandard.
Manuell testning och verifiering
Automatiserade verktyg missar kategoriskt tre typer av sårbarheter:
1. Logikfel – En applikation som låter användare eskalera rättigheter genom att manipulera affärslogik (exempelvis ändra pris i en e-handelsflöde) syns inte i automatiserad skanning.
2. Kedjade sårbarheter – Tre lågrisk-fynd som tillsammans ger fjärrkörning av kod kräver mänsklig kreativitet att identifiera.
3. Kontextberoende risker – En sårbarhet i en isolerad testmiljö är annorlunda än samma sårbarhet i ett system som hanterar patientdata.
Därför är manuell penetrationstestning av erfarna säkerhetsspecialister nödvändig som komplement. De flesta mogna säkerhetsprogram följer modellen: automatisera det repetitiva, använd människor för det komplexa.
Konfigurationsgranskning i molnmiljöer
En ofta förbisedd kategori är felkonfigurationer i molninfrastruktur. Flexeras State of the Cloud-rapport har konsekvent visat att säkerhet och konfigurationshantering är bland de största utmaningarna för organisationer i molnet. I praktiken är felkonfigurerade S3-buckets, alltför generösa IAM-roller och publikt exponerade databaser vanligare orsaker till dataintrång än sofistikerade zero-day-exploits.
Verktyg som AWS Config Rules, Azure Policy, Prisma Cloud eller Prowler automatiserar konfigurationsgranskning mot ramverk som CIS Benchmarks. Men precis som med sårbarhetsskanning krävs mänsklig bedömning för att avgöra vilka avvikelser som är verkliga risker i er kontext.
Bygga ett moget testprogram
Steg 1: Kartlägg er attackyta
Innan ni testar behöver ni veta vad som ska testas. En attackyteanalys inkluderar:
- Extern infrastruktur (publika IP-adresser, DNS-poster, API:er)
- Interna nätverk och segmentering
- Webbapplikationer och mobilappar
- Molnresurser över samtliga konton och prenumerationer
- Tredjepartsleverantörer med åtkomst till era system
- SaaS-integrationer och OAuth-flöden
Verktyg som Shodan, Censys eller leverantörsspecifika tjänster (AWS Security Hub, Azure Defender for Cloud) hjälper till att kartlägga den externa ytan. Men glöm inte: shadow IT – molnresurser som team har skapat utanför central styrning – är ofta de mest sårbara.
Steg 2: Definiera kadens och scope
Ett praktiskt ramverk för ett medelstort svenskt företag:
| Testtyp | Kadens | Scope | Ansvarig |
|---|---|---|---|
| Automatiserad sårbarhetsskanning (infra) | Veckovis | All extern och intern infrastruktur | Drift/SOC |
| SAST/SCA i CI/CD | Vid varje commit | All applikationskod och dependencies | Utvecklingsteam |
| DAST mot staging | Vid varje release | Webbapplikationer och API:er | AppSec/QA |
| Fullständigt sårbarhetstest med manuell verifiering | Kvartalsvis | Prioriterade system baserat på riskklassificering | Säkerhetsteam/extern partner |
| Penetrationstest (red team) | Halvårsvis/årligen | Fullständig infrastruktur och organisation | Extern specialist |
| Konfigurationsgranskning moln | Kontinuerlig (automatiserad) + kvartalsvis manuell | Samtliga molnkonton | Cloud-/plattformsteam |
Steg 3: Integrera med ärendehantering och styrning
Testresultat som hamnar i en PDF-rapport som ingen läser är meningslösa. Mogna organisationer:
- Integrerar skanningsfynd direkt i ärendehanteringssystem (Jira, ServiceNow) med automatisk tilldelning baserad på systemägare
- Definierar SLA:er för åtgärd baserat på risknivå: kritisk = 24h, hög = 7 dagar, medel = 30 dagar
- Mäter mean time to remediate (MTTR) per risknivå och team
- Rapporterar trend-data till ledningsgrupp och styrelse kvartalsvis
Det är här strategiskt säkerhetsarbete börjar ge verkligt värde – när testdata driver beslut om resurser, prioriteringar och arkitekturförändringar.
Sårbarhetstestning i molnet: specifika utmaningar
Molnmiljöer introducerar unika utmaningar som traditionella testmetoder inte täcker:
Delat ansvarsmodell – AWS, Azure och Google Cloud ansvarar för säkerheten av molnet, men ni ansvarar för säkerheten i molnet. Sårbarhetstester måste täcka ert ansvarsområde: IAM-konfiguration, nätverkssegmentering, datakryptering, applikationslogik.
Ephemeral infrastruktur – Containers och serverless-funktioner lever minuter eller sekunder. Traditionell sårbarhetsskanning som förutsätter statiska mål missar dessa. Lösningen är att integrera testning i build-pipeline (shift-left) och använda image scanning (Trivy, Grype) före driftsättning.
Multi-cloud-komplexitet – Organisationer som kör arbetsbelastningar i både AWS eu-north-1 (Stockholm) och Azure Sweden Central behöver testning som täcker båda miljöerna med konsekvent rapportering. Datadog State of Cloud har visat att multi-cloud-adoption fortsätter öka, vilket gör enhetlig säkerhetstestning kritisk.
Infrastructure as Code (IaC) – Med Terraform, CloudFormation eller Bicep kan ni skanna infrastrukturdefinitioner innan de driftsätts. Verktyg som Checkov, tfsec eller KICS fångar felkonfigurationer i kodstadiet – den billigaste platsen att åtgärda dem.
Vad Opsios SOC ser i verkligheten
Utifrån vår 24/7 SOC/NOC-verksamhet kan vi dela några mönster som vi observerar konsekvent:
De vanligaste fynden vid kunders första sårbarhetstest:
- Föråldrade TLS-konfigurationer (TLS 1.0/1.1 fortfarande aktivt)
- Överdrivet generösa IAM-policyer ("admin by default")
- Publikt exponerade tjänster som inte behöver vara publika
- Tredjepartsbibliotek med kända, patchade sårbarheter som aldrig uppdaterats
- Avsaknad av nätverkssegmentering mellan utvecklings- och produktionsmiljöer
Det som förvånar kunder mest: Att de allvarligaste riskerna sällan är sofistikerade – det handlar om grundläggande hygien som inte upprätthålls konsekvent. En S3-bucket med felaktig ACL eller en databasport öppen mot internet kräver ingen avancerad angripare.
Vår rekommendation: Börja med att åtgärda det grundläggande innan ni investerar i avancerad hotjakt eller AI-baserade säkerhetsverktyg. En robust grund av patchhantering, konfigurationshärdning och nätverkssegmentering eliminerar majoriteten av den attackyta som opportunistiska angripare utnyttjar.
Molnmigrering med säkerhetsfokus
Så väljer ni rätt partner för sårbarhetstest
Om ni inte har intern kapacitet att driva ett komplett testprogram, tänk på följande vid val av extern partner:
- Certifieringar och metodik – OSCP, OSCE, GPEN, GWAPT hos individuella testare. Leverantören bör följa etablerade ramverk (OWASP Testing Guide, PTES, NIST SP 800-115).
- Branschkunskap – En testare som förstår er branschs specifika riskbild (fintech, healthtech, industri) levererar relevantare fynd.
- Rapportkvalitet – Be om exempelrapporter. Bra rapporter innehåller: executive summary för ledning, tekniska detaljer för utvecklare, steg-för-steg-reproduktion, och konkreta åtgärdsförslag med prioritering.
- Uppföljning – En seriös partner erbjuder verifiering av åtgärder (re-test) och stöd vid remediering, inte bara en rapport och faktura.
- Svensk närvaro och datahantering – För organisationer med känsliga data: säkerställ att testpartnern kan hantera data inom Sverige/EU och förstår svensk regulatorisk kontext.
Vanliga frågor
Vad är skillnaden mellan sårbarhetstest och penetrationstest?
Sårbarhetsskanning identifierar och katalogiserar kända svagheter automatiserat. Penetrationstest går steget längre: en testare försöker aktivt exploatera sårbarheterna för att verifiera verklig risk. I praktiken behöver de flesta organisationer båda – skanning för bredd och pentest för djup.
Hur ofta bör vi genomföra sårbarhetstest?
Automatiserad sårbarhetsskanning bör köras kontinuerligt eller minst veckovis. Fullständiga penetrationstest rekommenderas kvartalsvis eller vid större förändringar i infrastrukturen. NIS2-direktivet kräver regelbundna tester, och praxis bland organisationer som omfattas är minst kvartalsvis.
Räcker automatiserade verktyg, eller behövs manuell testning?
Automatiserade verktyg är effektiva för att hitta kända CVE:er och felkonfigurationer, men missar ofta logikfel, kedjade sårbarheter och kontextberoende brister. Manuell testning av erfarna säkerhetsspecialister kompletterar genom att identifiera det som automatiken inte ser. Bäst resultat får ni med båda.
Vad kostar ett sårbarhetstest för ett medelstort svenskt företag?
Kostnaden varierar kraftigt beroende på scope. En automatiserad sårbarhetsskanning av extern yta kan starta runt 15 000–30 000 SEK. Fullständigt penetrationstest av webbapplikation och intern infrastruktur hamnar typiskt på 80 000–250 000 SEK. Managerade tjänster med kontinuerlig testning ger ofta bättre värde per krona.
Vilka ramverk och regelverk kräver sårbarhetstest?
NIS2-direktivet kräver regelbundna riskbedömningar och säkerhetstester för väsentliga och viktiga entiteter. GDPR artikel 32 kräver regelbunden utvärdering av tekniska skyddsåtgärder. ISO/IEC 27001:2022, kontroll A.8.8, specificerar hantering av tekniska sårbarheter. SOC 2 Trust Services Criteria ställer liknande krav.
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.
