OpenVAS Guide 2026: Skanna Sårbarheter i 13 Steg

Antalet publicerade CVE-poster passerade 76 000 under 2026, och CISA la till fler sårbarheter i sin KEV-katalog under årets första nio månader än under hela 2025, enligt en analys baserad på CISA:s egen JSON-feed. Samtidigt skanner många svenska it-avdelningar fortfarande manuellt, eller inte alls. OpenVAS, som drivs av det tyska företaget Greenbone, är den mest använda fria sårbarhetsskannern på marknaden och ett naturligt startläge för den som vill bygga egen CVE-bevakning utan att betala för Nessus eller Qualys.

Problemet många team hamnar i är inte brist på verktyg utan brist på en fungerande process runt verktyget. Att installera en skanner tar en eftermiddag. Att få den att faktiskt leverera värde varje vecka, år efter år, kräver rätt målkonfiguration, rätt skanningsfrekvens och en tydlig väg från fynd till åtgärd. Den här guiden fokuserar därför lika mycket på processen runt OpenVAS som på själva installationen, så att labbet ni bygger idag fortfarande används om sex månader istället för att tystna efter den första veckans nyfikenhet.

Den här guiden går igenom hela resan: från en tom Linux-server till ett fungerande skanningslabb som hittar, klassificerar och rapporterar sårbarheter automatiskt. Du får 13 konkreta steg, färdiga kodexempel, en lista med vanliga fallgropar och en felsökningssektion för när saker går snett (vilket de ofta gör första gången). Guiden bygger på Greenbone Community Edition, den gratisversion av plattformen som de flesta säkerhetsteam i Norden använder för interna nätverk och testmiljöer.

Det finns också ett regelverksskäl att bry sig om det här just nu. Fler svenska organisationer faller under krav på systematisk riskhantering i och med att cybersäkerhetslagen baserad på NIS2 omfattar fler sektorer än tidigare. En del av kraven handlar konkret om att kunna visa att ni identifierar och åtgärdar kända sårbarheter i er egen infrastruktur, inte bara reagerar när något redan gått fel. En egen skanningsrutin med OpenVAS är ett sätt att få den dokumentationen på plats utan att först behöva gå igenom en lång upphandling, vilket passar både mindre kommuner och medelstora bolag som plötsligt hamnat under lagens tillämpningsområde.

Vad är OpenVAS och Greenbone Community Edition?

OpenVAS Scanner är själva skanningsmotorn, det program som faktiskt skickar testtrafik mot dina system och letar efter kända brister. Greenbone Community Edition (GCE) är hela paketet runt omkring: webbgränssnittet Greenbone Security Assistant, databasmotorn gvmd som hanterar uppgifter och mål, samt feed-hanteringen som laddar ner nya sårbarhetssignaturer. Tillsammans kallas plattformen ofta GVM, Greenbone Vulnerability Management.

Den senaste versionen av OpenVAS Scanner är 23.50.26, publicerad 1 oktober 2026 enligt Greenbones releasesida på GitHub. Projektet har hög aktivitet, med commits så sent som 9 oktober 2026, och Greenbones feed innehåller enligt samma källa över 200 000 vulnerability tests (NVT:er). Det är den enskilt största fria samlingen av testskript för kända CVE:er som finns tillgänglig utan licenskostnad.

Skillnaden mot verktyg som Nmap är att OpenVAS inte bara upptäcker öppna portar och tjänster. Skannern loggar in, läser versionssträngar, testar faktiska svagheter och matchar dem mot CVE-databasen med en CVSS-poäng. Det gör verktyget mer likt Nessus och Qualys än ett rent nätverksskanningsverktyg, men med öppen källkod och ingen årlig licensavgift för kärnfunktionerna.

Projektet har en lång historia. OpenVAS började som en gren av Nessus-koden efter att Nessus gick från öppen till kommersiell licens för tjugo år sedan, och togs senare över och vidareutvecklades av Greenbone. Idag är det nästan missvisande att kalla hela paketet “OpenVAS”, eftersom namnet strikt syftar på själva skanningsmotorn medan Greenbone Community Edition är det officiella namnet på hela plattformen. De två termerna används ändå ofta som synonymer i praktiken, och den här guiden gör samma förenkling där det är naturligt.

Det är också värt att skilja på vad OpenVAS gör bra och vad det inte gör. Verktyget är starkt på nätverksbaserad och autentiserad hostskanning, webbserverkontroller och klassisk CVE-matchning. Det ersätter inte statisk kodanalys av er egen källkod, där verktyg som Semgrep hör hemma bättre, och det är inte ett dynamiskt API-testverktyg på samma sätt som Burp Suite. Se OpenVAS som skiktet som täcker infrastruktur och tjänster, inte applikationslogik.

