Linux-haavoittuvuusskannaus 2026: Trivy, OpenVAS ja Lynis käytännössä

Miksi haavoittuvuusskannaus on kriittistä vuonna 2026?

Tämä on asia, joka ei enää yllätä ketään: avoimen lähdekoodin riippuvuudet muodostavat valtaosan tuotantojärjestelmien koodista. Mutta numerot pysäyttävät silti — vuoden 2026 tutkimusten mukaan noin 74 prosenttia koodikannoista sisältää vähintään yhden korkean riskin haavoittuvuuden. Ja kun tekoälyavusteinen kehitys kiihdyttää koodin tuotantoa, mukaan tulee väistämättä tarkistamattomia riippuvuuksia ja hienovaraisia logiikkavirheitä.

Perinteinen ajoittainen skannaus ei yksinkertaisesti enää riitä.

Tässä oppaassa rakennamme kattavan haavoittuvuusskannausstrategian kolmella toisiaan täydentävällä työkalulla: Trivy kontti- ja koodiskannaukseen, OpenVAS (Greenbone Community Edition) verkkoskannaukseen ja Lynis järjestelmätason auditointiin. Käydään läpi asennukset, konfiguraatiot ja CI/CD-integraatiot käytännön esimerkkien avulla — ei pelkkää teoriaa.

Kolmen työkalun strategia: oikea työkalu oikeaan tehtävään

Yksikään haavoittuvuusskanneri ei kata kaikkia uhkavektoreita. Tämä on hyvä muistaa, koska houkutus turvautua yhteen ainoaan työkaluun on suuri. Tehokas strategia yhdistää useita työkaluja, joista jokaisella on oma vahvuusalueensa:

• Trivy — skannaa konttikuvia, tiedostojärjestelmiä, IaC-malleja, Git-repositorioita ja SBOM-tiedostoja. Tunnistaa CVE-haavoittuvuudet, virheelliset konfiguraatiot ja vuotaneet salaisuudet.
• OpenVAS / Greenbone — täysimittainen verkkoskanneri, joka testaa yli 160 000 tunnettua haavoittuvuutta todennetulla ja todentamattomalla skannauksella.
• Lynis — agenttipohjainen järjestelmäauditoija, joka tarkistaa Linux-konfiguraation CIS-vertailuarvojen mukaan ja ehdottaa korjaustoimenpiteitä.

Yhdessä nämä kolme kattavat melko hyvin koko pinon — koodista verkkoon ja käyttöjärjestelmään asti.

Trivy: konttien ja koodin haavoittuvuusskannaus

Trivyn asennus Linuxille

Trivy (versio 0.69, maaliskuu 2026) on yksi niistä harvoista tietoturvatyökaluista, joiden asennus on oikeasti helppoa. Se on yksittäinen binaari ilman tietokantariippuvuuksia tai väliohjelmistoja:

# Debian/Ubuntu
sudo apt-get install wget apt-transport-https gnupg lsb-release
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | \
  gpg --dearmor | sudo tee /usr/share/keyrings/trivy.gpg > /dev/null
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 trivy

# RHEL/CentOS/Fedora
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 yum install -y trivy

# Tarkista asennus
trivy --version

Konttikuvien skannaus

Trivyn ydinominaisuus on konttikuvien haavoittuvuusskannaus. Se tunnistaa haavoittuvuudet sekä käyttöjärjestelmäpaketeista (Alpine, Debian, Ubuntu, RHEL) että sovellusriippuvuuksista (npm, pip, Go, Maven, Cargo). Eli periaatteessa se kattaa sen, mitä oikeasti tarvitset:

# Perusskannaus
trivy image nginx:1.27

# Suodata vain kriittiset ja korkean tason haavoittuvuudet
trivy image --severity CRITICAL,HIGH nginx:1.27

# JSON-tuloste automaatiota varten
trivy image --format json --output results.json nginx:1.27

