OWASP ZAP: Automatisera Säkerhetstester i 13 Steg [2026]

ZAP fyller en tydlig lucka i verktygslådan: det är gratis, öppet och byggt för att köras automatiskt i varje pull request, till skillnad från kommersiella proxyverktyg som kräver en analytiker vid tangentbordet. Den 15 december 2025 släppte projektet OWASP ZAP 2.17.0, och sedan dess har verktyget fått både ett Automation Framework som mognat rejält och ett helt nytt tillägg för att testa AI-drivna applikationer. Den här guiden går igenom hur du installerar ZAP, bygger ett automatiserat testschema och kopplar in det i en CI/CD-pipeline, steg för steg.

Många team lägger säkerhetstestning sist i utvecklingscykeln, ofta som en manuell kontroll strax före lansering. Problemet är att fel som upptäcks sent är dyrare att åtgärda och lättare att fuska bort under tidspress. Dynamisk säkerhetstestning (DAST) med ett verktyg som ZAP löser det genom att flytta testningen till varje commit i stället för till slutet av en release. Skillnaden mot statisk kodanalys är att ZAP faktiskt anropar en körande applikation, precis som en riktig besökare eller angripare skulle göra, vilket gör att det hittar fel som bara syns i det färdiga systemets beteende.

Målet är ett komplett arbetsprojekt: en testapplikation, ett YAML-baserat automationsschema, en Docker-uppsättning och en färdig GitHub Actions-pipeline som stoppar en build om ZAP hittar allvarliga brister. Räkna med att avsätta ungefär 90 minuter om du följer med steg för steg på din egen maskin, och lite längre om du samtidigt anpassar konfigurationen efter din egen applikation.

Vad är OWASP ZAP och varför spelar det roll hösten 2026

Zed Attack Proxy, förkortat ZAP, är en dynamisk säkerhetsskanner (DAST) som fungerar som en mellanhand mellan din webbläsare eller dina testskript och applikationen du undersöker. Verktyget föddes ur OWASP-stiftelsens projektportfölj, men drivs numera under den fristående organisationen Software Security Project. Namnet “OWASP ZAP” lever kvar i dagligt tal och i sökresultat, även om projektet formellt är fristående från stiftelsen. Det ändrar inte hur verktyget används i praktiken, men förklarar varför dokumentationen ibland refererar till “Software Security Project” snarare än OWASP direkt.

Enligt ZAP-projektets egen statistik startades verktyget nästan 10 miljoner gånger bara under april 2026, och huvudförrådet på GitHub passerade 15 000 stjärnor samma månad. Det säger något om hur pass inbakat ZAP är i dagliga CI/CD-flöden snarare än att vara ett verktyg som körs manuellt en gång per kvartal. Två saker gör ZAP särskilt relevant just nu: dels att version 2.17.0 anpassade sina regelkategorier efter OWASP Top 10:2025, den uppdaterade och omstrukturerade listan över de vanligaste webbriskerna, dels att ett nytt tillägg för att granska AI-drivna gränssnitt (LLM Support) officiellt lanserades i augusti 2026.

Om du redan använder Burp Suite för manuell penetrationstestning kompletterar ZAP det arbetet snarare än att ersätta det. Burp Suite passar bäst för en person som aktivt undersöker en applikation, medan ZAP är byggt för att köras obevakat, natt efter natt, i en pipeline. Har du inte läst vår guide till API-säkerhetstestning med Burp Suite är det en bra jämförelsepunkt innan du bestämmer vilket verktyg som passar ditt team.

Projektet drivs i dag av en öppen grupp utvecklare snarare än ett enskilt bolag, och du kan följa releaser och tekniska diskussioner direkt på zaproxy.org. Just för att projektet är community-drivet uppdateras det ofta i små steg, ibland flera tilläggsuppdateringar per månad, snarare än stora versionshopp en gång per år. Det är värt att ha i bakhuvudet när du bygger en pipeline som ska hålla över tid.

För team som redan har byggt upp en bredare säkerhetsverktygskedja är ZAP sällan det enda verktyget i pipelinen. Ett vanligt mönster är att låta statisk analys och beroendeskanning köras tidigt i pull requesten, medan ZAP körs mot en uppstartad testmiljö senare i samma pipeline, ungefär som beskrivs mer generellt i vår genomgång av säkerhetsverktyg och sårbarhetshantering. Poängen är att DAST, SAST och beroendeskanning täcker olika delar av attackytan, och att inget enskilt verktyg ger fullständig täckning på egen hand.

Skanningstyperna i ZAP: spindel, aktiv, passiv och AJAX

Innan du börjar klicka runt i gränssnittet är det värt att förstå vilka fyra grundläggande tekniker ZAP bygger på, eftersom de styr hur aggressivt verktyget beter sig mot målet. Samtliga fyra går att styra både från skrivbordsgränssnittet, som ett kommandoradsflaggat skript, och som ett enskilt jobb i ett Automation Framework-schema, vilket betyder att du kan börja utforska dem interaktivt innan du låser fast beteendet i en automatiserad pipeline.