Rent praktiskt betyder det att en välskött säkerhetsavdelning sällan kör bara ett verktyg. OpenVAS täcker servrar, nätverksenheter och klienter. Containerbilder täcks bättre av dedikerade verktyg som scannar lager-för-lager i en image innan den ens driftsätts. Öppen källkod och tredjepartsbibliotek i er egen kod täcks av beroendeskanning. Lägg ihop de tre lagren och ni får en betydligt mer heltäckande bild än om ni förlitar er på ett enda verktyg som försöker göra allt på en gång, vilket i praktiken sällan fungerar lika bra som specialiserade verktyg för varje lager.

Förutsättningar och systemkrav innan du börjar

Greenbone rekommenderar numera en containerbaserad installation i stället för att installera komponenterna separat på värdsystemet. Det sparar timmar av beroendehantering och är den väg som nästan alla produktionsmiljöer väljer idag. Innan du börjar behöver du följande på plats.

Komponent	Rekommenderad version	Varför
Linux-distribution	Ubuntu 24.04 LTS eller Debian 12	Officiellt testade av Greenbone-communityn
Docker Engine	27.x eller senare	Kör containrarna i Greenbone Community Container
Docker Compose-plugin	v2.29 eller senare	Startar hela stacken med en kommandorad
OpenVAS Scanner	23.50.26 (1 okt 2026)	Själva skanningsmotorn
Greenbone Community Edition	Arkitektur release 22.4	Webbgränssnitt, gvmd och feed-hantering
Python	3.10 eller senare	Krävs för automatiseringsexemplen med python-gvm
Fritt diskutrymme	Minst 20-30 GB	Feed-data och rapporter växer snabbt

Räkna med minst 8 GB RAM för en testmiljö och betydligt mer om du tänker skanna hundratals värdar samtidigt i produktion. Du behöver också utgående HTTPS-access till Greenbones feed-servrar, annars laddas aldrig de 200 000 testskripten ner och skannern blir i praktiken blind för nya CVE:er.

Tänk också igenom nätverksplaceringen innan du installerar. En skanner som bara ser DMZ-nätet missar allt som ligger på det interna kontorsnätet, och tvärtom. De flesta organisationer landar på minst två skannerinstanser: en som ser internetvända system utifrån, och en som sitter inne i produktionsnätet och ser samma system som en angripare som redan tagit sig förbi den yttre perimetern skulle göra. Planera IP-adresser, brandväggsregler och vilka VLAN skannern behöver nå redan nu, det är enklare att rita upp på ett whiteboard än att felsöka efteråt när ett helt segment plötsligt rapporterar noll fynd.

Steg 1-3: Installera Docker och hämta Greenbone Community Edition

Steg 1: Installera Docker Engine

Om servern redan kör Docker kan du hoppa över detta steg. Annars installerar du motorn direkt från Dockers officiella skript, vilket är snabbast på en färsk Ubuntu- eller Debian-installation.

curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
sudo usermod -aG docker $USER
newgrp docker
docker --version
docker compose version

Steg 2: Hämta Greenbone Community Container

Greenbone publicerar en färdig docker-compose-fil för hela stacken. Du klonar konfigurationen och går in i katalogen innan du rör något annat.

mkdir -p ~/openvas-lab && cd ~/openvas-lab
curl -O https://raw.githubusercontent.com/greenbone/docs/main/docker-compose.yml
curl -O https://raw.githubusercontent.com/greenbone/docs/main/.env
ls -la

Steg 3: Konfigurera miljövariabler

Öppna .env-filen och sätt ett eget lösenord för admin-kontot, samt vilken port webbgränssnittet ska exponeras på. Lämna aldrig standardlösenordet kvar, det är den vanligaste orsaken till att testlabb blir ett eget säkerhetshål.

GSA_PASSWORD=ByT-Ditt-Egna-Losenord-Har-2026
GSA_WEB_PORT=9443
GSA_HTTPS_PORT=9443

Steg 4-5: Starta containrarna och logga in i Greenbone Security Assistant

Nu startar du hela stacken. Första gången laddas feed-datan ner, det innehåller de över 200 000 NVT-signaturerna och tar normalt mellan 20 och 60 minuter beroende på nätverkshastighet.

docker compose up -d
docker compose ps
docker compose logs -f gvmd

När loggarna visar att feed-synkroniseringen är klar, öppnar du webbläsaren mot https://din-server-ip:9443. Webbläsaren klagar på det självsignerade certifikatet, det är förväntat i en testmiljö och du klickar dig förbi varningen. Logga in med användarnamnet admin och lösenordet du satte i .env-filen.