# Skannaa paikallinen Docker-kuva
trivy image --input ./my-app-image.tar

# Näytä vain korjattavissa olevat haavoittuvuudet
trivy image --ignore-unfixed nginx:1.27

Tuo --ignore-unfixed -lippu on muuten todella hyödyllinen arjessa. Ei ole mitään järkeä stressata haavoittuvuuksista, joihin ei vielä ole korjausta saatavilla.

Tiedostojärjestelmän ja IaC-skannaus

Trivy ei rajoitu pelkästään kontteihin — ja tämä on yksi sen parhaista puolista. Se skannaa myös tiedostojärjestelmiä, Terraform-malleja, Kubernetes-manifeesteja ja Dockerfile-tiedostoja:

# Skannaa projektin tiedostojärjestelmä
trivy fs --severity HIGH,CRITICAL /opt/my-project/

# Skannaa Terraform-konfiguraatiot
trivy config --severity HIGH,CRITICAL ./terraform/

# Skannaa Kubernetes-manifeestit
trivy config ./k8s-manifests/

# Skannaa Git-repositorio
trivy repo https://github.com/example/my-app

# Etsi vuotaneet salaisuudet (API-avaimet, salasanat)
trivy fs --scanners secret /opt/my-project/

Erityisesti tuo salaisuusskannaus on pelastus. Olen itse nähnyt tilanteita, joissa API-avaimia on päätynyt repositorioihin vahingossa — ja mitä aikaisemmin ne löytää, sen parempi.

SBOM-generointi ja VEX-tuki

Software Bill of Materials (SBOM) on noussut keskeiseksi osaksi toimitusketjun turvallisuutta. Vuonna 2026 se ei ole enää "nice to have" vaan käytännössä pakollinen monilla toimialoilla. Trivy generoi SBOM:n CycloneDX- ja SPDX-formaateissa:

# Generoi CycloneDX SBOM konttikuvasta
trivy image --format cyclonedx --output sbom.json nginx:1.27

# Generoi SPDX SBOM
trivy image --format spdx-json --output sbom-spdx.json nginx:1.27

# Skannaa olemassa oleva SBOM haavoittuvuuksista
trivy sbom ./sbom.json

Trivyn .trivyignore ja konfiguraatio

Väärien positiivisten hallinta on tärkeää, varsinkin tuotantoympäristöissä. Kukaan ei halua hälytysväsymystä, jossa oikeat ongelmat hukkuvat turhien ilmoitusten joukkoon. Luo .trivyignore-tiedosto projektin juureen:

# .trivyignore — hylätyt haavoittuvuudet
# Dokumentoi syy ja aseta vanhentumispäivä

# CVE ei vaikuta meidän käyttötapaukseemme (exp: 2026-06-01)
CVE-2024-12345
# Odottaa upstream-korjausta
CVE-2025-67890

Keskitetty konfiguraatio trivy.yaml-tiedostolla pitää asetukset hallinnassa koko tiimille:

# trivy.yaml
severity:
  - CRITICAL
  - HIGH
ignore-unfixed: true
exit-code: 1
format: table
timeout: 10m
db:
  skip-update: false

OpenVAS / Greenbone Community Edition: verkkohaavoittuvuusskannaus

Greenbone Community Editionin asennus Dockerilla

OpenVAS on osa Greenbone Vulnerability Management (GVM) -pinoa, ja rehellisesti sanottuna sen asennus on perinteisesti ollut melko työläs prosessi. Onneksi konttipohjainen ratkaisu tekee siitä huomattavasti helpompaa. Greenbone tarjoaa yli 160 000 haavoittuvuustestiä (NVT) päivittäin päivittyvällä syötteellä:

# Luo hakemisto Greenbone-datalle
mkdir -p /opt/greenbone && cd /opt/greenbone

# Lataa docker-compose.yml
curl -f -L https://greenbone.github.io/docs/latest/_static/docker-compose-24.1.yml \
  -o docker-compose.yml

