Hoppa till innehåll
SäkerhetSäkerhetstestningDevSecOpsSAST14 min läsning

Säkerhetstestning: SAST, DAST, SCA och penetrationstestning

Automatiserad säkerhetsgranskning i hela utvecklingskedjan — från statisk analys till manuell pentest

1 augusti 2026Uppdaterad 10:00
3 20025
Säkerhetstestning: SAST, DAST, SCA och penetrationstestning
Säkerhetstestning 2026 handlar om automatisering i hela utvecklingskedjan — från första kodrad till produktion.Photo: Unsplash

Omfattande guide till säkerhetstestning 2026: SAST (SonarQube, Semgrep), DAST (OWASP ZAP, Burp Suite), SCA (Snyk, Dependabot), DevSecOps och penetrationstestning.

Säkerhetstestning har 2026 blivit en integrerad del av utvecklingsprocessen snarare än ett separat moment som görs innan release. DevSecOps-rörelsen har mognat, och verktyg som SonarQube, Semgrep, Snyk och OWASP ZAP är standard i moderna CI/CD-pipelines. Men med fler verktyg följer utmaningen att veta vilken typ av testning som ger mest värde — och när.

I den här guiden går vi igenom säkerhetstestning 2026: SAST-verktyg (SonarQube, Semgrep), DAST-verktyg (OWASP ZAP, Burp Suite), SCA (Snyk, Dependabot), penetrationstestningsmetodik, DevSecOps-integration och sårbarhetshantering.

SAST — Static Application Security Testing

SAST (statisk analys) granskar källkod utan att köra den. Verktygen analyserar kodens struktur, dataflöden och kontrollflöden för att identifiera säkerhetsproblem som SQL-injektion, XSS, buffer overflow och osäkra API-anrop. SAST är snabbt, kan integreras i IDE och CI/CD, och upptäcker problem tidigt i utvecklingscykeln — när de är billigast att åtgärda.

SonarQube är 2026 det mest använda SAST-verktyget, särskilt i enterprise-miljöer. Det stöder över 30 språk, har en rik regeluppsättning och integreras med alla större CI/CD-plattformar. Semgrep (open source) har vuxit kraftigt tack vare sin snabbhet, flexibla regelskapande och stöd för att skriva custom-regler. För svenska team rekommenderar vi Semgrep för mindre team och SonarQube för större organisationer med compliance-krav.

DAST — Dynamic Application Security Testing

DAST (dynamisk analys) testar en körande applikation utifrån — precis som en angripare skulle göra. Verktygen skannar applikationen, identifierar endpoints, skickar manipulerade requests och analyserar svar för att hitta sårbarheter som autentiseringsbrister, injektioner och konfigurationsproblem. DAST fångar problem som SAST inte kan upptäcka, som runtime-sårbarheter och felaktig serverkonfiguration.

OWASP ZAP (Zed Attack Proxy) är standardvalet 2026 för DAST — det är open source, aktivt underhållet och har utmärkt stöd för API-scanning (OpenAPI, GraphQL, SOAP). Burp Suite är kraftfullare men kräver licens och används främst av dedikerade säkerhetstestare. För svenska SaaS-team är ZAP integration i CI/CD-pipelinen en kostnadseffektiv startpunkt för DAST.

SCA — Software Composition Analysis

SCA (beroendeanalys) granskar dina open source-bibliotek och tredjepartskomponenter för kända sårbarheter. 2026 består en genomsnittlig webbapplikation av över 90 % open source-kod — vilket innebär att dina största säkerhetsrisker ofta inte finns i din egen kod utan i dina beroenden. SCA-verktyg jämför dina beroenden mot CVE-databaser (Common Vulnerabilities and Exposures) och varnar när sårbarheter upptäcks.

Snyk och Dependabot (GitHub) är standarden 2026. Snyk erbjuder djupare analys med prioritering, fix-förslag och integration i hela utvecklingskedjan. Dependabot är inbyggt i GitHub och är kostnadsfritt för alla GitHub-användare — det skapar automatiskt pull requests för att uppdatera sårbara beroenden. För svenska team rekommenderar vi Dependabot som grund och Snyk för organisationer med strikta compliance-krav.

Penetrationstestning — manuell expertis

Automatiserade verktyg kan hitta många sårbarheter, men de missar affärslogiska brister, komplexa autentiseringsflöden och skräddarsydda attacker. Penetrationstestning (pentest) innebär att en etisk hackare manuellt testar din applikation med samma metoder som en angripare — fast med ditt tillstånd och inom överenskomna ramar.