Det första du bör göra efter inloggning är att byta lösenord igen via gränssnittet, under Administration > Users, samt skapa ett separat konto med lägre behörighet för den dagliga driften. Att köra allt skanningsarbete som admin-kontot är en onödig risk som är lätt att undvika.

Första inloggningen visar en tom dashboard, vilket är helt normalt. Greenbones startsida fylls i första hand med diagram över CVSS-fördelning, uppgiftshistorik och feedstatus allt eftersom ni kör skanningar. Ta ett par minuter här och klicka igenom menyerna under Scans, Configuration och Administration innan du går vidare, så att du vet var sakerna finns när du faktiskt behöver dem mitt i en stressad patchningscykel.

Steg 6: Uppdatera sårbarhetsfeeden med senaste signaturerna

Greenbone Community Feed uppdateras flera gånger om dagen med nya NVT-tester när tillverkare och forskare publicerar nya CVE:er. Med en CVE-volym som i september 2026 nådde 15 180 nya poster på en enda månad, enligt data från CVE Trends, räcker det inte att uppdatera feeden en gång i veckan. Kontrollera och tvinga en uppdatering direkt i terminalen om du vill vara säker på att inte missa något.

docker compose exec gvmd gvmd --get-scanners
docker compose exec gvmd greenbone-feed-sync --type GVMD_DATA
docker compose exec gvmd greenbone-feed-sync --type SCAP
docker compose exec gvmd greenbone-feed-sync --type CERT

En lyckad körning avslutas med en rad som bekräftar hur mycket data som laddats ner och verifierats mot Greenbones signatur, ungefär enligt följande.

[i] Updating NVTs
[i] Download complete, verifying GPG signature
[i] Signature verified OK
[i] Syncing OBJECTS to /var/lib/gvm/data-objects
[i] Feed sync complete. 200134 NVTs loaded.

Om du istället ser upprepade GPG-fel eller att processen avslutas utan “Feed sync complete” på sista raden, är det nästan alltid ett nätverks- eller proxyproblem, inte ett fel i själva Greenbone-installationen. Testa att nå feed-servrarna direkt med curl från samma container innan du felsöker vidare i konfigurationen.

Schemalägg gärna detta som en nattlig cron-uppgift så att du alltid skannar mot den senaste listan av kända brister, inte en månad gammal ögonblicksbild.

Sätt detta i relation till hur snabbt hotbilden rör sig. Tidsperioden fram till början av oktober 2026 omfattade 90 953 publicerade CVE-poster och 308 nya KEV-tillägg under tolv månader, enligt CVE Trends. Det är ungefär 250 nya CVE:er per dag i genomsnitt över hela perioden, även om enskilda månader som september sticker ut betydligt mer. En skanner som bara uppdateras månadsvis missar i praktiken flera veckors nya signaturer varje gång, vilket i sig blir en osynlig lucka i er riskbild.

Steg 7: Skapa ditt första skanningsmål

I Greenbone-terminologin kallas det du vill skanna ett Target. Gå till Configuration > Targets och klicka på den blå plustecken-knappen. Ange ett namn, en eller flera IP-adresser eller ett CIDR-block, och vilka portar som ska testas.

Ett vanligt nybörjarmisstag är att lämna portlistan på standard (vanligen de cirka 4 500 vanligaste TCP-portarna) när ni egentligen vill täcka hela spannet 1-65535. För en första körning mot ett fåtal testservrar räcker standardlistan gott, men i en produktionsmiljö bör du bygga en egen portlista som matchar vad era system faktiskt exponerar.

# Exempel pa target via GMP (Greenbone Management Protocol) med gvm-cli
gvm-cli --gmp-username admin --gmp-password '***' socket \
  --xml '
    Intern testmiljo
    10.0.5.0/24
    
  '

Du kan skapa flera targets för olika delar av miljön, exempelvis ett för klientnätet, ett för serverhallen och ett för DMZ-nätet. Det gör det enklare att schemalägga olika skanningsfrekvens för olika kritikalitet. Internetvända system i DMZ-nätet förtjänar oftare än veckovis skanning givet hur snabbt nya exploateringar dyker upp, medan ett avskilt testnät med låg risk kan skannas månadsvis utan att ni förlorar särskilt mycket säkerhet.

Steg 8: Konfigurera skanningskonfigurationen

Under Configuration > Scan Configs väljer du hur aggressivt OpenVAS ska testa. “Full and fast” är standardvalet för de flesta och ger en bra balans mellan täckning och tid. “Full and very deep” testar fler kombinationer men kan ta flera gånger längre tid och belasta måltjänsterna hårdare, vilket kan vara olämpligt mot produktionssystem under kontorstid.