Skanningstyp	Vad den gör	Risknivå	Typisk användning
Spindel (Spider)	Följer länkar och formulär för att kartlägga applikationens struktur	Låg	Första kartläggningen av en okänd applikation
AJAX-spindel	Kör en riktig webbläsarmotor för att hitta innehåll som laddas via JavaScript	Låg till medel	Ensidesapplikationer (SPA) byggda i React, Vue eller liknande
Passiv skanning	Analyserar trafik som redan passerar ZAP utan att skicka egna anrop	Ingen	Säkerhetshuvuden, kakor, informationsläckage, körs alltid i bakgrunden
Aktiv skanning	Skickar manipulerade förfrågningar för att provocera fram fel	Hög	SQL-injektion, XSS, kommandoinjektion – endast mot testmiljöer

Den vanliga missuppfattningen är att en “skanning” i ZAP alltid innebär aktiv testning. I praktiken kombinerar de flesta pipelines en snabb baslinjeskanning (spindel plus passiv analys) på varje pull request, och sparar den fullständiga aktiva skanningen till en nattlig körning eller en dedikerad testmiljö. Det är samma logik som ligger bakom containerskanning med verktyg som Trivy: snabb feedback vid varje commit, djupare analys mer sällan.

Passiv skanning förtjänar extra uppmärksamhet eftersom den ofta underskattas. Den körs kontinuerligt i bakgrunden så fort trafik passerar genom ZAP, utan att skicka en enda extra förfrågan, och fångar ändå upp saker som saknade säkerhetshuvuden, kakor utan Secure– eller HttpOnly-flaggor och information som läcker i felmeddelanden. Många team börjar sin ZAP-resa med enbart passiv analys eftersom risken för sidoeffekter är noll, och lägger till aktiv skanning först när de har byggt förtroende för verktyget.

Förkrav: versioner och verktyg du behöver

• OWASP ZAP 2.17.0 eller senare (senaste stabila release, publicerad 15 december 2025)
• Java 17 eller senare om du kör skrivbordsversionen direkt – enligt ZAP:s egen installationsguide krävs Java 17+ för att starta programmet, medan Docker-versionerna inte kräver separat Java-installation
• Docker Engine 24 eller senare, för att köra de officiella avbildningarna zaproxy/zap-stable eller ghcr.io/zaproxy/zaproxy:stable
• Git och ett GitHub- eller GitLab-konto om du vill följa CI/CD-avsnittet
• En testapplikation att skanna – i den här guiden används en enkel lokal webbapp, men du kan ersätta den med din egen testmiljö
• En OpenAPI- eller Swagger-specifikation om du vill följa API-skanningsavsnittet
• Grundläggande YAML-kunskap för Automation Framework-schemat
• Cirka 90 minuters sammanhängande tid

Du behöver inte ha alla delar på plats för att komma igång. De flesta läsare börjar med enbart skrivbordsversionen och en lokal testapplikation, för att sedan lägga till Docker och CI/CD-integrationen när de grundläggande koncepten sitter. Försöker du bygga hela kedjan på en gång blir felsökningen svårare, eftersom du då inte vet om ett problem beror på ZAP-konfigurationen, Docker-nätverket eller CI-plattformens egenheter.

Skanna aldrig en applikation du inte äger eller har skriftligt tillstånd att testa. Aktiv skanning skickar samma sorts payloads som en angripare skulle använda, och kan i värsta fall skriva data, skapa konton eller trigga varningar hos en tredje part. Har du en molnmiljö i AWS, Azure eller GCP är det också värt att säkerställa att testmiljön i sig är korrekt konfigurerad innan du börjar, annars riskerar du att jaga symptom som egentligen beror på felkonfigurerad molninfrastruktur snarare än brister i själva applikationskoden.

Steg 1–2: Installera OWASP ZAP 2.17.0 och verifiera Java

Ladda ner installationsfilen för ditt operativsystem från ZAP:s officiella nedladdningssida, eller hoppa direkt till Docker-varianten längre ner om du föredrar att slippa hantera Java lokalt. macOS-installeraren buntar en lämplig Java-version, men på Windows och Linux måste du installera Java 17 eller senare separat innan ZAP startar.

# Verifiera att rätt Java-version är installerad
java -version
# Förväntad utskrift bör visa version 17 eller högre, till exempel:
# openjdk version "21.0.4" 2024-07-16

# Alternativ: hoppa över lokal Java och hämta Docker-avbildningen direkt
docker pull zaproxy/zap-stable
docker run --rm -t zaproxy/zap-stable zap.sh -version

