Linux sebezhetőségvizsgálat automatizálása: OpenVAS, Trivy és OpenSCAP a gyakorlatban

Bevezetés — Miért nem elég a tűzfal és az SSH megerősítés?

Ha eddig követted a sorozatunkat, már felépítetted az nftables tűzfalat, megerősítetted az SSH-t posztkvantum kriptográfiával, biztonságossá tetted a konténereidet, és beüzemelted az auditd-t a futásidejű monitorozáshoz. Ezek remek alapok. De van egy kritikus réteg, ami még hiányzik: a proaktív sebezhetőségvizsgálat.

Gondolj bele. A tűzfal megakadályozza a jogosulatlan hozzáférést. Az auditd észleli a gyanús tevékenységet. De ki mondja meg neked, hogy a rendszereden most éppen milyen ismert sebezhetőségek vannak, amelyeket egy támadó simán kihasználhat? Nos, senki — hacsak nem vizsgálod rendszeresen.

A számok önmagukért beszélnek: 2025-ben több mint 5500 Linux kernel CVE-t regisztráltak, ami történelmi rekord. A Datadog 2026-os DevSecOps jelentése szerint a szervezetek 87%-a legalább egy kihasználható sebezhetőséget futtat éles környezetben, és ez a szolgáltatásaik 40%-át érinti. A medián függőség 278 nappal marad el a legfrissebb verziótól — ez közel 10 hónapos ablak a támadóknak. Őszintén? Ezek elég ijesztő számok.

Ebben az útmutatóban három nyílt forráskódú eszközzel ismerkedsz meg, amelyek együtt lefedik a sebezhetőségvizsgálat teljes spektrumát:

• OpenVAS (Greenbone) — Hálózati és rendszerszintű sebezhetőségvizsgálat több mint 160 000 teszttel
• Trivy — Konténerek, kódtárak, IaC fájlok és SBOM-ok villámgyors vizsgálata
• OpenSCAP — CIS és STIG szabványoknak való megfelelőség ellenőrzése és automatikus javítása

Mindhárom eszközre kapsz telepítési útmutatót, gyakorlati konfigurációkat és automatizálási példákat. Vágjunk bele.

OpenVAS (Greenbone Community Edition) — Hálózati sebezhetőségvizsgálat

Az OpenVAS (Open Vulnerability Assessment System) a világ egyik legelterjedtebb nyílt forráskódú sebezhetőségvizsgáló eszköze. A Greenbone fejleszti 2006 óta, és a Community Edition szabadon elérhető. Hálózati szintű vizsgálatot végez: portokat szondáz, szolgáltatásokat azonosít, majd a felismert szoftverek ismert sebezhetőségeit ellenőrzi egy naponta frissülő adatbázisból.

Architektúra és komponensek

A Greenbone Community Edition több komponensből áll, amelyek együtt alkotják a teljes sebezhetőség-kezelési platformot:

• openvas-scanner (openvasd) — A tényleges vizsgálómotor, amely a sebezhetőségi teszteket (VT) futtatja a célrendszerek ellen. A 2026-os verzióban a korábbi notus-scanner és ospd-openvas komponenseket egyetlen Rust-alapú démon váltotta fel (ami érezhetően gyorsabb lett).
• gvmd — A központi menedzsment démon, amely összehangolja a vizsgálatokat, tárolja az eredményeket és kezeli a konfigurációt.
• GSA (Greenbone Security Assistant) — A webes felület, amelyen keresztül a vizsgálatokat irányítod és az eredményeket elemzed.
• PostgreSQL — Az adatbázis-háttér a konfiguráció és eredmények tárolására.

Telepítés Docker Compose segítségével

2026-ban a legegyszerűbb és legmegbízhatóbb telepítési mód a Docker Compose. A Greenbone hivatalos konténerképeit a saját registry-jükből húzzuk le. Ha valaha is próbáltad natívan telepíteni az OpenVAS-t, tudod, miért jó hír ez.

# Könyvtár létrehozása és compose fájl letöltése
mkdir -p ~/greenbone-community-container && cd ~/greenbone-community-container

# Hivatalos Docker Compose fájl letöltése
curl -f -O -L https://greenbone.github.io/docs/latest/_static/docker-compose.yml

# Konténerek indítása (háttérben)
docker compose up -d

# Állapot ellenőrzése — várj, amíg minden szolgáltatás healthy lesz
docker compose ps

# Feed szinkronizáció állapota (ez az első indításnál 30-60 percig tarthat)
docker compose logs -f vulnerability-tests