Om du skannar system som är känsliga för belastning, till exempel äldre industriella styrsystem, finns läget “System Discovery” som bara kartlägger vad som finns utan att köra tyngre exploateringstester. Välj alltid det mildaste läget som faktiskt ger er den information ni behöver, snarare än att alltid köra den djupaste varianten.

Det går också att klona en befintlig scan config och justera enskilda NVT-familjer. Vill du exempelvis utesluta alla tester som kräver skriv-åtkomst mot databaser, eller stänga av de mest aggressiva denial-of-service-liknande kontrollerna mot produktionssystem, gör du det genom att redigera kopian i stället för att röra någon av de fördefinierade standardkonfigurationerna. Det håller era anpassningar spårbara och gör det enkelt att återgå om något blir fel.

Steg 9: Kör din första sårbarhetsskanning

Nu kopplar du ihop target och scan config i en Task under Scans > Tasks. Klicka på play-ikonen för att starta direkt, eller ställ in ett schema om skanningen ska köras automatiskt varje natt eller vecka.

# Starta en befintlig task via kommandoraden
gvm-cli --gmp-username admin --gmp-password '***' socket \
  --xml ''

# Kontrollera status
gvm-cli --gmp-username admin --gmp-password '***' socket \
  --xml ''

En skanning mot en enskild server tar normalt mellan 15 och 45 minuter beroende på hur många tjänster som svarar och vilken scan config du valt. Mot ett helt /24-nät med flera hundra värdar bör du räkna med flera timmar, och det är här många nya användare blir frustrerade och avbryter i onödan. Låt den köra klart första gången så du vet vad en normal körtid faktiskt är i din miljö.

Vill du skala upp och skanna flera nät parallellt kan du köra flera ospd-openvas-instanser bakom samma gvmd, varje instans knuten till en egen scanner-post i gränssnittet. Det är så större organisationer löser att en enda körtråd annars blir en bottleneck när antalet mål växer från tiotals till tusentals värdar. Lägg inte alla targets i en enda jättelik task, dela upp dem så att ett misslyckat segment inte stoppar hela körningen.

Steg 10: Tolka resultat, CVSS-poäng och riskklassning

När skanningen är klar visas resultaten under Scans > Results, sorterade efter allvarlighetsgrad. Varje fynd får en CVSS-poäng mellan 0 och 10, och Greenbone grupperar dem i High (7,0-10), Medium (4,0-6,9) och Low (0,1-3,9). Ett typiskt resultat för en oparad webbserver kan se ut så här.

Host: 10.0.5.42
NVT: Apache HTTP Server Multiple Vulnerabilities
CVE: CVE-2026-XXXXX
CVSS: 8.1 (High)
Port: 443/tcp
Summary: Servern korde en version av Apache med
  en kand sarbarhet for minneskorruption vid
  hantering av fragmenterade HTTP/2-headers.
Solution: Uppgradera till senaste patchade version.

Lägg märke till att fältet Solution nästan alltid pekar på en uppgradering snarare än en konfigurationsändring. Det beror på att de flesta NVT:er testar efter kända versionssträngar, och den mest tillförlitliga åtgärden för en version med en känd brist är att byta till en version utan den bristen. I undantagsfall, när en officiell patch ännu inte finns, föreslår Greenbone istället en kompenserande kontroll, exempelvis att stänga av en specifik funktion eller begränsa åtkomsten via brandväggsregler tills en permanent fix publiceras.

Det är viktigt att komma ihåg att en KEV-notering (Known Exploited Vulnerability) hos CISA inte betyder samma sak som ett CVSS-tal. KEV-listan säger att CISA har bekräftade belägg för aktiv exploatering i verkligheten, enligt en genomgång från Blacktree Security, medan CVSS mäter teoretisk allvarlighetsgrad. En sårbarhet med CVSS 6,5 som ligger på KEV-listan ska i praktiken prioriteras före en med CVSS 9,0 som bara är teoretisk. Greenbone märker inte automatiskt KEV-status i gränssnittet, så du bör korsreferera era högprioriterade fynd mot CISA:s KEV-katalog manuellt eller via ett skript.

Siffrorna bakom KEV-katalogen visar varför den distinktionen spelar roll. CISA lade till 247 sårbarheter i katalogen mellan 1 januari och 1 oktober 2026, enligt en analys av CISA:s feed, vilket redan vid den tidpunkten var fler tillägg än under hela 2025 (245 tillägg). I det andra kvartalet 2026 stod Microsoft för 15 av 75 nya KEV-tillägg och Cisco för sju, tillsammans nästan 30 procent av kvartalets totala tillägg enligt SecPods genomgång. Håll alltså extra ögon på fynd som rör produkter från dessa leverantörer, oavsett vilken enskild CVSS-poäng de fått.