En pentest följer en strukturerad metodik: informationsinsamling (reconnaissance), hotmodellering, sårbarhetsanalys, exploatering, och rapportering med åtgärdsförslag. För svenska företag som hanterar personuppgifter eller omfattas av NIS2 är regelbundna pentester inte bara rekommenderade — de är ofta ett krav från försäkringsbolag, kunder och myndigheter. Läs mer om pris för penetrationstestning.

DevSecOps — säkerhet i hela kedjan

DevSecOps innebär att säkerhet integreras i varje steg av utvecklings- och driftsprocessen, inte som ett separat moment. Målet är att göra säkerhet till en del av utvecklamas vardag — inte en bromskloss som kommer från ett separat säkerhetsteam. 2026 är DevSecOps standard i mogna organisationer, med säkerhetskontroller i IDE, pull requests, CI/CD-pipeline och runtime.

En typisk DevSecOps-pipeline: utvecklaren får SAST-varningar i IDE → pre-commit hooks kör Semgrep och Snyk → pull request triggerar SAST, SCA och secrets scanning → merge till main triggerar DAST och container scanning → deployment triggerar runtime-säkerhet. Varje steg har en tydlig ägare och eskaleringsväg. För svenska team som implementerar DevSecOps, börja med secrets scanning och SCA — de ger snabbast ROI.

SAST-verktyg på djupet — SonarQube vs Semgrep

SonarQube är det mest etablerade SAST-verktyget med stöd för över 30 språk, en omfattande regeluppsättning (inklusive OWASP Top 10 och CWE) och integration med alla större CI/CD-verktyg. SonarQube kan köras on-premises eller som SaaS (SonarCloud). Det är tungt men mycket kapabelt — särskilt för enterprise-organisationer med krav på spårbarhet och compliance-rapportering.

Semgrep är lättare, snabbare och mer flexibelt än SonarQube. Semgrep fokuserar på att göra det enkelt att skriva egna regler — du kan definiera ett säkerhetsmönster på några rader och köra det över hela kodbasen. Semgrep är idealiskt för team som vill ha snabb feedback utan tung konfiguration. För mindre svenska SaaS-team är Semgrep + Dependabot ofta en tillräcklig SAST-lösning.

Container-säkerhet i CI/CD

Containrar introducerar unika säkerhetsutmaningar: bas-images kan innehålla sårbarheter, hemligheter kan läcka in i images, och containrar som körs som root ökar attackytan. Container-säkerhet börjar i byggkedjan: skanna bas-images vid import (Trivy, Docker Scout), skanna byggda images före publicering till registry, och skanna images i registry regelbundet för nya sårbarheter.

Implementation i CI/CD: efter image-build, kör trivy image och blockera deployment om kritiska sårbarheter upptäcks. Använd en image signing-mekanism (Cosign) för att säkerställa att endast godkända images deployas. För svenska team som använder Azure: Azure Container Registry har inbyggd sårbarhetsscanning via Microsoft Defender for Cloud — aktivera den och konfigurera aviseringar.

Sårbarhetshantering — prioritera och åtgärda

Att upptäcka sårbarheter är bara halva arbetet — den verkliga utmaningen är att prioritera och åtgärda dem effektivt. Ett typiskt medelstort SaaS-företag kan ha hundratals eller tusentals detekterade sårbarheter från SAST, SCA och DAST. Att försöka åtgärda allt är varken praktiskt eller kostnadseffektivt — du måste prioritera baserat på allvarlighetsgrad, exploaterbarhet och affärspåverkan.

Prioriteringsramverk: CVSS-score (Common Vulnerability Scoring System) för teknisk allvarlighetsgrad, EPSS (Exploit Prediction Scoring System) för sannolikhet att sårbarheten exploateras inom 30 dagar, och affärskontext (exponerad mot internet? innehåller känslig data?). Kombinera dessa för att skapa en riskbaserad prioriteringslista. Sätt SLA:er: kritisk (åtgärda inom 24–48 timmar), hög (1 vecka), medel (1 månad), låg (nästa release).

Secrets scanning — hitta läckta hemligheter

Secrets scanning är en av de mest värdefulla säkerhetsåtgärderna du kan implementera. Det innebär att automatiskt söka efter API-nycklar, lösenord, tokens och certifikat i din kod före commits och i dina repos historik. GitHub har inbyggt secrets scanning för alla offentliga repos (kostnadsfritt) och för privata repos med GitHub Advanced Security. GitLeaks, TruffleHog och ggshield är populära CLI-verktyg.

För svenska team rekommenderar vi att implementera pre-commit hooks med GitLeaks (blockerar commits med hemligheter), aktivera GitHub Secrets Scanning (får automatiska varningar om hemligheter upptäcks i repos), och köra periodiska genomsökningar av hela repo-historiken (för att hitta hemligheter som redan läckt). Om en hemlighet upptäcks: rotera den omedelbart, granska åtkomstloggar, och utred hur den läckte.