Om java -version visar en äldre version, eller kommandot inte hittas alls, är det enklare att gå Docker-vägen än att jonglera flera Java-installationer på samma maskin. Det sparar dig även från ett av de vanligaste felen nya användare stöter på, som vi återkommer till i felsökningsavsnittet. Fullständiga installationsanvisningar per plattform, inklusive kontrollsummor för nedladdningen, finns på ZAP:s officiella startguide.

Kör du aktiv skanning mot en större applikation är det värt att i förväg höja hur mycket minne Java-processen får använda, eftersom standardinställningen annars kan bli en flaskhals vid stora webbplatsträd. Det gör du genom att lägga till en -Xmx-flagga när du startar ZAP från kommandoraden, till exempel -Xmx2048m för att ge processen 2 GB heap-minne i stället för standardvärdet.

En körd docker run-kommando ovan bör ge en utskrift som ser ut ungefär så här, vilket bekräftar att avbildningen laddats ner och att ZAP kan starta korrekt:

Unable to find image 'zaproxy/zap-stable:latest' locally
latest: Pulling from zaproxy/zap-stable
Digest: sha256:1a2b3c4d5e6f...
Status: Downloaded newer image for zaproxy/zap-stable:latest
2.17.0

Steg 3–4: Sätt upp kontext, scope och en testmålsapp

När ZAP startar möts du av tre huvudvyer: webbplatsträdet till vänster, förfrågnings- och svarsdata i mitten och larmlistan längst ner. Innan du skannar något bör du skapa en kontext, en avgränsning av vilka URL:er som faktiskt ingår i testet. Utan en definierad scope riskerar en spindel att följa länkar ut till helt andra domäner, vilket både förlänger testtiden och kan innebära att du oavsiktligt skannar tredjepartstjänster.

Gå till Context-menyn, skapa en ny kontext, och lägg till ett inkluderande regex för ditt måldomän, till exempel https://din-testapp\.lokal.*. Om applikationen har ett inloggningsflöde du inte vill testa i det här steget, lägg till motsvarande URL:er i exkluderingslistan. Detta scope-arbete är grunden för allt som följer, inklusive Automation Framework-schemat i steg 8.

Ett vanligt nybörjarmisstag är att blanda ihop “include” och “exclude” i regexlistan, vilket antingen gör att spindeln inte hittar någonting alls eller att den svämmar över i tusentals irrelevanta sidor. Testa gärna scope-inställningen genom att högerklicka på en enskild sida i webbplatsträdet och välja “Spindla den här noden” innan du kör en fullständig skanning mot hela applikationen. Det ger snabb feedback på om regexet faktiskt fångar rätt URL-mönster, utan att du behöver vänta på en hel körning för att upptäcka ett stavfel i uttrycket.

Steg 5–6: Kör en baslinjeskanning och en full aktiv skanning

Baslinjeskanningen är den säkraste startpunkten. Den kör spindeln i några minuter och samlar sedan in resultat från passiv analys, utan att skicka en enda potentiellt skadlig payload. Det gör den lämplig att köra mot i princip vilken miljö som helst, inklusive produktion, även om det fortfarande är bäst praxis att rikta den mot en testmiljö.

# Baslinjeskanning via Docker – passiv, säker att köra ofta
docker run --rm -t zaproxy/zap-stable zap-baseline.py \
  -t https://din-testapp.lokal \
  -r baseline-rapport.html

# Full aktiv skanning – endast mot testmiljöer
docker run --rm -t zaproxy/zap-stable zap-full-scan.py \
  -t https://din-testapp.lokal \
  -r full-rapport.html \
  -j

Flaggan -j i det andra kommandot aktiverar AJAX-spindeln, vilket är värt att slå på om din applikation är byggd som en SPA. Den fullständiga aktiva skanningen tar betydligt längre tid, ofta 20 minuter till flera timmar beroende på applikationens storlek, eftersom ZAP nu faktiskt skickar payloads mot varje identifierad ingångspunkt och väntar in svaren.

När baslinjeskanningen är klar skriver ZAP en sammanfattning till terminalen innan HTML-rapporten sparas. En typisk körning mot en okänd applikation ser ut ungefär så här:

PASS: Cookie No HttpOnly Flag [10010]
PASS: Absence of Anti-CSRF Tokens [10202]
WARN-NEW: Content Security Policy (CSP) Header Not Set [10038] x14
WARN-NEW: X-Content-Type-Options Header Missing [10021] x9
WARN-NEW: Server Leaks Version Information [10036] x3
FAIL-NEW: 0	FAIL-EXIST: 0	WARN-NEW: 3	WARN-EXIST: 0	INFO: 2	IGNORE: 0	PASS: 46