Steg 11: Exportera och dela rapporter

De flesta behöver skicka vidare resultaten till andra team, till en ticketing-plattform eller till ledningen i ett läsbart format. Greenbone stödjer export till PDF, CSV, XML och flera andra format direkt från gränssnittet, men för automatiserade flöden är kommandoraden snabbare.

# Exportera en rapport som CSV via gvm-cli
gvm-cli --gmp-username admin --gmp-password '***' socket \
  --xml '' \
  > rapport_$(date +%F).csv

Byt ut format_id mot ID för PDF eller XML om du behöver andra format. Greenbone listar samtliga export-ID:n under Configuration > Report Formats i gränssnittet.

Steg 12: Automatisera skanningar med Python och GVM-API

Manuella klick i webbgränssnittet funkar bra för en enstaka testkörning, men för löpande drift vill du ha skript som startar skanningar, pollar status och hämtar resultat automatiskt. Greenbone underhåller det officiella Python-biblioteket python-gvm, som pratar samma GMP-protokoll som webbgränssnittet gör under huven.

pip install python-gvm

# scan_runner.py
from gvm.connections import UnixSocketConnection
from gvm.protocols.gmp import Gmp
from gvm.transforms import EtreeCheckCommandTransform

connection = UnixSocketConnection(path='/run/gvmd/gvmd.sock')
transform = EtreeCheckCommandTransform()

with Gmp(connection, transform=transform) as gmp:
    gmp.authenticate('automation_user', 'byt-losenord')

    response = gmp.start_task(task_id='DIN-TASK-ID-HAR')
    report_task_id = response.xpath('//report_id/text()')[0]
    print(f"Skanning startad, report-id: {report_task_id}")

    status = gmp.get_task(task_id='DIN-TASK-ID-HAR')
    print(status.xpath('//status/text()')[0])

Kör skriptet från en cron-uppgift eller en CI/CD-pipeline efter varje stor driftsättning, och skicka resultatet vidare till ert ticketsystem via ett enkelt webhook-anrop. Det förvandlar OpenVAS från ett verktyg du kommer ihåg att öppna ibland till en del av den löpande säkerhetsrutinen, på samma sätt som container-skanning med Trivy eller beroendeskanning med OSV-Scanner redan är för kodnära sårbarheter.

Steg 13: Härda, uppdatera och underhåll din installation

En sårbarhetsskanner som själv är sårbar är ett dåligt skämt. Lås ner åtkomsten till webbgränssnittet bakom en brandvägg eller VPN, aldrig direkt mot internet. Rotera admin-lösenordet regelbundet, och ge varje person som behöver åtkomst ett eget konto med minsta nödvändiga behörighet i stället för att dela admin-inloggningen.

Håll även containerimagerna uppdaterade. Eftersom OpenVAS Scanner är ett aktivt projekt med releaser ungefär varje månad, bör du köra docker compose pull och docker compose up -d regelbundet för att få både säkerhetsfixar i skannern själv och stöd för nya testtyper.

Byt också ut det självsignerade certifikatet som GSA använder mot ett riktigt certifikat så snart labbet lämnar testfasen, antingen från er interna PKI eller via ett internt CA-verktyg. Ett självsignerat certifikat är helt okej att klicka förbi i en testmiljö, men i produktion blir det en vana som riskerar att göra användarna okänsliga för riktiga certifikatvarningar på andra, faktiskt komprometterade, system.

Vanliga fallgropar när du sätter upp OpenVAS

De flesta problemen i en ny OpenVAS-installation handlar inte om buggar i mjukvaran, utan om vanemässiga misstag som dyker upp om och om igen i olika team. Här är de sex vanligaste, i ungefär den ordning de brukar drabba en förstagångsanvändare.

Feed-synkroniseringen hinner inte klart. Många avbryter installationen för tidigt eftersom nedladdningen av 200 000+ NVT:er tar lång tid, särskilt över en långsam företagsuppkoppling. Kontrollera alltid loggarna med docker compose logs -f gvmd innan du antar att något är trasigt och startar om från början.
Skanning mot produktion under kontorstid. En djup skanning kan belasta äldre system så hårt att tjänster blir långsamma eller kraschar helt, särskilt mot inbyggda system och äldre industriutrustning som aldrig är byggd för att hantera oväntad testtrafik. Kör första fulla skanningen utanför kontorstid och informera berörda systemägare i förväg.
Fel portlista. Standardportlistan missar ofta tjänster på ovanliga portar, vilket ger en falsk känsla av säkerhet när rapporten ser ren ut trots att en sårbar tjänst lyssnar på en port ingen tänkt på att inkludera.
Ingen uppföljning av falska positiva. OpenVAS rapporterar ibland fynd baserat enbart på versionssträngar utan att verifiera exploaterbarhet på riktigt. Validera högriskfynd manuellt, eller med ett kompletterande verktyg, innan ni eskalerar till krisläge och väcker halva organisationen i onödan.
Admin-kontot används för allt. Delade superanvändarkonton gör det omöjligt att spåra vem som startade vilken skanning, och ökar skadan avsevärt om kontot läcker eller missbrukas av en insider.
Feeden uppdateras aldrig efter installation. Utan schemalagd uppdatering skannar ni snart mot en månader gammal lista, trots att i genomsnitt omkring 250 nya CVE:er publiceras varje dag under 2026 enligt CVE Trends-statistiken ovan.

