Sårbarhetsscanning: Automatiserad säkerhetsgranskning 2026

Sårbarhetsscanning har 2026 gått från en manuell, periodisk granskning till en automatiserad, kontinuerlig process som är integrerad i varje DevOps-pipeline. Med verktyg som Trivy, Grype, Terrascan och Dependabot kan du upptäcka sårbarheter i containrar, infrastruktur som kod, beroenden och källkod — allt innan det når produktion. För svenska företag som omfattas av NIS2 är automatiserad sårbarhetsscanning inte bara en bra praxis — det är ett regulatoriskt krav.

I den här guiden går vi igenom sårbarhetsscanning 2026: container-scanning (Trivy, Grype, Clair), infrastrukturscanning (Terrascan, tfsec, Checkov), beroendescannning, CVE-databaser, prioritering (CVSS, EPSS), remedieringsarbetsflöden och scanning i CI/CD.

Varför automatiserad sårbarhetsscanning?

Traditionell sårbarhetshantering innebar att en säkerhetsexpert periodiskt granskade system och publicerade rapporter — ofta med veckors eller månaders fördröjning. 2026 är det inte tillräckligt. Nya sårbarheter upptäcks dagligen (över 20 000 CVE:er per år), och attackfönstret mellan upptäckt och exploatering krymper. Automatiserad scanning ger dig kontinuerlig insyn i din säkerhetsstatus och varnar dig inom minuter — inte veckor — när nya sårbarheter upptäcks.

För svenska SaaS-företag som hostar på Azure eller AWS är automatiserad scanning ofta en förutsättning för att uppfylla kraven i NIS2, SOC 2 och ISO 27001. Det ger dig bevis på att du aktivt övervakar och hanterar sårbarheter — något som revisorer allt oftare efterfrågar. Automatisering minskar också beroendet av knappa säkerhetsexperter och låter dina utvecklare arbeta självständigt med säkerhet.

Container-scanning — Trivy, Grype och Clair

Container-scanning är 2026 en av de mest mogna och viktigaste formerna av sårbarhetsscanning. Verktygen analyserar container-images lager för lager, identifierar alla installerade paket och bibliotek, och jämför dem mot CVE-databaser för att hitta kända sårbarheter. Trivy (Aqua Security) är standardvalet 2026 — det är snabbt, enkelt att använda och stöder alla större operativsystem och språk.

Grype (Anchore) är ett bra alternativ med liknande funktionalitet. Clair (Red Hat) används främst som backend för container-registry-scanning. För svenska team rekommenderar vi Trivy som primärt container-scanner — integrera det i CI/CD-pipelinen och konfigurera det att blockera deployment om kritiska (CVSS 9+) sårbarheter upptäcks. För Azure-användare: Microsoft Defender for Cloud har inbyggd container-scanning som komplement.

Infrastrukturscanning — Terrascan, tfsec och Checkov

Infrastructure as Code (IaC) har gjort infrastrukturhantering reproducerbar och versionshanterad — men det betyder också att säkerhetsproblem i din kod kan replikeras över hela din miljö. IaC-scanning granskar din Terraform, CloudFormation, Pulumi och Kubernetes-manifest kod för att hitta felkonfigurationer som öppna säkerhetsgrupper, ohanterad kryptering och överprivilegierade IAM-roller.

Terrascan (Accurics/Accenture) och Checkov (Bridgecrew/Prisma Cloud) är de mest populära IaC-scannerna 2026. Båda har ett stort antal inbyggda regler baserade på CIS Benchmarks och OWASP. tfsec (numera del av Trivy) är ett lättare alternativ. För svenska team som använder Terraform rekommenderar vi Checkov integrerat i CI/CD — det har bäst stöd för Azure-specifika resurser och ger tydliga remedieringsförslag.

Beroendescannning — hantera leveranskedjerisken

Beroendescannning (dependency scanning) granskar dina open source-bibliotek och deras beroendekedja för kända sårbarheter. 2026 är supply chain-attacker ett av de snabbast växande hoten — angripare komprometterar populära npm-, PyPI- och Maven-paket för att sprida skadlig kod till alla som använder dem. npm drabbades av flera uppmärksammade attacker under 2025 som påverkade tusentals nedströmsberoenden.

Dependabot (inbyggt i GitHub) skannar dina dependencies automatiskt och skapar pull requests när uppdateringar finns tillgängliga. Snyk går steget längre med prioritering av sårbarheter baserat på exploaterbarhet och reachability (kan sårbarheten faktiskt nås från din kod?). För svenska team rekommenderar vi Dependabot för automatisering av uppdateringar och Snyk för prioriterad sårbarhetshantering med reachability-analys.

CVE-databaser och deras begränsningar

CVE (Common Vulnerabilities and Exposures) är standarden för att identifiera och katalogisera sårbarheter. NIST:s National Vulnerability Database (NVD) är den primära källan, men den lider av fördröjningar och inkonsekvent poängsättning. 2026 har alternativa databaser som GitHub Advisory Database, GitLab Advisory Database och OSV.dev blivit viktiga komplement med snabbare uppdateringar och bättre täckning.