Lägg märke till att baslinjeskanningen i standardläge inte fäller bygget även om den hittar varningar (WARN-NEW), bara faktiska fel (FAIL-NEW). Vill du att pipelinen ska stoppa builden redan vid varningar behöver du antingen höja tröskelvärdet med flaggan -I för att ignorera skillnaden, eller definiera det explicit i din Automation Framework-konfiguration, vilket vi går igenom i nästa steg. Fullständig dokumentation för Docker-varianterna finns i ZAP:s Docker-guide.

Steg 7: Mappa larm mot OWASP Top 10:2025

OWASP uppdaterade sin lista över de tio vanligaste webbriskerna under 2025, och strukturen skiljer sig en del från tidigare versioner. Att förstå vilka kategorier ZAP faktiskt kan täcka automatiskt, och vilka som kräver manuellt arbete, hjälper dig sätta rimliga förväntningar på vad en grön ZAP-rapport egentligen betyder.

OWASP Top 10:2025	ZAP-täckning
A01: Broken Access Control	Kräver autentiserade roller och definierade testflöden – ZAP hittar inte detta ur lådan
A02: Security Misconfiguration	God täckning via passiva regler för säkerhetshuvuden och TLS-konfiguration
A03: Software Supply Chain Failures	Begränsad – ZAP testar körande applikationer, inte beroendekedjan (använd i stället OSV-Scanner)
A04: Cryptographic Failures	Delvis – upptäcker exponerad känslig data och svag TLS-konfiguration
A05: Injection	Stark täckning – SQL-injektion, XSS och kommandoinjektion är kärnfunktioner i aktiv skanning
A06: Insecure Design	Kräver manuell granskning av affärslogik, ligger utanför automatiserad skanning
A07: Authentication Failures	Kan testas när autentiserade sessioner och testkonton är korrekt konfigurerade
A08: Software or Data Integrity Failures	Begränsad och kontextberoende täckning
A09: Security Logging and Alerting Failures	ZAP kan inte bekräfta att intern loggning fungerar korrekt
A10: Mishandling of Exceptional Conditions	Vissa felhanterings- och informationsläckageproblem upptäcks

Slutsatsen är enkel men viktig: en ren ZAP-rapport bevisar inte att applikationen är fri från alla Top 10-risker, bara att de kategorier ZAP faktiskt kan testa automatiskt inte slog larm. För åtkomstkontroll och affärslogik behöver du fortfarande manuell testning eller riktade testfall, gärna i kombination med JWT- och BOLA-testning för API-lager. Den fullständiga och uppdaterade listan med alla underkategorier finns på top10.owasp.org, och det är värt att läsa igenom originalkällan snarare än att bara luta sig mot en sammanfattning, eftersom OWASP löpande förtydligar definitionerna.

Steg 8–9: Bygg ett Automation Framework-schema och kör ZAP i Docker

Automation Framework är ZAP:s YAML-baserade sätt att beskriva en hel testkörning: vilken kontext som ska användas, vilka jobb som ska köras i vilken ordning, och vad som ska hända med resultatet. Det ingår i den senaste ZAP-versionen och i den stabila Docker-avbildningen, och är tänkt att på sikt bli det primära sättet att styra ZAP snarare än enskilda kommandoradsflaggor. Automation Framework-tillägget nådde version 0.59.0 i aprilbygget 2026, med nya funktioner som stöd för att läsa in ett schema direkt från urklipp och åtkomst till förloppet för långkörande jobb.

env:
  contexts:
    - name: "TestApp"
      urls: ["https://din-testapp.lokal"]
      includePaths: ["https://din-testapp\\.lokal.*"]
  parameters:
    failOnError: true
    progressToStdout: true

jobs:
  - type: spider
    parameters:
      context: "TestApp"
      maxDuration: 5

  - type: passiveScan-wait
    parameters:
      maxDuration: 5

  - type: activeScan
    parameters:
      context: "TestApp"
      policy: "Default Policy"

  - type: report
    parameters:
      template: "traditional-html"
      reportDir: "/zap/wrk/"
      reportFile: "zap-rapport"

Spara filen som zap.yaml och kör den mot den stabila Docker-avbildningen. Notera att Docker Hub-organisationen för ZAP:s officiella avbildningar bytte namn från softwaresecurityproject till zaproxy i samband med 2.15-releasen, så använd alltid det nya namnet i nya pipelines.

docker run -v "$(pwd):/zap/wrk/:rw" -t zaproxy/zap-stable \
  zap.sh -cmd -autorun /zap/wrk/zap.yaml

Fördelen jämfört med de färdigpaketerade skripten (zap-baseline.py, zap-full-scan.py) är att du med Automation Framework kan kombinera flera jobbtyper, återanvända samma schema lokalt och i CI, och testa det i skrivbordsgränssnittet innan du kör det obevakat. Utöver spider, passiveScan-wait, activeScan och report finns bland annat jobbtyperna openapi för att importera en API-specifikation, alertFilter för att tona ner specifika regel-ID:n innan rapporten skrivs, och det nyare mcp-import-jobbet som vi går igenom i avsnittet om avancerade tips. Full referens över samtliga jobbtyper och deras parametrar finns i Automation Framework-dokumentationen.