Az első indítás után a GSA webes felület a https://127.0.0.1:9392 címen érhető el. Az alapértelmezett bejelentkezési adatok: admin / admin — ezt azonnal változtasd meg az első bejelentkezés után. Komolyan, ne halogasd.

Telepítés csomagból (RHEL/AlmaLinux)

Ha inkább natív csomagokat szeretnél Docker nélkül (mondjuk mert az üzemeltetési szabályzat nem enged konténereket), RHEL 9 alapú rendszeren a következőképpen járhatsz el:

# EPEL és szükséges csomagok
sudo dnf install -y epel-release
sudo dnf install -y gvm openvas redis postgresql-server

# PostgreSQL és Redis inicializálása
sudo postgresql-setup --initdb
sudo systemctl enable --now postgresql redis

# GVM inicializálása (adatbázis, feed, admin felhasználó)
sudo gvm-setup

# A setup végén kapott jelszót jegyezd fel!
# Szolgáltatások indítása
sudo systemctl enable --now gvmd gsad ospd-openvas

Vizsgálat konfigurálása és futtatása

A webes felületen a vizsgálat beállítása négy lépésből áll:

1. Cél (Target) létrehozása — Navigálj a Configuration → Targets menüpontra, adj meg IP-címet, tartományt vagy hostname-eket. Több célpontot is megadhatsz vesszővel elválasztva vagy IP-tartományként (pl. 192.168.1.0/24).
2. Hitelesítő adatok megadása (opcionális, de ajánlott) — A Configuration → Credentials alatt adj meg SSH vagy SMB hitelesítő adatokat. A hitelesített vizsgálat lényegesen több sebezhetőséget talál, mert a rendszer belsejéből is ellenőrzi a telepített csomagok verzióit. Tapasztalataim szerint akár 3-4x annyi találatot kaphatunk így.
3. Feladat (Task) létrehozása — A Scans → Tasks menüben hozz létre új feladatot. Válaszd ki a célpontot, a vizsgálati konfigurációt (Full and fast az ajánlott kiindulópont) és opcionálisan a hitelesítő adatokat.
4. Vizsgálat indítása — Kattints a Start gombra. Egy /24-es alhálózat hitelesített vizsgálata jellemzően 2-4 órát vesz igénybe, szóval tervezz vele.

Eredmények értelmezése és automatizálás

Az OpenVAS az eredményeket CVSS pontszám alapján kategorizálja: Critical (9.0–10.0), High (7.0–8.9), Medium (4.0–6.9), Low (0.1–3.9). Minden találathoz kapsz CVE-azonosítót, leírást és javítási javaslatot.

Ha nem akarsz minden alkalommal kézzel elindítani a vizsgálatot (és miért akarnál?), a gvm-tools Python csomaggal automatizálhatod:

# gvm-tools telepítése
pip install gvm-tools

# Vizsgálat indítása parancssorból (GMP protokollon)
gvm-cli socket --socketpath /run/gvmd/gvmd.sock \
  --gmp-username admin --gmp-password <JELSZÓ> \
  --xml "<create_task>
    <name>Heti automatikus vizsgálat</name>
    <config id='daba56c8-73ec-11df-a475-002264764cea'/>
    <target id='<TARGET_ID>'/>
  </create_task>"

# Időzítés cron-nal: minden vasárnap hajnali 2-kor
# 0 2 * * 0 /usr/local/bin/gvm-weekly-scan.sh >> /var/log/gvm-scan.log 2>&1

Trivy — Konténer- és kódvizsgálat a fejlesztési folyamatban

Míg az OpenVAS a hálózati szintű vizsgálatra specializálódott, a Trivy (Aqua Security) a modern DevSecOps eszköztár alappillére. Konténer-képeket, fájlrendszereket, Git-tárakat, IaC fájlokat és Kubernetes-klasztereket vizsgál — egyetlen binárisból, percek alatt. Ha az OpenVAS a „nehéztüzérség", akkor a Trivy a „svájci bicska".

A Trivy jelenleg a v0.69.x verziónál jár (2026. március), és több mint 27 000 GitHub-csillaggal valamint évi 100 millió letöltéssel a kategória legszélesebb körben használt nyílt forráskódú eszköze. Több mint 30 sebezhetőségi adatbázist használ, beleértve a GitHub Security Advisories-t és a National Vulnerability Database-t.

Telepítés

