White box pentest: så testar du system inifrån
Group COO & CISO
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
White box pentest: så testar du system inifrån
White box pentest innebär att säkerhetstestare får fullständig tillgång till källkod, arkitektur och dokumentation innan de angriper systemet. Metoden hittar logikfel, hårdkodade hemligheter och arkitekturbrister som black box-testning systematiskt missar. För svenska organisationer som omfattas av NIS2-direktivet är det en av de mest effektiva åtgärderna för att dokumentera proaktiv riskhantering — och faktiskt hitta de sårbarheter som angripare utnyttjar i praktiken.
Viktiga slutsatser
- White box pentest ger testare full tillgång till källkod, arkitektur och dokumentation — det avslöjar brister som black box aldrig når
- Metoden är särskilt värdefull för att uppfylla NIS2-direktivets krav på proaktiv riskhantering och dokumenterad säkerhetstestning
- Kombinera statisk kodanalys (SAST) med dynamisk testning för att täcka både logikfel och runtime-sårbarheter
- Planera 3–6 veckor för ett fullständigt white box pentest — det tar längre tid än black box men ger avsevärt djupare resultat
- Integrera white box-testning i CI/CD-pipelinen för kontinuerlig säkerhet, inte bara punktinsatser
Vad innebär white box pentest?
White box pentest — ibland kallat clear box eller glass box testing — är en penetrationstestmetod där testaren arbetar med fullständig insyn i det system som testas. Det betyder konkret att testteamet får:
- Fullständig källkodsåtkomst till alla relevanta repositories
- Arkitekturdiagram som visar systemkomponenter, dataflöden och integrationspunkter
- Databasscheman inklusive relationsmodeller och lagringslogik
- API-specifikationer (OpenAPI/Swagger, gRPC-definitioner)
- Nätverksdiagram med segmentering, brandväggsregler och VPN-konfigurationer
- Åtkomstuppgifter på olika behörighetsnivåer
Den avgörande skillnaden mot andra testmetoder är att testaren inte slösar tid på rekognosering. Istället ägnas hela insatsen åt att systematiskt granska och angripa systemet med samma kunskapsnivå som en utvecklare eller en insider med illvilliga avsikter.
Varför "inifrån och ut" spelar roll
De flesta faktiska dataintrång involverar någon form av insiderinformation — stulna inloggningsuppgifter, komprometterade utvecklarkontor eller en angripare som redan tagit sig förbi perimetern. White box pentest speglar just det scenariot. Testaren frågar inte "kan jag ta mig in?" utan "vad kan jag göra nu när jag är inne?"
Från Opsios SOC ser vi regelbundet incidenter där den initiala intrångsvektorn var trivial, men den verkliga skadan uppstod genom kedjade sårbarheter djupt i applikationslagret — brister som bara syns med källkodsåtkomst.
Vill ni ha expertstöd med white box pentest: så testar du system inifrån?
Våra molnarkitekter hjälper er med white box pentest: så testar du system inifrån — från strategi till implementation. Boka ett kostnadsfritt 30-minuters rådgivningssamtal utan förpliktelse.
White box vs. black box vs. grey box
Valet av testmetod beror på vad du vill uppnå. Här är en ärlig jämförelse:
| Aspekt | White box | Grey box | Black box |
|---|---|---|---|
| Informationsnivå | Full: källkod, arkitektur, credentials | Partiell: viss dokumentation, användarkonton | Ingen: testaren börjar från noll |
| Perspektiv | Insider / utvecklare med illvillig avsikt | Autentiserad användare med begränsad behörighet | Extern angripare utan förkunskap |
| Upptäcktsdjup | Logikfel, hårdkodade hemligheter, arkitekturbrister, race conditions | Behörighetseskalering, IDOR, sessionshantering | Exponerade tjänster, kända CVE:er, konfigurationsfel |
| Tidsåtgång | 3–6 veckor | 2–4 veckor | 1–3 veckor |
| Bäst lämpad för | Kritiska system, compliance-krav, pre-release | Kundportaler, API:er med behörighetssystem | Extern perimetersäkerhet, snabb riskbild |
| Begränsning | Kräver förtroende och NDA, tar längre tid | Hittar inte djupa kodbrister | Missar allt som inte syns utifrån |
Opsios rekommendation: Använd inte bara en metod. Kombinera ett årligt white box pentest av era mest kritiska system med regelbundna black box-tester av den externa attackytan. Det ger både djup och bredd.
Metodik: så genomförs ett white box pentest
Ett välstrukturerat white box pentest följer en tydlig metodik. Vi utgår från OWASP Testing Guide och PTES (Penetration Testing Execution Standard), anpassat för svenska regulatoriska krav.
Fas 1: Scopning och förberedelse (vecka 1)
Innan en enda rad kod granskas behöver scope definieras noggrant:
- Vilka system och komponenter ingår? Var tydlig — "hela plattformen" är inte ett scope.
- Vilka testmiljöer används? Produktionsdata bör undvikas. Staging-miljöer med realistisk data (anonymiserad) är att föredra.
- Vilka regler gäller? Definiera Rules of Engagement: vilka tider testning får ske, vilka attacker som är tillåtna, eskaleringsrutiner vid kritiska fynd.
- Juridiska avtal: NDA, testningsavtal med ansvarsbegränsning, GDPR-överväganden vid hantering av personuppgifter i testmiljö.
Fas 2: Statisk kodanalys (vecka 1–2)
Testarna granskar källkoden utan att köra den. Det handlar om att identifiera:
- Hårdkodade hemligheter: API-nycklar, databaslösenord, krypteringsnycklar som lagras direkt i koden. Verktyg som Semgrep, Gitleaks och TruffleHog automatiserar en del av detta, men manuell granskning hittar obfuskerade varianter.
- Injektionspunkter: SQL injection, XSS, command injection — spåra varje användarinmatning genom kodflödet.
- Kryptografiska brister: Svaga algoritmer (MD5, SHA-1 för lösenord), felaktig nyckelhantering, avsaknad av salt.
- Autentiserings- och auktoriseringslogik: Hur hanteras sessions-tokens? Finns det race conditions i behörighetskontroller? Kan behörighetseskalering uppnås genom att manipulera JWT-claims?
Fas 3: Dynamisk testning (vecka 2–4)
Nu körs systemet, och testarna angriper det aktivt:
- Fuzzing av API-endpoints med manipulerad indata
- Behörighetseskalering — kan en vanlig användare nå admin-funktioner?
- Sessionsmanipulering — sessionsfixering, cookie-tampering, CSRF
- Business logic-testning — kan betalningsflöden manipuleras? Kan man beställa negativa kvantiteter?
- Infrastrukturanalys — Kubernetes-konfigurationer, IAM-policyer i molnet, nätverkssegmentering
Fas 4: Rapportering och åtgärdsplan (vecka 5–6)
En bra pentestrapport är inte en lista med CVE:er. Den ska innehålla:
- Exekutiv sammanfattning för ledning och styrelse (1–2 sidor)
- Tekniska fynd med CVSS-poäng, bevis (screenshots, request/response), och steg-för-steg-reproduktion
- Prioriterad åtgärdslista — vad ska åtgärdas först baserat på faktisk risk, inte bara CVSS-poäng
- Verifieringstest efter åtgärderna — bekräfta att bristerna faktiskt är åtgärdade
Verktyg och tekniker i praktiken
White box pentest kombinerar automatiserade verktyg med manuell expertis. Verktygen ensamma räcker inte — de producerar falska positiver och missar kontextberoende brister. Men utan dem missar du de lågt hängande frukterna.
Statisk analys (SAST)
- SonarQube — bred täckning av språk, bra för kodkvalitet och säkerhetsbrister
- Semgrep — regelbaserad analys, utmärkt för custom rules anpassade till er kodbas
- Checkmarx / Fortify — enterprise-verktyg med djupare dataflödesanalys
- Gitleaks / TruffleHog — specifikt för att hitta hemligheter i Git-historik
Dynamisk analys (DAST) och manuella verktyg
- Burp Suite Professional — branschstandard för webbapplikationstestning
- OWASP ZAP — open source-alternativ med aktiv community
- Nuclei — templatebaserad sårbarhetsskanning
- SQLMap — automatiserad SQL injection-testning
Infrastruktur och molnsäkerhet
- ScoutSuite / Prowler — granskning av AWS/Azure/GCP-konfigurationer
- kube-bench — CIS Benchmark-kontroller för Kubernetes
- Trivy — sårbarhetsskanning av container-images och IaC-filer
NIS2 och regulatoriska krav
NIS2-direktivet, som trädde i kraft i EU under 2024 och implementeras i svensk lagstiftning, ställer explicita krav på organisationer som levererar samhällsviktiga och viktiga tjänster. Artikel 21 kräver bland annat:
- Riskanalys och säkerhetspolicyer för informationssystem
- Incidenthantering med rapporteringskrav
- Kontinuitetsplanering och krishantering
- Säkerhet i leveranskedjan — inklusive era underleverantörers system
- Säkerhetstestning och revisionsrutiner
White box pentest adresserar flera av dessa punkter direkt. Dokumentationen från testet fungerar som revisionsunderlag vid tillsyn från Myndigheten för samhällsskydd och beredskap (MSB) eller sektorsspecifika tillsynsmyndigheter.
ISO 27001-koppling
Organisationer certifierade enligt ISO/IEC 27001 behöver visa att de genomför regelbunden säkerhetstestning som en del av sin riskhanteringsprocess. White box pentest är en av de starkaste åtgärderna för kontrollerna i Annex A relaterade till:
- A.8.8 — Hantering av tekniska sårbarheter
- A.8.25 — Säker utveckling
- A.8.29 — Säkerhetstestning i utveckling och acceptans
Vanliga misstag vi ser
Från Opsios praktiska erfarenhet av att stödja penetrationstester åt kunder identifierar vi återkommande fallgropar:
1. Scope som är för brett eller för vagt. "Testa allt" leder till ytlig analys. Avgränsa till de system som bär störst risk — det som hanterar betalningar, personuppgifter eller styr kritisk infrastruktur.
2. Ingen åtgärdsprocess efter testet. Ett pentest utan uppföljning är bortkastad budget. Definiera ansvarig, tidplan och verifieringstest innan testet ens börjar.
3. Testning bara i staging, aldrig produktionslikt. Om staging-miljön saknar realistisk konfiguration (WAF, nätverkssegmentering, aktiva säkerhetskontroller) missar testet hela klasser av brister. Testa i en miljö som speglar produktion.
4. Fokus på verktygsrapporter istället för affärsrisk. En "critical" CVSS-sårbarhet i ett internt system utan exponering mot internet är inte nödvändigtvis det viktigaste att åtgärda. Prioritera baserat på faktisk attackyta och skyddsvärde.
Integrera white box-testning i utvecklingsprocessen
Det mest effektiva sättet att arbeta med white box pentest är att inte behandla det som en engångsinsats. Bygg in det i er utvecklingslivscykel:
1. Automatiserad SAST i CI/CD — Semgrep eller SonarQube körs vid varje pull request. Blockera merge vid kritiska fynd.
2. DAST i staging-pipeline — OWASP ZAP eller Nuclei skannar automatiskt efter deploy till staging.
3. Manuellt white box pentest vid större releaser, arkitekturförändringar eller minst en gång per år.
4. Threat modeling vid design av nya funktioner — identifiera potentiella brister innan koden skrivs.
Den här kombinationen ger kontinuerlig säkerhet istället för ögonblicksbilder. Enligt CNCF:s årliga undersökning ökar andelen organisationer som integrerar säkerhetstestning direkt i sina CI/CD-pipelines stadigt — och de som gör det upptäcker brister veckor eller månader tidigare.
Cloud FinOps och kostnadsoptimering
Så väljer du rätt pentestpartner
Alla pentestare är inte likvärdiga. Här är vad som faktiskt spelar roll:
- Certifieringar som visar praktisk förmåga: OSCP, OSCE, CREST CRT/CCT. Undvik leverantörer som bara kör automatiserade skanningar och kallar det pentest.
- Erfarenhet av er tekniska stack: En testare som aldrig sett Kubernetes eller AWS IAM-policyer kommer missa molnspecifika brister.
- Rapportkvalitet: Be om en exempelrapport (anonymiserad). Den ska innehålla reproduktionssteg, affärsriskbedömning och konkreta åtgärdsförslag — inte bara verktygsoutput.
- Verifieringstest inkluderat: Seriösa leverantörer inkluderar en omtest-fas efter åtgärderna.
- Kommunikation under testet: Kritiska fynd ska rapporteras omedelbart, inte efter tre veckors tystnad.
Vad kostar ett white box pentest?
Kostnad beror på scope, men räkna med ungefär följande storleksordning för den svenska marknaden:
| Scope | Typisk tidsåtgång | Prisintervall (SEK) |
|---|---|---|
| Enskild webbapplikation | 2–3 veckor | 150 000–300 000 |
| Webbapplikation + API + mobilapp | 3–5 veckor | 300 000–600 000 |
| Komplex plattform med infrastruktur | 4–8 veckor | 500 000–1 200 000 |
Jämfört med kostnaden för ett dataintrång — som enligt IBM:s Cost of a Data Breach-rapport konsekvent visar genomsnittskostnader i miljonklassen — är det en försvarbar investering. Särskilt för organisationer som hanterar personuppgifter under GDPR, där IMY kan utdöma sanktionsavgifter på upp till 20 miljoner EUR eller 4 % av global omsättning.
Vanliga frågor
Vad skiljer white box pentest från grey box pentest?
I ett grey box pentest har testaren begränsad information — exempelvis användaruppgifter och viss dokumentation, men inte fullständig källkodsåtkomst. White box ger total insyn: källkod, arkitekturdiagram, databasscheman och API-specifikationer. Grey box simulerar en insider med begränsad behörighet, medan white box möjliggör en komplett kodgranskning.
Hur ofta bör vi genomföra white box pentest?
Minst årligen, plus vid större releaser eller arkitekturförändringar. NIS2-direktivet kräver regelbunden säkerhetstestning av samhällsviktiga tjänster. Organisationer med snabba releascykler bör komplettera med automatiserad SAST/DAST i CI/CD-pipelinen och göra manuella white box-tester vid större förändringar.
Räcker inte automatiserade verktyg istället för manuellt pentest?
Automatiserade verktyg som SonarQube eller Semgrep fångar kända sårbarhetsmönster effektivt, men missar affärslogiska brister, komplex autentiseringslogik och kedjade sårbarheter. Manuellt white box pentest hittar de brister som kräver mänsklig förståelse av systemets kontext och syfte. Bäst resultat får du genom att kombinera båda.
Vilka risker finns med att ge testare full källkodsåtkomst?
Det kräver starkt förtroende och juridiska skyddsmekanismer. Upprätta alltid NDA och tydliga avtal om datahantering. Ge åtkomst via säkra miljöer — inte kopior av produktionsdata. Välj testare med dokumenterad erfarenhet och relevant certifiering (OSCP, CREST). På Opsio arbetar vi med segmenterad åtkomst och loggning av alla aktiviteter under testet.
Uppfyller white box pentest kraven i NIS2-direktivet?
NIS2 kräver att organisationer som levererar samhällsviktiga tjänster genomför regelbunden riskanalys och säkerhetstestning. White box pentest är en av de mest grundliga metoderna för att uppfylla dessa krav, särskilt artikel 21 om tekniska säkerhetsåtgärder. Dokumentationen från testet fungerar dessutom som revisionsunderlag.
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.