Trivy och Grype använder flera databaser samtidigt för bästa täckning. Utmaningen är att olika databaser kan ha olika CVSS-poäng för samma sårbarhet, och många sårbarheter har inte CVSS-poäng alls. För svenska team: använd ett scanningverktyg som aggregerar flera databaser och fokusera på EPSS (Exploit Prediction Scoring System) snarare än enbart CVSS för prioritering.

Prioritering — CVSS, EPSS och affärskontext

En av de största utmaningarna med sårbarhetsscanning är bruset. En typisk organisation kan ha tusentals detekterade sårbarheter — om du försöker åtgärda alla blir du paralyserad. Prioritering är nyckeln. CVSS (Common Vulnerability Scoring System) ger en teknisk allvarlighetsgrad (0–10) baserad på attackvektor, komplexitet, och påverkan. EPSS (Exploit Prediction Scoring System) predikterar sannolikheten att en sårbarhet exploateras inom 30 dagar.

Bäst praxis 2026: kombinera CVSS och EPSS med affärskontext. En kritisk CVSS 9.3 i ett icke-exponerat internt system kan vänta. En medelhög CVSS 6.5 med hög EPSS i en internetexponerad API-endpoint måste åtgärdas omedelbart. Sätt upp automatiska regler: blockera deployment om CVSS ≥ 9.0 OCH EPSS ≥ 0.5, varna om CVSS ≥ 7.0 OCH EPSS ≥ 0.3.

Scanning i CI/CD — bygg rätt pipeline

Sårbarhetsscanning i CI/CD är 2026 standard. Målet är att upptäcka och blockera sårbara artefakter innan de når produktion — utan att sakta ner utvecklingen i onödan. En välbyggd pipeline har flera scanning-steg: bygg-scann (Trivy på image), IaC-scann (Checkov på Terraform), beroendescann (Snyk/Dependabot), och hemlighetsscann (GitLeaks på kod).

För GitHub Actions: använd Trivy Action för container-scanning, Checkov Action för IaC, och Snyk Action för beroenden. Konfigurera varje steg med lämpliga tröskelvärden: blockera på kritiska sårbarheter, varna på höga, och tillåt medel/låg med automatisk ticket-skapande. Använd caching för att undvika att skanna oförändrade images och beroenden vid varje körning.

Remedieringsarbetsflöden

Att upptäcka sårbarheter är värdelöst utan effektiva remedieringsarbetsflöden. Varje detekterad sårbarhet bör automatiskt: skapa en ticket i ditt ärendehanteringssystem med korrekt prioritet, tilldela rätt team baserat på teknologiområde, inkludera åtgärdsförslag från scanning-verktyget, och eskalera om SLA inte hålls. För sårbarheter som kan åtgärdas med versionsuppdatering (de flesta SCA-sårbarheter), skapa en pull request automatiskt.

Acceptera att vissa sårbarheter inte kan åtgärdas omedelbart — på grund av affärspåverkan, tekniska begränsningar eller avsaknad av patch. Dokumentera accepterad risk med: varför sårbarheten accepteras, vilka kompenserande kontroller som finns, när sårbarheten ska omvärderas, och vem som accepterar risken. För NIS2-krav måste accepterade risker granskas av ledningen.

Mätning och rapportering

Vad du inte mäter kan du inte förbättra. Sätt upp nyckeltal för din sårbarhetshantering: genomsnittlig tid till remediering (MTTR), antal öppna sårbarheter per allvarlighetsgrad, antal sårbarheter som blockerats i CI/CD, och täckningsgrad (hur många % av era images/repos skannas). Rapportera månadsvis till ledningen med trender och åtgärder.

Sårbarhetsscanning för svenska NIS2-omfattade företag

NIS2-direktivet, implementerat i svensk lag under 2025–2026, ställer tydliga krav på sårbarhetshantering för verksamheter inom kritisk infrastruktur och digitala tjänster. Kraven inkluderar: kontinuerlig sårbarhetsövervakning, dokumenterad process för hantering, automatiserad scanning i utvecklingskedjan, och regelbunden rapportering till ledningen. För företag som levererar molntjänster, SaaS eller digital infrastruktur är automatiserad sårbarhetsscanning ett minimikrav.

För svenska team: dokumentera er sårbarhetshanteringsprocess — vilka verktyg används, vilka system skannas, vilka SLA:er gäller, och hur eskalerar ni. Genomför regelbundna sårbarhetsgenomgångar med ledningen. Kombinera automatiserad scanning med årliga penetrationstester. Läs mer om NIS2-checklistan för detaljerade krav.

Slutsats

Automatiserad sårbarhetsscanning är 2026 en grundläggande del av varje seriös DevOps-pipeline. Trivy för containrar, Checkov för IaC, Snyk/Dependabot för beroenden — kombinerat med en tydlig prioriteringsmodell (CVSS + EPSS + affärskontext) och effektiva remedieringsarbetsflöden. För svenska företag som omfattas av NIS2 är det inte bara en rekommendation — det är ett krav. Börja med container-scanning (Trivy) och beroendescannning (Dependabot), lägg till IaC-scanning, och bygg ut din pipeline steg för steg.

Vill du ha hjälp att bygga en automatiserad sårbarhetshantering? Jag erbjuder konsultation inom DevSecOps och säkerhetsarkitektur — läs mer om våra tjänster eller boka ett samtal.