# Telepítés a hivatalos telepítő szkripttel (ajánlott)
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sudo sh -s -- -b /usr/local/bin

# Verzió ellenőrzése
trivy version
# Kimenet: Version: 0.69.3

# Alternatív telepítés csomagkezelővel (Debian/Ubuntu)
sudo apt-get install -y wget apt-transport-https gnupg lsb-release
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | sudo gpg --dearmor -o /usr/share/keyrings/trivy.gpg
echo "deb [signed-by=/usr/share/keyrings/trivy.gpg] https://aquasecurity.github.io/trivy-repo/deb $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/trivy.list
sudo apt-get update && sudo apt-get install -y trivy

# RHEL/CentOS/AlmaLinux
sudo rpm --import https://aquasecurity.github.io/trivy-repo/rpm/public.key
cat << EOF | sudo tee /etc/yum.repos.d/trivy.repo
[trivy]
name=Trivy repository
baseurl=https://aquasecurity.github.io/trivy-repo/rpm/releases/\$basearch/
gpgcheck=1
enabled=1
gpgkey=https://aquasecurity.github.io/trivy-repo/rpm/public.key
EOF
sudo dnf install -y trivy

Konténer-képek vizsgálata

A Trivy leggyakoribb felhasználási esete a konténer-képek sebezhetőségvizsgálata. Egyetlen parancs, és máris van eredményed:

# Alapvető konténervizsgálat
trivy image nginx:latest

# Csak kritikus és magas súlyosságú találatok
trivy image --severity CRITICAL,HIGH nginx:latest

# JSON kimenet további feldolgozáshoz
trivy image --format json --output results.json nginx:latest

# Nem javított sebezhetőségek kiszűrése
trivy image --ignore-unfixed alpine:3.21

# Saját konténer-kép vizsgálata a build után
docker build -t myapp:latest .
trivy image myapp:latest

Egy jellemző vizsgálat 60 másodperc alatt lefut. Ez az, ami a Trivyt a CI/CD pipeline-okba való integráláshoz tökéletessé teszi — nem kell percekig (vagy órákig) várnod az eredményre.

Fájlrendszer és kódtár vizsgálata

A Trivy nem csak konténereket vizsgál. A forráskódban lévő sebezhetőségeket, titkokat és hibás konfigurációkat is felderíti:

# Aktuális projekt fájlrendszerének vizsgálata
trivy fs --scanners vuln,secret,misconfig .

# Git-tár távoli vizsgálata
trivy repo https://github.com/example/project

# IaC fájlok (Terraform, CloudFormation) vizsgálata
trivy config ./terraform/

# Kubernetes YAML manifesztek vizsgálata
trivy config ./k8s-manifests/

# Titkok (API-kulcsok, jelszavak) keresése
trivy fs --scanners secret /path/to/project

SBOM generálás és megfelelőségi vizsgálat

A szoftverlánc-biztonság (software supply chain security) egyre nagyobb súlyt kap 2026-ban — és nem véletlenül. Sok szabályozási keretrendszer (SOC2, NIST) megköveteli az SBOM (Software Bill of Materials) előállítását. A jó hír: a Trivy ezt natívan támogatja.

# SBOM generálása CycloneDX formátumban
trivy image --format cyclonedx --output sbom.json nginx:latest

# SBOM generálása SPDX formátumban
trivy image --format spdx-json --output sbom-spdx.json myapp:latest

# CIS benchmark vizsgálat Kubernetes klaszteren
trivy k8s --compliance k8s-cis-1.24 --report summary cluster

CI/CD integráció — GitHub Actions példa

A Trivy igazi ereje a fejlesztési folyamatba való zökkenőmentes integrációban rejlik. Az alábbi GitHub Actions munkafolyamat minden push után automatikusan megvizsgálja a konténer-képet:

name: Trivy sebezhetőségvizsgálat
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  trivy-scan:
    runs-on: ubuntu-latest
    steps:
      - name: Kódtár klónozása
        uses: actions/checkout@v4

      - name: Docker kép építése
        run: docker build -t myapp:${{ github.sha }} .

      - name: Trivy sebezhetőségvizsgálat
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: 'myapp:${{ github.sha }}'
          format: 'sarif'
          output: 'trivy-results.sarif'
          severity: 'CRITICAL,HIGH'
          exit-code: '1'

      - name: Eredmények feltöltése GitHub Security-be
        uses: github/codeql-action/upload-sarif@v3
        if: always()
        with:
          sarif_file: 'trivy-results.sarif'