Ett vanligt nybörjarfel med YAML-scheman i allmänhet, inte bara i ZAP, är att blanda tabbar och mellanslag för indentering. YAML tolererar bara mellanslag, och en enda felplacerad tabb kan göra att hela filen misslyckas att laddas utan ett tydligt felmeddelande om exakt vilken rad som är fel. Validera schemat med ett fristående YAML-lintverktyg innan du felsöker inne i ZAP, det sparar ofta tio minuters onödigt letande.

Steg 10: Skanna ett API från en OpenAPI-specifikation

Om det du testar är ett API snarare än en traditionell webbapplikation är API-skanningen mer träffsäker än en generisk spindel, eftersom den importerar din OpenAPI- eller Swagger-definition och därmed känner till exakt vilka endpoints, parametrar och datatyper som finns, utan att behöva gissa sig fram genom att följa länkar.

docker run --rm -t zaproxy/zap-stable zap-api-scan.py \
  -t https://din-testapp.lokal/openapi.json \
  -f openapi \
  -r api-rapport.html

Typiska fynd här är saknade säkerhetshuvuden, endpoints utan hastighetsbegränsning, och parametrar som saknar indatavalidering. Kombinerar du detta med GraphQL i din stack är det värt att också läsa vår genomgång av GraphQL-säkerhet i Node.js, eftersom ZAP:s OpenAPI-import inte fångar GraphQL-scheman på samma sätt.

Terminalutskriften från en API-skanning listar hur många endpoints som importerades innan testningen ens börjar, vilket är ett bra sätt att snabbt upptäcka om specifikationen var ofullständig:

Total of 2 URLs
Importing an OpenAPI definition from https://din-testapp.lokal/openapi.json
Found 23 endpoints across 6 tags
Number of URLs found: 41
FAIL-NEW: 1	WARN-NEW: 7	PASS: 28

Ser du ett betydligt lägre antal endpoints än du förväntar dig är den vanligaste orsaken att specifikationsfilen är föråldrad eller att autentiseringen som krävs för att nå vissa delar av API:t inte har konfigurerats i skanningen.

Steg 11: Integrera ZAP i GitHub Actions och GitLab CI

De paketerade skanningarna har motsvarande officiella GitHub Actions, vilket gör integrationen betydligt enklare än att skriva egna Docker-anrop i workflow-filen. Använd alltid en pinnad versionstagg snarare än @main, så att en uppdatering i ZAP-projektet inte plötsligt bryter din pipeline mitt i natten.

name: ZAP-sakerhetsskanning

on:
  pull_request:
  schedule:
    - cron: "0 2 * * 1"

jobs:
  zap_scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Starta applikationen
        run: docker compose up -d

      - name: ZAP baslinjeskanning
        uses: zaproxy/[email protected]
        with:
          target: "http://localhost:8080"
          fail_action: true

      - name: ZAP full aktiv skanning (endast schemalagd körning)
        if: github.event_name == 'schedule'
        uses: zaproxy/[email protected]
        with:
          target: "http://localhost:8080"

Kör du GitLab i stället för GitHub finns ingen motsvarande officiell action, men samma logik fungerar utmärkt som ett rakt Docker-jobb:

zap_baseline:
  image: zaproxy/zap-stable
  stage: security
  script:
    - zap-baseline.py -t "$DAST_TARGET" -r zap-rapport.html
  artifacts:
    when: always
    paths:
      - zap-rapport.html

Mönstret som fungerar bäst i praktiken: baslinjeskanning på varje pull request med fail_action: true så bygget stoppas vid nya högriskfynd, och en fullständig aktiv skanning en gång i veckan mot en dedikerad testmiljö, eftersom den tar för lång tid för att köras på varje commit.

Både action-baseline och action-full-scan kan konfigureras att automatiskt öppna ett GitHub-ärende för varje nytt fynd, vilket är användbart i mindre team men snabbt kan bli brusigt i större organisationer med många repor. Ett vanligare mönster är att i stället spara HTML-rapporten som ett byggartefakt och länka till den från pull request-kommentaren, så att granskaren kan öppna den fullständiga rapporten utan att behöva gräva i loggar. Generell dokumentation om hur artefakter och statuskontroller fungerar i GitHub Actions finns i GitHubs officiella Actions-dokumentation.

Steg 12–13: Autentiserade skanningar och håll koll på CVE:er

De flesta verkliga applikationer kräver inloggning innan det mest intressanta innehållet blir tillgängligt, och en oautentiserad skanning missar därför en stor del av attackytan. I ett Automation Framework-schema definierar du autentisering som en del av kontexten, antingen via formulärbaserad inloggning, ett skriptat inloggningsflöde, eller genom att injicera en giltig sessionstoken direkt i varje förfrågan.