# Lataa ja käynnistä kaikki palvelut
docker compose -f docker-compose.yml -p greenbone-community-edition pull
docker compose -f docker-compose.yml -p greenbone-community-edition up -d

# Odota NVT-syötteen latautumista (voi kestää 15-30 min)
docker compose -f docker-compose.yml -p greenbone-community-edition \
  logs -f ospd-openvas

# Aseta admin-salasana
docker compose -f docker-compose.yml -p greenbone-community-edition \
  exec -u gvmd gvmd gvmd --user=admin --new-password=VahvaSalasana123!

Greenbone-verkkoliittymä on käytettävissä osoitteessa https://localhost:443 (aiemmin portti 9392, mutta nykyisin HTTPS on oletuksena). Huomaa, että NVT-syötteen ensimmäinen lataus vie aikaa — tee se mielellään illalla ja anna koneen pyöriä yön yli.

Ensimmäinen verkkoskannaus

Verkkoliittymän kautta voit luoda skannauskohteita ja -tehtäviä graafisesti. Jos taas pidät komentorivillä työskentelystä (kuten monet meistä), gvm-tools mahdollistaa automatisoinnin:

# Asenna gvm-tools
pip3 install gvm-tools

# Luo kohde ja tehtävä komentorivillä
gvm-cli --gmp-username admin --gmp-password VahvaSalasana123! \
  socket --socketpath /run/gvmd/gvmd.sock \
  --xml "<create_target><name>Web-palvelin</name><hosts>192.168.1.100</hosts></create_target>"

# Listaa käytettävissä olevat skannausprofiiilit
gvm-cli --gmp-username admin --gmp-password VahvaSalasana123! \
  socket --socketpath /run/gvmd/gvmd.sock \
  --xml "<get_configs/>"

Skannausprofiilien valinta

Greenbone tarjoaa useita esikonfiguroituja profiileja. Oikean valinta riippuu tilanteesta:

• Full and Fast — kattavin skannaus kaikille NVT-testeille. Tämä on suositeltava valinta useimmille tuotantoympäristöille.
• Full and Deep — perusteellisempi mutta hitaampi ja kuormittavampi. Käytä harkiten.
• Host Discovery — pelkkä verkkotunnistus ilman haavoittuvuustestausta.
• System Discovery — tunnistaa käyttöjärjestelmät ja palvelut.

Todennettu skannaus SSH:lla

Tässä on iso käytännön ero: todennettu skannaus löytää tyypillisesti 40–60 prosenttia enemmän haavoittuvuuksia kuin todentamaton, koska se pääsee käsiksi järjestelmän sisäisiin pakettitietoihin. Pieni lisävaiva, suuri hyöty.

# Luo SSH-avainpari skannaukseen
ssh-keygen -t ed25519 -f /opt/greenbone/scan-key -N "" -C "openvas-scanner"

# Kopioi julkinen avain kohdejärjestelmiin
ssh-copy-id -i /opt/greenbone/scan-key.pub [email protected]

# Kohdejärjestelmässä: luo rajoitettu skannaustiili
sudo useradd -r -s /bin/bash -d /home/scan-user scan-user
echo "scan-user ALL=(root) NOPASSWD: /usr/bin/apt list --installed, \
  /usr/bin/rpm -qa, /usr/sbin/dmidecode" | sudo tee /etc/sudoers.d/openvas-scan

Tärkeä huomio: skannaustilin oikeudet kannattaa pitää mahdollisimman rajoitettuina. Yllä oleva sudoers-konfiguraatio antaa vain ne komennot, joita OpenVAS oikeasti tarvitsee.

Lynis: järjestelmätason turvallisuusauditointi

Lynisin asennus ja peruskäyttö

Lynis on kevyt ja nopea järjestelmäauditoija — oma suosikkini nopeaan tilannekuvaan palvelimen turvallisuudesta. Se tarkistaa Linux-konfiguraation satojen testien avulla, vertaa asetuksia CIS-vertailuarvoihin ja tuottaa konkreettisia koventamissuosituksia:

# Asennus paketinhallinnasta
sudo apt-get install lynis    # Debian/Ubuntu
sudo yum install lynis        # RHEL/CentOS

# Tai suoraan Git-repositoriosta (uusin versio)
cd /opt
sudo git clone https://github.com/CISOfy/lynis
cd lynis

# Suorita täysi järjestelmäauditointi
sudo lynis audit system

# Suorita auditointi ja tallenna raportti
sudo lynis audit system --report-file /var/log/lynis-report.dat

# Tarkista vain tietty kategoria
sudo lynis audit system --tests-from-group "firewalls"
sudo lynis audit system --tests-from-group "ssh"
sudo lynis audit system --tests-from-group "authentication"

Lynis-tulosten tulkinta

Lynis tuottaa Hardening Index -pisteet (0–100), joka kertoo järjestelmän koventamisen tason. Uudelle palvelimelle tyypillinen pistemäärä on jossain 50–65 tienoilla, joten älä hätkähdä jos ensimmäinen tulos näyttää matalalta. Lisäksi Lynis listaa:

• Varoitukset (Warnings) — välittömästi korjattavat ongelmat
• Ehdotukset (Suggestions) — suositellut parannukset prioriteettijärjestyksessä
• Löydökset (Findings) — yleistä tietoa järjestelmän tilasta

# Näytä vain varoitukset
sudo grep Warning /var/log/lynis-report.dat

# Näytä ehdotukset prioriteettijärjestyksessä
sudo grep Suggestion /var/log/lynis-report.dat | sort -t: -k2 -rn

# Vertaile kahden auditoinnin tuloksia
diff /var/log/lynis-report-before.dat /var/log/lynis-report-after.dat

Mukautettu Lynis-profiili

Organisaatiokohtainen profiili on käytännössä pakollinen, kun Lynisiä käytetään systemaattisesti useilla palvelimilla. Se määrittelee skannausasetukset ja kynnysarvot yhdenmukaisesti:

# /etc/lynis/custom.prf

# Minimi Hardening Index tuotantopalvelimille
min-hardening-index=75

# Ohita testit, jotka eivät sovellu ympäristöömme
skip-test=FILE-6310
skip-test=KRNL-5820

# Ota käyttöön lisätestit
test-group=malware
test-group=crypto

# Hälytysasetukset
warnings-only=no
show-report-solution=yes

CI/CD-integraatio: automatisoitu haavoittuvuusskannaus

Tässä kohtaa asiat alkavat mennä todella mielenkiintoisiksi. Manuaalinen skannaus on hyvä alku, mutta oikea voima tulee automaatiosta. Kun haavoittuvuusskannaus on osa CI/CD-putkea, mikään ei pääse tuotantoon tarkistamattomana.

GitHub Actions -työnkulku Trivyllä

Seuraava työnkulku skannaa jokaisen pull requestin ja estää yhdistämisen, jos kriittisiä haavoittuvuuksia löytyy:

# .github/workflows/security-scan.yml
name: Security Scan Pipeline
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  trivy-image-scan:
    name: Konttikuvan haavoittuvuusskannaus
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Build Docker image
        run: docker build -t my-app:${{ github.sha }} .

      - name: Trivy - konttikuvan skannaus
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: my-app:${{ github.sha }}
          format: table
          exit-code: 1
          severity: CRITICAL,HIGH
          ignore-unfixed: true

  trivy-iac-scan:
    name: IaC-konfiguraatioskannaus
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Trivy - IaC-skannaus
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: config
          scan-ref: .
          exit-code: 1
          severity: CRITICAL,HIGH

  trivy-secret-scan:
    name: Salaisuuksien skannaus
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Trivy - salaisuusskannaus
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: fs
          scanners: secret
          scan-ref: .
          exit-code: 1