Az exit-code: '1' beállítás azt jelenti, hogy a pipeline megbukik, ha kritikus vagy magas sebezhetőséget talál. Nem juthat át selejtes kód — pont ez a lényeg.

GitLab CI/CD integráció

Ha GitLab-ot használsz, a konfiguráció hasonlóan egyszerű:

trivy-scan:
  stage: test
  image:
    name: aquasec/trivy:latest
    entrypoint: [""]
  script:
    - trivy image --exit-code 1 --severity CRITICAL,HIGH $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    - trivy fs --exit-code 1 --severity CRITICAL,HIGH --scanners vuln,secret .
  allow_failure: false

OpenSCAP — Megfelelőségi vizsgálat és automatikus javítás

Az OpenSCAP egy teljesen más dimenzióból közelíti meg a biztonságot: a megfelelőség (compliance) oldaláról. Nem egyedi sebezhetőségeket keres, hanem azt ellenőrzi, hogy a rendszered megfelel-e előre definiált biztonsági szabványoknak — mint a CIS Benchmarks, DISA STIG vagy PCI-DSS.

Az OpenSCAP a NIST által definiált SCAP (Security Content Automation Protocol) szabvány nyílt forráskódú implementációja. XML-alapú biztonsági házirendeket olvas be, és a rendszered állapotát ezekhez méri. Kicsit száraz téma? Lehet. De hidd el, amikor egy auditor bekopog, nagyon örülni fogsz, hogy van egy szép HTML riportod.

Telepítés és profilok

# Debian/Ubuntu
sudo apt install -y libopenscap8 ssg-debian ssg-ubuntu

# RHEL/AlmaLinux/Rocky Linux
sudo dnf install -y openscap-scanner scap-security-guide

# Elérhető profilok listázása (RHEL 9 példa)
oscap info /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

A SCAP Security Guide (SSG) több CIS-profilt is tartalmaz disztribúciónként:

• cis — CIS Level 2 Server (a szigorúbb változat)
• cis_server_l1 — CIS Level 1 Server (alapszintű)
• cis_workstation_l1 — CIS Level 1 Workstation
• cis_workstation_l2 — CIS Level 2 Workstation
• stig — DISA STIG (katonai/kormányzati környezetekhez)
• pci-dss — PCI-DSS (kártyás fizetési rendszerekhez)

A legfrissebb RHEL 9-es CIS szabályzat verziója 2.0.0, ami az SSG 0.1.75 és újabb verzióiban érhető el.

CIS megfelelőségi vizsgálat futtatása

# CIS Level 1 Server vizsgálat HTML riporttal (RHEL 9)
sudo oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_server_l1 \
  --report /tmp/cis-report.html \
  --results /tmp/cis-results.xml \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

# Ubuntu 24.04 CIS vizsgálat
sudo oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
  --report /tmp/cis-ubuntu-report.html \
  /usr/share/xml/scap/ssg/content/ssg-ubuntu2404-ds.xml

# STIG vizsgálat (RHEL 9)
sudo oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_stig \
  --report /tmp/stig-report.html \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

A generált HTML-riport részletesen felsorolja minden szabály állapotát (pass/fail/notapplicable), a CVSS-pontszámot és a javítási javaslatot.

Egy fontos megjegyzés: 100%-os megfelelőség ritkán szükséges, és őszintén szólva nem is mindig praktikus. A cél a 90% feletti eredmény, amelyet a környezet sajátosságainak megfelelő, jól dokumentált kivételekkel egészítesz ki.

Automatikus javítás (remediation)

Az OpenSCAP egyik legértékesebb funkciója az automatikus javítás. Kétféle formátumban generálhatsz javító szkripteket — és ez rengeteg manuális munkát spórol meg:

# Bash szkript generálása a nem megfelelő elemekhez
sudo oscap xccdf generate fix \
  --fix-type bash \
  --profile xccdf_org.ssgproject.content_profile_cis_server_l1 \
  --output /tmp/cis-remediate.sh \
  /tmp/cis-results.xml

# Ansible playbook generálása
sudo oscap xccdf generate fix \
  --fix-type ansible \
  --profile xccdf_org.ssgproject.content_profile_cis_server_l1 \
  --output /tmp/cis-remediate.yml \
  /tmp/cis-results.xml

# FONTOS: Mindig tesztkörnyezetben próbáld ki először!
# A javító szkript futtatása
sudo bash /tmp/cis-remediate.sh