env:
  contexts:
    - name: "TestApp"
      urls: ["https://din-testapp.lokal"]
      authentication:
        method: "form"
        parameters:
          loginPageUrl: "https://din-testapp.lokal/login"
          loginRequestUrl: "https://din-testapp.lokal/login"
          loginRequestBody: "username={%username%}&password={%password%}"
      users:
        - name: "testanvandare"
          credentials:
            username: "[email protected]"
            password: "ersatt-med-hemlighet-fran-ci"

Lägg aldrig riktiga lösenord i klartext i en fil som checkas in i Git. Använd i stället miljövariabler eller en hemlighetshanterare i din CI-plattform, och skanna gärna hela repot med Gitleaks för att fånga upp eventuella hemligheter som ändå smyger sig in.

Har din applikation tvåfaktorsautentisering eller ett engångskodflöde vid inloggning blir formulärbaserad autentisering opraktisk att automatisera fullt ut. I de fallen är det ofta enklare att skapa en långlivad testtoken eller API-nyckel för en dedikerad testanvändare, och konfigurera ZAP att injicera den som ett auktoriseringshuvud i varje förfrågan i stället för att simulera hela inloggningsflödet. Det kräver visserligen att applikationen stödjer tokenbaserad autentisering vid sidan av det vanliga inloggningsflödet, men sparar avsevärd tid jämfört med att felsöka ett skriptat multi-stegs inloggningsflöde i CI.

Slutligen: ZAP är inte statiskt. Uppdatera tillägg regelbundet via Manage Add-ons i skrivbordsversionen, eller bygg om din Docker-avbildning med jämna mellanrum, eftersom den stabila avbildningen uppdateras varje gång ZAP släpper en ny fullversion. En pipeline som pekar mot en flera månader gammal avbildning missar nya kontroller och kan dessutom sakna stöd för nyare regelkategorier. Vill du hänga med i exakt vad som ändras mellan versioner är releaslistan på GitHub den mest tillförlitliga källan, eftersom den listar varje ändring direkt från projektet självt snarare än via en tredje hands sammanfattning.

Ett bra rutinmässigt tillvägagångssätt är att låta din schemalagda fullskanning även innehålla ett steg som drar en färsk zaproxy/zap-stable-avbildning innan körningen startar, i stället för att förlita sig på en cachad lokal kopia. Det säkerställer att din veckovisa körning alltid använder den senaste regeluppsättningen utan att du manuellt behöver hålla koll på releaser.

Bygg ett komplett arbetsprojekt: exempelapp och pipeline

Sätt ihop allt ovan till en fungerande helhet. Strukturen nedan förutsätter att din applikation redan har en docker-compose.yml, och lägger till ZAP som ett fristående jobb som körs mot den uppstartade tjänsten.

• docker-compose.yml – startar din applikation lokalt på port 8080
• zap/zap.yaml – Automation Framework-schemat från steg 8, med kontext och autentisering från steg 12
• .github/workflows/zap.yml – workflow-filen från steg 11, med schemalagd fullskanning en gång i veckan
• zap/rules.tsv – valfri fil för att tona ner eller ignorera specifika regel-ID:n som ger falska positiva i just din applikation

# Kör hela projektet lokalt, från grunden
docker compose up -d
docker run -v "$(pwd)/zap:/zap/wrk/:rw" --network host -t zaproxy/zap-stable \
  zap.sh -cmd -autorun /zap/wrk/zap.yaml
cat zap/zap-rapport.html | grep -c "Risk=\"High\""

Ett realistiskt utfall efter första körningen mot en applikation som aldrig testats tidigare brukar innehålla en handfull medelrisk-fynd (saknade säkerhetshuvuden som Content-Security-Policy eller X-Frame-Options) och ibland ett eller ett par högriskfynd om formulär saknar CSRF-skydd. Målet första gången är inte en helt tom rapport, utan att etablera en baslinje du kan förbättra över tid.

Ett fungerande projekt bör se ut ungefär så här på disk, med ZAP-relaterade filer samlade i en egen mapp för att hålla dem åtskilda från applikationskoden:

mitt-projekt/
├── docker-compose.yml
├── src/
│   └── ... (applikationskod)
├── .github/
│   └── workflows/
│       └── zap.yml
└── zap/
    ├── zap.yaml
    └── rules.tsv

När du kör hela kedjan för första gången, från ren applikation till färdig rapport, är det värdefullt att spara resultatet som en referenspunkt. Nästa gång du kör samma pipeline kan du jämföra antalet fynd mot den här baslinjen och snabbt se om en ny funktion i koden har introducerat en regression, i stället för att behöva läsa igenom hela rapporten från grunden varje gång.

Vanliga fallgropar när du kör OWASP ZAP