Felsökning: 8 vanliga problem och lösningar

Nedan är de problem som vanligast dyker upp i supportforum och interna chattkanaler när team sätter upp OpenVAS för första gången, tillsammans med vad som faktiskt löser dem i de flesta fall.

Webbgränssnittet svarar inte på port 9443. Kontrollera att containern faktiskt är uppe med docker compose ps, att den inte ligger i en omstartsloop, och att brandväggen på både server och eventuell molnleverantör tillåter inkommande trafik till den porten.
Inloggningen misslyckas trots rätt lösenord. Lösenordet i .env läses bara in vid första uppstarten av databasen. Om du ändrat filen efteråt måste du nollställa postgres-volymen eller byta lösenord via GSA-gränssnittet istället för att bara starta om containrarna.
Feed-synkroniseringen hänger sig på samma procentandel. Kontrollera utgående HTTPS mot Greenbones feed-servrar, det är ofta blockerat av företagets proxy eller en brandväggsregel som bara tillåter trafik mot en vitlista av domäner.
Skanningen fastnar på statusen “Requested” utan att gå vidare. gvmd-containern kan inte nå ospd-openvas-containern över nätverket. Kontrollera nätverksinställningarna i docker-compose.yml och att båda tjänsterna ligger i samma Docker-nätverk.
Inga resultat trots lång körtid. Målet blockerar möjligen skannerns IP-adress via en IPS eller WAF som tolkar skanningstrafiken som en attack. Testa med en mindre aggressiv scan config, eller vitlista skannerns adress temporärt under testfönstret.
Containern kraschar med minnesfel mitt i en stor skanning. gvmd och postgres-databasen behöver mer minne än många mindre testservrar har tillgängligt. Höj minnesgränsen i docker-compose.yml, eller flytta hela stacken till en instans med mer RAM.
Rapport-export ger en tom fil eller felmeddelande. Rapport-id eller format-id stämmer inte längre, ofta efter en uppgradering som bytt ut interna ID:n. Lista giltiga värden med kommandona get_reports respektive get_report_formats innan du kör exporten igen.
python-gvm kan inte ansluta till gvmd. Kontrollera sökvägen till unix-socketen, den skiljer sig mellan en lokal installation och en containerbaserad, och kräver ofta rättigheter för den operativsystemsanvändare som kör skriptet. En felaktig sökväg ger vanligtvis ett tydligt “connection refused”-fel i Python-tracebacken.

Avancerade tips för produktionsmiljöer

När grundinstallationen fungerar finns flera sätt att höja kvaliteten på era skanningar. Använd autentiserade skanningar där OpenVAS loggar in via SSH eller SMB på målsystemen. Det ger betydligt mer tillförlitliga resultat än en obehörig skanning utifrån, eftersom skannern då kan läsa faktiska paketversioner istället för att gissa baserat på nätverkssvar.

För autentiserade skanningar mot Linux-värdar räcker det med ett dedikerat servicekonto med läsrättigheter, aldrig ett konto med fulla administratörsrättigheter. Skapa SSH-nycklar specifikt för skanningsändamål, lagra dem i Greenbones egen “Credentials”-funktion under Configuration > Credentials, och koppla dem till targetet i stället för att återanvända nycklar som redan används för annat. Mot Windows-värdar fungerar motsvarande upplägg via SMB med ett begränsat domänkonto, vilket de flesta större organisationer redan har rutiner för från andra verktyg i miljön.

Bygg dessutom en rutin för att trenda resultat över tid i stället för att bara titta på en enskild rapport. Exportera varje körning till CSV och ladda in i ett enkelt dashboard, så ser ni direkt om antalet högriskfynd ökar eller minskar månad för månad. Det är samma princip som ligger bakom strukturerad CVE-bevakning med CVSS 4.0, bara applicerad på er egen infrastruktur istället för på externa flöden.

Slutligen, separera skanningsroller från patchningsroller. Teamet som hittar sårbarheter ska inte vara samma team som stänger ärenden utan verifiering, annars uppstår en intressekonflikt där obekväma fynd riskerar att tystas ner i stället för att åtgärdas.