# Vagy Ansible-lel
ansible-playbook -i localhost, -c local /tmp/cis-remediate.yml

Figyelem: Az automatikus javítást soha ne futtasd közvetlenül éles rendszeren. Ezt nem lehet eléggé hangsúlyozni. Először tesztkörnyezetben ellenőrizd, hogy a javítások nem okoznak szolgáltatáskiesést — láttam már olyat, hogy egy túlbuzgó remediáció kiütötte az SSH-t, és onnan már csak a konzolon keresztül lehetett visszaállítani.

Konténer-képek vizsgálata OpenSCAP-pal

Az oscap-podman segítségével konténer-képeket is vizsgálhatsz CIS-szabványok alapján:

# UBI 9 konténer-kép CIS vizsgálata
sudo oscap-podman registry.access.redhat.com/ubi9/ubi:latest \
  xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis \
  --report /tmp/container-cis-report.html \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

Automatizált heti vizsgálat cron-nal

Az alábbi szkript egy komplett heti megfelelőségi vizsgálatot valósít meg, az eredmények naplózásával és a régi riportok automatikus takarításával:

#!/bin/bash
# /usr/local/bin/weekly-compliance-scan.sh
# Heti CIS megfelelőségi vizsgálat automatizálása

DATE=$(date +%Y%m%d)
REPORT_DIR="/var/log/compliance"
PROFILE="xccdf_org.ssgproject.content_profile_cis_server_l1"
CONTENT="/usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml"

mkdir -p "$REPORT_DIR"

# Vizsgálat futtatása
oscap xccdf eval \
  --profile "$PROFILE" \
  --report "$REPORT_DIR/cis-report-$DATE.html" \
  --results "$REPORT_DIR/cis-results-$DATE.xml" \
  "$CONTENT" 2>&1 | tee "$REPORT_DIR/scan-log-$DATE.txt"

# Összesítés kinyerése és naplózása
PASS=$(grep -c 'result="pass"' "$REPORT_DIR/cis-results-$DATE.xml" 2>/dev/null || echo 0)
FAIL=$(grep -c 'result="fail"' "$REPORT_DIR/cis-results-$DATE.xml" 2>/dev/null || echo 0)
TOTAL=$((PASS + FAIL))

if [ "$TOTAL" -gt 0 ]; then
  SCORE=$(echo "scale=1; $PASS * 100 / $TOTAL" | bc)
  logger -t compliance-scan "Heti CIS vizsgálat kész: $SCORE% ($PASS/$TOTAL szabály teljesítve)"
fi

# Régi riportok takarítása (90 napnál régebbiek)
find "$REPORT_DIR" -name "*.html" -mtime +90 -delete
find "$REPORT_DIR" -name "*.xml" -mtime +90 -delete

# Hozzáadás a crontab-hoz: minden vasárnap hajnali 3-kor
echo "0 3 * * 0 root /usr/local/bin/weekly-compliance-scan.sh" | sudo tee /etc/cron.d/compliance-scan
sudo chmod 644 /etc/cron.d/compliance-scan

A három eszköz együttes használata — Integrált sebezhetőségkezelés

Az OpenVAS, Trivy és OpenSCAP nem egymás versenytársai — éppen ellenkezőleg, kiegészítik egymást. Mindegyik más szintű és más típusú sebezhetőséget fed le:

Ajánlott vizsgálati ütemterv

Egy jól működő sebezhetőségkezelési programhoz az alábbi ütemtervet javaslom:

1. Minden commit/build (Trivy) — A CI/CD pipeline-ban minden konténer-kép és kódbázis automatikusan vizsgálva van. Kritikus találat esetén a pipeline megáll. Ez a legfontosabb lépés, mert itt fogjuk meg a problémákat a legkorábban.
2. Hetente (OpenSCAP) — Az éles szerverek CIS/STIG megfelelőségi vizsgálata automatikus cron job-ként fut. Az eredmények a biztonsági csapat dashboardjára kerülnek.
3. Havonta (OpenVAS) — Teljes hálózati sebezhetőségvizsgálat hitelesített módban. Az eredmények összehasonlítása az előző hónappal, új sebezhetőségek priorizálása CVSS és EPSS alapján.
4. Negyedévente — Az összes vizsgálati eredmény összesített áttekintése, trendek elemzése, javítási hatékonyság mérése. Ez az a pont, ahol kimutathatod a vezetőségnek, hogy a biztonsági befektetések megtérülnek.

Gyakori hibák és hibaelhárítás