• Att köra full aktiv skanning mot produktion. Aktiv skanning skickar payloads som kan skapa testdata, trigga e-postutskick eller i värsta fall skriva över riktig information. Rikta alltid aktiv skanning mot en isolerad testmiljö.
• Att glömma definiera scope. Utan en avgränsad kontext följer spindeln länkar ut till tredjepartsdomäner, vilket förlänger körtiden kraftigt och kan uppfattas som en attack av en tjänst du inte äger.
• Att förväxla en tom rapport med “säker applikation”. Som tabellen över Top 10:2025 visar täcker ZAP inte åtkomstkontroll eller affärslogik automatiskt. En grön rapport betyder bara att de testade kategorierna klarade sig.
• Att köra aktiv skanning på varje pull request. Det gör pipelinen orimligt långsam. Använd baslinjeskanning för snabb feedback och spara fullskanningen till en schemalagd körning.
• Att ignorera falska positiva helt och hållet. Vissa regler slår an på mönster som är ofarliga i din specifika kontext. Lösningen är att aktivt trimma regeluppsättningen i stället för att sluta läsa rapporterna.
• Att checka in autentiseringsuppgifter i klartext. Automation Framework-scheman innehåller ofta inloggningsdata – hantera dem alltid via miljövariabler eller en hemlighetshanterare, aldrig direkt i YAML-filen som ligger i Git.
• Att anta att en gammal Docker-avbildning fortfarande är aktuell. Den stabila avbildningen uppdateras bara när du faktiskt drar en ny version. En pipeline som cachar avbildningen i flera månader kör i praktiken en förlegad regeluppsättning utan att någon märker det.

Felsökning: de vanligaste problemen och lösningarna

De flesta problem med ZAP handlar antingen om nätverksåtkomst mellan containrar, felkonfigurerad scope, eller en applikation som beter sig annorlunda i CI-miljön jämfört med lokalt. Nedan är de nio problem vi stöter på oftast när läsare hör av sig, tillsammans med den lösning som brukar fungera.

Symptom	Trolig orsak	Lösning
ZAP startar inte, ingen felkod	Fel eller saknad Java-version	Kör java -version och installera Java 17 eller senare, eller byt till Docker-avbildningen
Spindeln hittar nästan inga sidor	Applikationen är en SPA som renderas med JavaScript	Slå på AJAX-spindeln i stället för den vanliga HTML-spindeln
Aktiv skanning tar flera timmar	För bred scope eller för många parametrar per endpoint	Snäva av kontexten, exkludera statiska filer och tredjepartsdomäner
Docker-containern kan inte nå målapplikationen	Nätverksisolering mellan containrar	Använd --network host lokalt, eller sätt båda tjänsterna i samma Docker-nätverk i CI
Autentiserad skanning loggas ut direkt	Sessionen upptäcks inte korrekt av ZAP	Verifiera inloggningsindikatorn (logged-in/logged-out regex) i kontextens autentiseringsinställningar
API-skanningen missar endpoints	OpenAPI-specifikationen är ofullständig eller föråldrad	Generera om specen från din faktiska kodbas innan skanning, inte en manuellt underhållen kopia
GitHub Actions-jobbet timeoutar	Full aktiv skanning körs på varje pull request	Flytta fullskanningen till en schemalagd körning, behåll endast baslinjeskanning på PR
Rapporten är full av lågrisk-brus	Standardregeluppsättningen är inte anpassad efter applikationen	Skapa en anpassad scan policy och tona ner regler som inte är relevanta för din kontext
Automation Framework-schemat felar direkt vid start	Felaktig YAML-indentering eller okänt jobbnamn	Validera YAML-syntaxen separat och jämför jobbnamnen mot aktuell ZAP-dokumentation

Avancerade tips: LLM Support, Client Spider och NIS2-dokumentation

Tre nyare funktioner är värda extra uppmärksamhet om du redan behärskar grunderna. Först: LLM Support-tillägget, som officiellt lanserades i augusti 2026, låter dig rikta ZAP mot applikationer som bygger på språkmodeller och leta efter AI-specifika sårbarheter som prompt injection. Det är särskilt relevant nu när fler team exponerar chattgränssnitt och agentbaserade funktioner mot externa användare.

För det andra lade ZAP-projektet i maj 2026 till stöd för att skanna MCP-servrar (Model Context Protocol), det protokoll som blivit standard för att koppla AI-agenter till externa verktyg. Automation Framework fick ett nytt mcp-import-jobb för detta, och det finns en motsvarande “ZAP MCP Scan”-action för GitHub. Kör du agentbaserade AI-integrationer i din stack är detta troligen din mest relevanta nya attackyta att testa.

För det tredje introducerade ZAP i mars 2026 så kallade “Guided ZAP Scans”, där fynd från statisk kodanalys (SAST) används för att styra den aktiva skanningen mot de mest sannolikt sårbara delarna av applikationen i stället för att testa blint. Det ger snabbare och mer relevant feedback i en pipeline där varje minut räknas.