GitLab CI -putkikonfiguraatio

Jos tiimisi käyttää GitLabia, vastaava konfiguraatio näyttää tältä:

# .gitlab-ci.yml
stages:
  - build
  - security-scan

variables:
  TRIVY_SEVERITY: "CRITICAL,HIGH"
  TRIVY_EXIT_CODE: "1"

build-image:
  stage: build
  image: docker:latest
  services:
    - docker:dind
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

trivy-scan:
  stage: security-scan
  image:
    name: aquasec/trivy:latest
    entrypoint: [""]
  script:
    - trivy image
        --exit-code $TRIVY_EXIT_CODE
        --severity $TRIVY_SEVERITY
        --ignore-unfixed
        --format template
        --template "@/contrib/gitlab.tpl"
        --output gl-container-scanning-report.json
        $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    - trivy image
        --exit-code 0
        --severity $TRIVY_SEVERITY
        --format table
        $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  artifacts:
    reports:
      container_scanning: gl-container-scanning-report.json
  cache:
    paths:
      - .trivycache/
  allow_failure: false

Automatisoitu Lynis-auditointi cronjobilla

Lynis-auditoinnin voi (ja kannattaa) ajastaa suoritettavaksi säännöllisesti. Seuraava skripti suorittaa auditoinnin, tarkistaa tulokset ja lähettää hälytyksen tarvittaessa:

#!/bin/bash
# /opt/scripts/lynis-audit.sh
# Ajastettu järjestelmäauditointi ja raportointi

REPORT_DIR="/var/log/lynis"
DATE=$(date +%Y-%m-%d)
HOSTNAME=$(hostname -f)
MIN_SCORE=75

mkdir -p "$REPORT_DIR"

# Suorita auditointi
lynis audit system --no-colors --report-file "$REPORT_DIR/report-$DATE.dat" \
  --log-file "$REPORT_DIR/audit-$DATE.log" > "$REPORT_DIR/output-$DATE.txt" 2>&1

# Hae Hardening Index
SCORE=$(grep "hardening_index" "$REPORT_DIR/report-$DATE.dat" | cut -d= -f2)

# Hae varoitusten määrä
WARNINGS=$(grep -c "^warning\[\]" "$REPORT_DIR/report-$DATE.dat")

# Hälytys, jos pisteet alle kynnysarvon
if [ "$SCORE" -lt "$MIN_SCORE" ]; then
  echo "HÄLYTYS: $HOSTNAME Lynis-pisteet $SCORE/$MIN_SCORE (varoituksia: $WARNINGS)" | \
    mail -s "Lynis-auditointi: pisteet alle kynnysarvon" [email protected]
fi

# Lähetä metriikat valvontajärjestelmään (esim. Prometheus pushgateway)
cat << EOF | curl --data-binary @- http://pushgateway:9091/metrics/job/lynis/instance/$HOSTNAME
lynis_hardening_index $SCORE
lynis_warnings_total $WARNINGS
EOF

# Lisää crontab-merkintä (suoritus joka yö klo 03:00)
echo "0 3 * * * root /opt/scripts/lynis-audit.sh" | sudo tee /etc/cron.d/lynis-audit
sudo chmod 644 /etc/cron.d/lynis-audit

Tulosten yhdistäminen ja priorisointi

DefectDojo: keskitetty haavoittuvuuksien hallinta

Kun käytössä on useita skannaustyökaluja (kuten meidän kolmen työkalun strategia), tulokset on koottava yhteen — muuten hallinta muuttuu nopeasti kaoottiseksi. DefectDojo on avoimen lähdekoodin haavoittuvuuksien hallinta-alusta, joka aggregoi löydökset yli 200 eri työkalusta, poistaa duplikaatit ja yhdistää ne vaatimustenmukaisuuskehyksiin:

# Tuo Trivy-tulokset DefectDojoon API:n kautta
curl -X POST "https://defectdojo.example.com/api/v2/import-scan/" \
  -H "Authorization: Token YOUR_API_TOKEN" \
  -F "scan_type=Trivy Scan" \
  -F "[email protected]" \
  -F "product_name=My Application" \
  -F "engagement_name=CI/CD Scan" \
  -F "active=true" \
  -F "verified=false"

# Tuo OpenVAS-tulokset
curl -X POST "https://defectdojo.example.com/api/v2/import-scan/" \
  -H "Authorization: Token YOUR_API_TOKEN" \
  -F "scan_type=OpenVAS CSV" \
  -F "[email protected]" \
  -F "product_name=Infrastructure" \
  -F "engagement_name=Network Scan Q1 2026"

Priorisointimatriisi

Kaikkia haavoittuvuuksia ei voi korjata samaan aikaan — eikä pidäkään. Priorisointi on avain siihen, että käytettävissä oleva aika kohdistuu oikeisiin asioihin:

• P0 (Välitön) — CVSS 9.0+, aktiivinen hyväksikäyttö, julkisessa verkossa oleva palvelu. Korjaa 24 tunnin sisällä.
• P1 (Kriittinen) — CVSS 7.0–8.9, korjaus saatavilla, tuotantopalvelimella. Korjaa 7 päivän sisällä.
• P2 (Korkea) — CVSS 4.0–6.9 tai sisäisessä verkossa. Korjaa 30 päivän sisällä.
• P3 (Matala) — CVSS alle 4.0, ei suoraa hyökkäysvektoria. Korjaa seuraavassa huoltoikkunassa.

Näitä aikaikkunoita kannattaa käsitellä tavoitteina, ei absoluuttisina rajoina. Tärkeintä on, että prosessi on systemaattinen ja dokumentoitu.

Vaatimustenmukaisuus ja raportointi

Haavoittuvuusskannaus ei ole pelkkä tekninen harjoitus — se tukee myös useita vaatimustenmukaisuuskehyksiä, joita organisaatiot joutuvat noudattamaan:

• PCI DSS 4.0 — vaatimus 6.3.3: sisäinen ja ulkoinen haavoittuvuusskannaus vähintään neljännesvuosittain
• ISO 27001:2022 — liite A.8.8: teknisten haavoittuvuuksien hallinta
• CIS Controls v8 — kontrolli 7: jatkuva haavoittuvuuksien hallinta
• Cyber Resilience Act (EU) — vaatimus haavoittuvuusskannauksen integroinnista ohjelmistokehityksen elinkaareen

Erityisesti EU:n Cyber Resilience Act on tuonut uusia vaatimuksia, jotka koskettavat käytännössä kaikkia ohjelmistotuottajia Euroopassa.

# OpenSCAP CIS-vertailuarvotarkistus (täydentää Lynistä)
sudo apt-get install libopenscap8 ssg-debian
oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
  --results /var/log/oscap-results.xml \
  --report /var/log/oscap-report.html \
  /usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml

Parhaat käytännöt tuotantoympäristöissä

Lopuksi kootaan yhteen tärkeimmät käytännöt, jotka olen nähnyt toimivan hyvin oikeissa tuotantoympäristöissä:

• Skannaa aikaisin ja usein — integroi Trivy esikäännöskoukuihin, CI-putkiin ja Kubernetes-admission-kontrollereihin. Mitä aikaisemmin haavoittuvuus löytyy, sen halvempi se on korjata.
• Käytä porrastettuja kynnysarvoja — estä CRITICAL ja HIGH tuotannossa, salli MEDIUM kehitysympäristössä. Liian tiukat säännöt kehityksessä turhauttavat tiimin.
• Yhdistä todennettu ja todentamaton skannaus — OpenVAS-todennettu skannaus löytää merkittävästi enemmän haavoittuvuuksia. Se on pieni lisävaiva, joka kannattaa aina.
• Automatisoi korjaukset — käytä Dependabotia tai Renovatea riippuvuuspäivitysten automatisointiin. Vähemmän manuaalista työtä, nopeammat korjaukset.
• Dokumentoi poikkeukset — jokainen .trivyignore-merkintä ja hyväksytty riski on dokumentoitava syyn ja vanhentumispäivän kanssa. Ilman dokumentaatiota poikkeukset muuttuvat pysyviksi.
• Seuraa metriikoita — mittaa keskimääräinen korjausaika (MTTR), avoimien haavoittuvuuksien määrä ja Lynis Hardening Index ajan yli. Ilman mittareita et tiedä, paraneeko tilanne vai huononeeko.