API-säkerhetstestning

API:er är 2026 den vanligaste attackytan, och API-säkerhetstestning kräver specialiserade verktyg och tekniker. OWASP API Security Top 10 är utgångspunkten för att identifiera API-specifika risker. DAST-verktyg som OWASP ZAP och Burp Suite har specialiserade API-scanning-lägen som tolkar OpenAPI-specifikationer och GraphQL-scheman för att generera riktade tester.

För svenska team som bygger API:er rekommenderar vi att integrera API-säkerhetstestning i CI/CD: importera din OpenAPI-specifikation till ZAP, kör automatiserade API-tester vid varje pull request, och komplettera med en årlig manuell pentest av API-flöden. Läs mer om API-säkerhet för detaljerade riktlinjer.

Säkerhetstestning för mobila appar

Mobila applikationer kräver en utökad säkerhetstestningsstrategi som täcker både klient- och serversidan. För iOS och Android: kör SAST med MobSF (Mobile Security Framework), testa lokal datalagring (Keychain, SharedPreferences), kontrollera nätverkssäkerhet (certifikatpinning, TLS-versioner), och testa sidoladdningssäkerhet. Använd Burp Suite som proxy för att testa API-kommunikation från mobilappen.

Rapportering och compliance

Säkerhetstestning är värdelös utan tydlig rapportering och uppföljning. Varje testomgång bör generera en rapport som listar: testade områden, hittade sårbarheter med CVSS-score och åtgärdsförslag, tidigare sårbarheter som åtgärdats, och kvarvarande risker med accepterad risk. För NIS2, SOC 2 och ISO 27001 krävs dokumenterade säkerhetstestningsprocesser och bevis på att tester genomförs regelbundet.

Slutsats

Säkerhetstestning 2026 är en kontinuerlig process som integreras i hela utvecklingskedjan — inte en engångsinsats före release. SAST, DAST, SCA och manuell penetrationstestning kompletterar varandra och fångar olika typer av sårbarheter. Nyckeln är att bygga en DevSecOps-pipeline som automatiskt kör rätt typ av testning vid rätt tillfälle, prioritera sårbarheter baserat på risk snarare än antal, och dokumentera allt för compliance. Börja med secrets scanning och SCA (störst effekt minst ansträngning), lägg till SAST, och komplettera med DAST och pentest för kritiska system.

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

Att upptäcka sårbarheter är bara halva arbetet — prioritera baserat på risk, exploaterbarhet och affärspåverkan, inte på antal.

- Simon Axelsson

Vanliga frågor

Vad är skillnaden mellan SAST och DAST?
SAST (Static Analysis) granskar källkod utan att köra den — hittar problem tidigt men kan ge falska positiva. DAST (Dynamic Analysis) testar en körande applikation utifrån — hittar runtime-problem men kräver en deployad applikation. Båda kompletterar varandra och bör användas tillsammans.
Vilket SCA-verktyg ska jag välja?
Dependabot (inbyggt i GitHub) är kostnadsfritt och räcker för de flesta team som grundskydd. Snyk erbjuder djupare analys med prioritering och fix-förslag — bra för organisationer med compliance-krav. GitLab har inbyggt SCA i Ultimate-versionen.
Hur ofta bör jag penetrationstesta?
Minst årligen och efter större förändringar. För system som hanterar känslig data eller omfattas av NIS2: minst två gånger per år. API-tjänster och ny funktionalitet bör pentestas före lansering.
Vad kostar en penetrationstest?
En pentest för en typisk webbapplikation kostar 30 000–80 000 SEK beroende på omfattning, antal endpoints och testarens erfarenhet. API-pentest är billigare (15 000–40 000 SEK). Se vår <a href='/tjanster/pentest-pris-guide'>prisguide för pentest</a>.
Måste jag åtgärda alla hittade sårbarheter?
Nej, prioritera baserat på risk. En sårbarhet i en intern administrationsfunktion utan känslig data är mindre allvarlig än en kritisk sårbarhet i en internetexponerad API-endpoint. Acceptera lågrisk-sårbarheter med dokumentation. Sätt SLA:er: kritisk 24–48h, hög 1 vecka, medel 1 månad.

Om författaren

Simon Axelsson
Simon AxelssonIT-konsult & teknisk rådgivare

Simon Axelsson är senior IT-konsult och grundare av SIAX Technology AB. Han hjälper nordiska företag med molninfrastruktur, dataplattformar och AI-automation.

Fler artiklar av Simon