Ur ett nordiskt perspektiv finns det också ett dokumentationsvärde i regelbundna ZAP-rapporter. Organisationer som omfattas av cybersäkerhetslagen och NIS2 förväntas kunna visa att de har processer för att identifiera och hantera sårbarheter i sina system. En schemalagd ZAP-körning med sparade rapporter, kopplad till en dokumenterad incidentplan, är ett konkret sätt att bygga upp det underlaget över tid utan att det blir ett manuellt engångsprojekt inför en revision.

Läs mer om bakgrunden till Guided ZAP Scans, inklusive hur SAST-fynd faktiskt viktas mot aktiva testfall, direkt i ZAP-teamets blogginlägg från mars 2026. Kombinerar du det med en färdig CVE-bevakningsprocess får du en pipeline som både testar din egen kod aktivt och håller koll på nya sårbarheter i de komponenter du bygger vidare på.

Client Spider är den tredje funktionen värd att nämna. Den ersätter successivt den äldre AJAX-spindeln för moderna JavaScript-ramverk och bygger på en mer robust webbläsarmotor för att rendera och interagera med dynamiskt innehåll. Om din applikation är byggd med ett ramverk som lutar tungt åt klientrendering är det värt att testa Client Spider som ett alternativ redan nu, eftersom den äldre AJAX-spindeln och tillägget för DOM-baserad XSS-detektion enligt ZAP:s septemberuppdatering 2026 successivt fasas ut ur de nattliga och veckovisa byggena.

Ett sista praktiskt tips: spara alltid rapporterna utanför CI-miljön, till exempel i en S3-bucket eller som ett artefaktarkiv med lång retention. Många CI-plattformar rensar byggartefakter efter några veckor, vilket gör att du annars saknar historik precis när en revisor eller ny kollega frågar hur säkerhetsläget har utvecklats över tid.

Vanliga frågor

Är OWASP ZAP verkligen gratis att använda kommersiellt?
Ja. ZAP är öppen källkod och kan användas fritt, inklusive i kommersiella pipelines, utan licenskostnad.

Kan ZAP ersätta en manuell penetrationstestare helt?
Nej. Som tabellen över OWASP Top 10:2025 visar kräver kategorier som åtkomstkontroll och osäker design manuell granskning. ZAP är ett komplement, inte en ersättning för mänsklig expertis.

Vilken skillnad är det egentligen mellan baslinjeskanning och full aktiv skanning?
Baslinjeskanningen kör passiv analys och en enkel spindling utan att skicka skadliga payloads, medan den fulla aktiva skanningen faktiskt provocerar fram fel genom att skicka manipulerade förfrågningar. Den förra är säker att köra ofta, den senare kräver en testmiljö.

Måste jag installera Java för att köra ZAP?
Endast om du kör skrivbordsversionen direkt på din maskin, där Java 17 eller senare krävs. Kör du någon av de officiella Docker-avbildningarna behöver du inte installera Java separat.

Hur ofta bör jag köra en full aktiv skanning i CI/CD?
De flesta team kör baslinjeskanning på varje pull request och sparar den fulla aktiva skanningen till en schemalagd körning, till exempel en gång i veckan, mot en dedikerad testmiljö.

Fungerar ZAP för att testa GraphQL-API:er?
Delvis. ZAP:s standardimport är byggd för OpenAPI/Swagger-scheman, inte GraphQL-scheman. För GraphQL-specifik testning behöver du komplettera med riktade tekniker.

Vad är skillnaden mellan ZAP och Burp Suite?
ZAP är gratis, öppen källkod och byggt för obevakad automation i pipelines. Burp Suite är ett kommersiellt verktyg som är starkare för interaktiv, manuell penetrationstestning. Många team använder båda för olika delar av arbetet.

Kan ZAP testa applikationer som använder AI-agenter eller MCP-servrar?
Ja, sedan maj 2026 finns ett specifikt mcp-import-jobb i Automation Framework för att skanna MCP-servrar, och LLM Support-tillägget som lanserades i augusti 2026 riktar in sig på AI-specifika sårbarheter som prompt injection.

Kostar det något att köra ZAP i en CI/CD-pipeline i stor skala?
Själva verktyget är gratis oavsett hur många gånger du kör det. Den faktiska kostnaden är i stället beräkningstid i din CI-plattform, eftersom en fullständig aktiv skanning kan ta betydande tid och därmed dra CI-minuter, särskilt om du kör den mot flera miljöer parallellt.

Var hittar jag fler exempel på färdiga Automation Framework-scheman?
ZAP:s officiella GitHub-repo innehåller exempelscheman för vanliga scenarier, och det är ofta snabbare att utgå från ett befintligt exempel och anpassa det efter din applikation än att skriva ett schema helt från grunden.