A gyakorlatban néhány probléma rendszeresen felmerül. Mindannyian voltunk már ott — íme a leggyakoribbak és a megoldásuk.

OpenVAS: „Feed not synced" vagy üres vizsgálati eredmények

Az OpenVAS feed szinkronizáció az első telepítés után 30-60 percig tarthat. Ha a vizsgálat nem talál semmit, ne ess pánikba — először ellenőrizd a feed állapotát:

# Docker Compose környezetben
docker compose logs vulnerability-tests | tail -20

# Natív telepítésnél
sudo greenbone-feed-sync --type nvt
sudo greenbone-feed-sync --type scap
sudo greenbone-feed-sync --type cert

Trivy: lassú vizsgálat vagy elavult adatbázis

# Adatbázis manuális frissítése
trivy image --download-db-only

# Gyorsítótár törlése problémás viselkedés esetén
trivy clean --all

# Offline környezetben: adatbázis letöltése és átmásolása
trivy image --download-db-only --cache-dir /tmp/trivy-cache
# Majd az air-gapped szerverre másolás

OpenSCAP: „Profile not found" hiba

Ez az egyik legfrusztrálóbb hibaüzenet, de a megoldás általában egyszerű:

# Elérhető profilok listázása a konkrét disztribúcióhoz
oscap info /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml | grep "Profile"

# Ha a SSG csomag túl régi, frissítsd:
sudo dnf update scap-security-guide
# vagy
sudo apt update && sudo apt install --only-upgrade ssg-debian

Gyakran ismételt kérdések (GYIK)

Milyen gyakran kell sebezhetőségvizsgálatot futtatnom?

A legjobb gyakorlat szerint a konténer- és kódvizsgálatot (Trivy) minden build/deploy alkalommal érdemes futtatni. A hálózati vizsgálatot (OpenVAS) havonta, a megfelelőségi vizsgálatot (OpenSCAP) hetente ajánlott elvégezni. Ha szabályozási keretrendszer alá esel (PCI-DSS, SOC2), azok jellemzően negyedéves külső és éves belső vizsgálatot írnak elő — de a gyakoribb belső vizsgálat mindenképp megéri.

Az OpenVAS biztonságos használni éles hálózaton?

Az OpenVAS alapértelmezett „Full and fast" konfigurációja minimalizálja a szolgáltatáskiesés kockázatát, de minden aktív hálózati vizsgálat elméletileg hatással lehet instabil szolgáltatásokra. Éles környezetben mindig a karbantartási ablakban futtasd a vizsgálatot, és előtte tesztkörnyezetben validáld a beállításokat. És ami a legfontosabb: soha ne futtass vizsgálatot engedély nélkül — az engedély nélküli vizsgálat jogellenes.

Mi a különbség a Trivy és az OpenVAS között?

A kettő teljesen más megközelítést alkalmaz. Az OpenVAS hálózati szintű vizsgálatot végez: portokat szondáz, szolgáltatásokat azonosít, és a futó szoftverek ismert sebezhetőségeit ellenőrzi kívülről. A Trivy statikus elemzést végez: konténer-képek, forráskód és konfigurációs fájlok tartalmát vizsgálja ismert sebezhetőségek, titkos kulcsok és hibás konfigurációk után. A kettőt érdemes együtt használni, mert teljesen eltérő sebezhetőségeket fednek le.

Hogyan kezeljük a hamis pozitív találatokat?

Hamis pozitívok mindig lesznek — ez elkerülhetetlen. Az OpenVAS-ban a „Resolutions" funkcióval jelölheted ezeket, amelyek így a következő vizsgálatnál nem jelennek meg. A Trivy-ban .trivyignore fájlban listázhatod a kizárt CVE-ket (indoklással együtt). Az OpenSCAP-ban az --tailoring-file opcióval testre szabhatod a profilt. Minden esetben dokumentáld a kizárás okát és rendszeresen vizsgáld felül a kizárási listát — ami ma hamis pozitív, holnap már valódi probléma lehet.

Szükséges-e mindhárom eszközt használni?

Nem feltétlenül — de a legerősebb védelmet az adja, ha mindhárom réteget lefeded. Ha csak egyet választhatsz, a Trivy a legjobb kiindulópont, mert könnyen integrálható a fejlesztési folyamatba és a leggyorsabb visszajelzést adja. Ha infrastruktúrát üzemeltetsz konténerek nélkül, az OpenVAS + OpenSCAP kombináció adja a legteljesebb képet.