Koppla OpenVAS till ert SIEM och er incidenthantering

En skanner som bara lämnar resultat i sitt eget webbgränssnitt blir lätt en isolerad ö i verktygsfloran. De flesta mogna säkerhetsteam skickar OpenVAS-fynd vidare till samma plattform där loggar och larm redan samlas, exempelvis Wazuh om ni redan kört igång ett eget SIEM, eller en ärendehanteringsplattform som TheHive för att driva uppföljningen som formella ärenden med deadlines och ägare.

Den enklaste integrationen är att låta automationsskriptet från steg 12 skriva varje högriskfynd som en egen rad i en delad CSV-fil eller databas, och sedan läsa in den filen i er befintliga plattform via ett schemalagt jobb. Mer avancerade team bygger istället en liten mellanprogramvara som pratar GMP-protokollet direkt mot gvmd och skickar fynd som strukturerade händelser i realtid, men för de flesta organisationer är den enklare CSV-baserade vägen fullt tillräcklig för att komma igång.

OpenVAS jämfört med Nessus och Qualys 2026

OpenVAS konkurrerar inte med de kommersiella alternativen på exakt samma villkor, men verktygen löser ofta samma grundproblem för olika budgetar. Valet handlar sällan om vilket verktyg som är “bäst” i absoluta termer, utan om vilken kombination av kostnad, drifttid och supportbehov som passar er organisations storlek och mognad.

Mindre organisationer och kommuner med begränsad säkerhetsbudget väljer ofta OpenVAS just därför att det tar bort licenskostnaden som en budgetfråga helt och hållet, och flyttar frågan till drifttid i stället, vilket många redan har kapacitet för via befintlig IT-drift. Större organisationer med flera hundra eller tusentals tillgångar och krav på snabb support under en pågående incident lutar oftare åt en kommersiell lösning, där kostnaden för licensen vägs mot kostnaden för en egen driftsorganisation runt skannern.

Egenskap	OpenVAS / Greenbone CE	Nessus	Qualys
Licenskostnad	Gratis (öppen källkod)	Kommersiell licens	Kommersiell, molnbaserad
Driftmodell	Egen server eller container	Lokal eller molnbaserad	Primärt SaaS i molnet
Antal NVT/signaturer	200 000+ (community feed)	Egen plugin-databas	Egen signaturdatabas
Bäst för	Interna nät, test, mindre budget	Snabb djupskanning, brett stöd	Stora, molndrivna organisationer
Support	Community, betald Greenbone Enterprise finns	Leverantörssupport ingår	Leverantörssupport ingår

Konkreta prisjämförelser mellan de tre förändras ofta och saknar tillförlitliga 2026-källor i skrivande stund, så dra inga definitiva slutsatser om kronor och ören utan att själva begära offert. Vad som däremot går att slå fast är att OpenVAS ger er en fungerande skanner för CVE-upptäckt utan inköpsprocess, vilket gör det till ett naturligt första steg innan ni eventuellt väger in en kommersiell lösning för skala eller support.

I praktiken väljer många organisationer en hybrid. De kör OpenVAS på interna nät och testmiljöer där kostnaden för en kommersiell licens är svår att motivera, samtidigt som de håller en kommersiell lösning för internetvända system där leverantörssupport och snabbare signaturuppdateringar kan vara värda prislappen. Det finns inget tekniskt hinder mot att köra båda parallellt, och många CISO:er ser det faktiskt som en fördel: två oberoende skannermotorer upptäcker ofta delvis olika saker, vilket minskar risken att en enskild blind fläck i en motor blir en blind fläck i hela organisationens säkerhetsbild.

Komplett exempelprojekt: ett fullständigt skanningslabb

Nedan är en komplett docker-compose.yml som samlar allt från föregående steg i en enda fil. Spara den som den är och kör docker compose up -d för att få igång ett helt eget labb på under en timme, feed-nedladdning inräknad.