Usein kysytyt kysymykset

Mikä on paras haavoittuvuusskanneri Linuxille?

Lyhyt vastaus: ei ole yhtä parasta. Paras strategia yhdistää useita skannereita eri käyttötarkoituksiin. Trivy on erinomainen konttien ja koodin skannaukseen, OpenVAS verkkotason haavoittuvuuksiin ja Lynis järjestelmäkonfiguraation auditointiin. DevSecOps-putkeen valitse Trivy, infrastruktuuriskannaukseen OpenVAS ja vaatimustenmukaisuusauditointiin Lynis yhdessä OpenSCAPin kanssa.

Kuinka usein haavoittuvuusskannaus tulisi suorittaa?

CI/CD-putkessa Trivy-skannaus tulisi suorittaa jokaisen koodimuutoksen yhteydessä — tämä on käytännössä ilmaista, koska se kestää vain sekunteja. Verkkoskannaus OpenVASilla suositellaan vähintään viikoittain sisäisille järjestelmille ja kuukausittain ulkoisille. Lynis-auditointi kannattaa ajaa päivittäin tuotantopalvelimilla. PCI DSS 4.0 vaatii haavoittuvuusskannauksen vähintään neljännesvuosittain, mutta jatkuva skannaus on ehdottomasti paras käytäntö.

Onko Trivy vai Grype parempi konttiskannaukseen?

Molemmat ovat laadukkaita avoimen lähdekoodin skannereita. Trivy tarjoaa laajemman kattavuuden (kontit, IaC, SBOM, salaisuudet, Kubernetes), kun taas Grype keskittyy pelkästään haavoittuvuusskannaukseen ja on hieman nopeampi yksittäisissä skannauksissa. Jos haluat yhden työkalun useaan käyttötapaukseen, Trivy on parempi valinta. Grype taas soveltuu tilanteisiin, joissa tarvitset vain CVE-skannauksen ja käytät jo Syftia SBOM-generointiin.

Miten OpenVAS eroaa Nessuksesta?

OpenVAS (Greenbone Community Edition) on avoimen lähdekoodin ratkaisu, joka syntyi alun perin Nessuksen haarautumana. Nessus on kaupallinen tuote, jossa on laajempi haavoittuvuustietokanta ja parempi tekninen tuki. OpenVAS tarjoaa yli 160 000 haavoittuvuustestiä ja sopii erinomaisesti organisaatioille, jotka haluavat täyden hallinnan skannausinfrastruktuuristaan ilman lisenssikustannuksia. Käytännössä molemmat hoitavat homman — valinta riippuu budjetista ja tukitarpeista.

Voiko haavoittuvuusskannaus aiheuttaa häiriöitä tuotantoympäristössä?

Kyllä, ja tämä on tärkeä asia tiedostaa. Erityisesti verkkoskannaus voi kuormittaa kohteita. Trivyn staattinen analyysi on turvallista suorittaa milloin tahansa — se ei ota yhteyttä mihinkään. OpenVAS-skannaukset sen sijaan tulisi ajastaa huoltoikkunoiden aikana tai käyttää "Safe checks" -asetusta, joka välttää potentiaalisesti häiritseviä testejä. Aloita aina todentamattomalla skannauksella ennen aggressiivisempien profiilien käyttöä tuotannossa.