version: "3.8"
services:
  vulnerability-tests:
    image: greenbone/vulnerability-tests
    volumes:
      - vt_data:/var/lib/openvas/plugins

  notus-data:
    image: greenbone/notus-data
    volumes:
      - notus_data:/var/lib/notus

  scap-data:
    image: greenbone/scap-data
    volumes:
      - scap_data:/var/lib/gvm/scap-data

  cert-bund-data:
    image: greenbone/cert-bund-data
    volumes:
      - cert_data:/var/lib/gvm/cert-data

  gpg-data:
    image: greenbone/data-objects
    volumes:
      - data_objects:/var/lib/gvm/data-objects

  redis-server:
    image: greenbone/redis-server
    restart: on-failure

  pg-gvm:
    image: greenbone/pg-gvm
    volumes:
      - psql_data:/var/lib/postgresql

  gvmd:
    image: greenbone/gvmd
    depends_on:
      - pg-gvm
      - redis-server
    volumes:
      - gvmd_data:/var/lib/gvm
      - vt_data:/var/lib/openvas/plugins:ro
      - scap_data:/var/lib/gvm/scap-data:ro
      - cert_data:/var/lib/gvm/cert-data:ro
      - data_objects:/var/lib/gvm/data-objects:ro
    environment:
      - GSA_PASSWORD=${GSA_PASSWORD}

  gsa:
    image: greenbone/gsa
    depends_on:
      - gvmd
    ports:
      - "${GSA_WEB_PORT}:9443"

  ospd-openvas:
    image: greenbone/ospd-openvas
    depends_on:
      - redis-server
    volumes:
      - vt_data:/var/lib/openvas/plugins:ro
      - notus_data:/var/lib/notus:ro

volumes:
  vt_data:
  notus_data:
  scap_data:
  cert_data:
  data_objects:
  redis_data:
  psql_data:
  gvmd_data:

Detta är en förenklad version för att visa strukturen. I en skarp installation bör du använda Greenbones officiella och underhållna compose-fil, eftersom image-namn och versionstaggar uppdateras löpande i takt med nya releaser av OpenVAS Scanner och övriga komponenter.

Lägg märke till hur många fristående komponenter som faktiskt ingår. vulnerability-tests innehåller själva NVT-skripten, scap-data och cert-bund-data bidrar med ytterligare sårbarhetsreferenser från amerikanska och tyska källor, och ospd-openvas är bryggan som gvmd pratar med för att faktiskt skicka iväg testtrafik. Förstår du den uppdelningen blir felsökning mycket enklare, eftersom du kan avgöra exakt vilken container som är trolig orsak när något strular, i stället för att gissa brett över hela stacken.

När labbet är igång, testa det mot en medvetet sårbar övningsmaskin innan ni pekar det mot riktig infrastruktur. Det bekräftar att hela kedjan, från target till task till rapport, fungerar end-to-end utan att ni riskerar att störa något produktionssystem under den första testomgången.

Vanliga frågor om OpenVAS och sårbarhetshantering

Är OpenVAS verkligen helt gratis att använda?
Ja, Greenbone Community Edition är öppen källkod och fri att köra på egen infrastruktur. Greenbone säljer en företagsversion med extra feed-innehåll, support och drift i molnet för organisationer som behöver det, men kärnfunktionerna kostar ingenting.

Kan OpenVAS skanna molntjänster som AWS eller Azure?
Ja, så länge skannern har nätverksvägen till resurserna, men tänk på molnleverantörernas regler för säkerhetstester. AWS och Azure kräver i vissa fall förhandsanmälan innan aktiv skanning mot deras infrastruktur.

Hur ofta bör vi köra en fullständig skanning?
En rimlig utgångspunkt är veckovis för interna nät och efter varje större förändring, som en ny driftsättning eller en öppnad brandväggsregel, med tanke på att hundratals nya CVE:er publiceras varje vecka under 2026.

Skiljer sig OpenVAS från en IDS som Suricata?
Ja, helt olika syfte. OpenVAS letar aktivt efter kända svagheter genom att testa system, medan en IDS passivt övervakar trafik efter tecken på att en attack redan pågår.

Vad gör jag om en skanning rapporterar hundratals fynd på en gång?
Sortera efter CVSS-poäng och korsreferera de högsta mot CISA:s KEV-katalog. Åtgärda aktivt exploaterade sårbarheter först, oavsett vad den rena CVSS-siffran säger.

Kan jag köra OpenVAS på en vanlig bärbar dator för att testa?
Tekniskt går det med Docker Desktop, men räkna med att feed-synkroniseringen och själva skanningarna blir långsammare än på en dedikerad server med mer minne och snabbare disk.

Behöver vi tillstånd innan vi skannar vårt eget nätverk?
Internt, ja i princip alltid, se till att ni har skriftligt godkännande från systemägaren innan ni kör aktiva tester, även mot egen infrastruktur. Mot tredje parts system krävs alltid explicit tillstånd.

När är det läge att byta från gratisversionen till Greenbone Enterprise?
Oftast när ni behöver leverantörssupport med svarstider, ytterligare feed-innehåll utöver community-feeden, eller molnbaserad drift utan att själva underhålla servrar. Rent tekniskt klarar community-versionen betydligt mer än de flesta förväntar sig innan den gränsen nås.

OpenVAS: Skanna Sårbarheter i 13 Steg, 90 Min [2026]