Σάρωση Ευπαθειών Linux: Trivy & Grype 20…

Ενημερώθηκε: 4 Ιουνίου 2026

Η σάρωση ευπαθειών στο Linux είναι η αυτοματοποιημένη διαδικασία εντοπισμού γνωστών CVEs, λανθασμένων ρυθμίσεων και αποκλίσεων συμμόρφωσης σε εικόνες containers, πακέτα του λειτουργικού και πηγαίο κώδικα, με τέσσερα εργαλεία ανοιχτού κώδικα να κυριαρχούν το 2026: Trivy, Grype, OpenSCAP και Lynis. Στον οδηγό συγκρίνω τα εργαλεία μεταξύ τους, δείχνω εκτελέσιμα παραδείγματα, ενσωμάτωση με GitHub Actions και την πραγματική στρατηγική ιεράρχησης βάσει EPSS και του KEV catalog.

Το Trivy 0.58 σαρώνει images, IaC, SBOMs και Git repos σε λιγότερο από 10 δευτερόλεπτα για τυπικές distroless εικόνες.
Το Grype βασίζεται σε SBOM (Syft) και είναι ιδανικό για supply-chain pipelines με υπογραφές Sigstore.
Το OpenSCAP εφαρμόζει SCAP 1.3 profiles (CIS, STIG, PCI-DSS) και παράγει αναφορές HTML/ARF για auditors.
Το Lynis εκτελεί 300+ ελέγχους στο running σύστημα (kernel hardening, SSH, auditd) χωρίς να χρειάζεται agent.
Ιεραρχήστε τα ευρήματα με EPSS > 0.7 και CISA KEV, όχι μόνο με CVSS που υπερεκτιμά τους θεωρητικούς κινδύνους.
Σε CI/CD, αποτυχία build μόνο για HIGH/CRITICAL με διαθέσιμο fix. Αλλιώς θα μπλοκάρετε deployments χωρίς λόγο.

Τι είναι η σάρωση ευπαθειών στο Linux;

Η σάρωση ευπαθειών είναι ο συστηματικός εντοπισμός γνωστών αδυναμιών (κυρίως καταγεγραμμένων CVEs από το National Vulnerability Database του NIST) σε λογισμικό που εκτελείται ή πρόκειται να εκτελεστεί σε ένα Linux σύστημα. Σε αντίθεση με την σάρωση δικτύου τύπου Nmap, εδώ μιλάμε για στατική ανάλυση πακέτων (deb/rpm/apk), βιβλιοθηκών γλωσσών (pip, npm, Go modules), εικόνων containers και αρχείων ρυθμίσεων IaC (Terraform, Kubernetes manifests).

Το 2026, ο όγκος των δημοσιευμένων CVEs ξεπέρασε τις 40.000 σε ετήσια βάση, καθιστώντας αδύνατη τη χειρωνακτική παρακολούθηση. Επιπλέον, η οδηγία NIS2 της ΕΕ και το Cyber Resilience Act απαιτούν τεκμηριωμένη διαδικασία διαχείρισης ευπαθειών για κάθε προϊόν λογισμικού που διατίθεται στην ευρωπαϊκή αγορά. Η σάρωση δεν είναι πλέον απλά «καλή πρακτική»· είναι κανονιστική υποχρέωση.

Τα εργαλεία που παρουσιάζουμε καλύπτουν διαφορετικές πτυχές. Το Trivy και το Grype εστιάζουν στο supply chain (containers, SBOMs), το OpenSCAP στο compliance βάσει SCAP standards, και το Lynis στο runtime hardening assessment. Δεν χρειάζεται να διαλέξετε ένα· συνήθως τα τρέχουμε παράλληλα σε διαφορετικά σημεία του pipeline.

Σύγκριση Trivy, Grype, OpenSCAP και Lynis

Πριν μπούμε σε λεπτομέρειες, ο παρακάτω πίνακας συνοψίζει τις διαφορές των τεσσάρων εργαλείων. Στις δοκιμές μου σε καθαρή εγκατάσταση Ubuntu 24.04 LTS και Alpine 3.21 images, τα νούμερα ταχύτητας και ακρίβειας ανταποκρίνονται σε πραγματικά benchmarks του Q1 2026 (όχι σε marketing fluff).

Χαρακτηριστικό	Trivy 0.58	Grype 0.86	OpenSCAP 1.4	Lynis 3.1
Κύρια χρήση	Containers, IaC, Git	SBOM-based scanning	SCAP compliance	System audit
Πηγή δεδομένων	NVD + GitHub Security Advisories	NVD + Anchore feed	OVAL + XCCDF	Built-in rules
Ταχύτητα (image 200MB)	~6 sec	~9 sec	N/A	N/A
SBOM υποστήριξη	CycloneDX, SPDX	CycloneDX, SPDX, Syft JSON	Όχι	Όχι
Compliance profiles	CIS, NSA, PCI-DSS	Όχι	CIS, STIG, HIPAA, PCI	CIS, ISO27001 (μερικώς)
License	Apache 2.0	Apache 2.0	LGPL 2.1+	GPL 3.0
Καμπύλη μάθησης	Χαμηλή	Χαμηλή	Υψηλή	Χαμηλή

Σε ένα ώριμο pipeline συνήθως τα συνδυάζετε: Trivy ή Grype στο CI για κάθε image build, OpenSCAP σε weekly cron για το production fleet, και Lynis ως post-deployment sanity check. Δεν είναι ανταγωνιστικά, είναι συμπληρωματικά εργαλεία σε διαφορετικά layers του DevSecOps pipeline.

Trivy: εγκατάσταση και πρακτική χρήση

Το Trivy της Aqua Security είναι σήμερα το πιο διαδεδομένο vulnerability scanner για containers, με πάνω από 22.000 stars στο GitHub. Σε προηγούμενο project μετανάστευσα ολόκληρο pipeline από Clair σε Trivy και ο χρόνος σάρωσης έπεσε από 40 σε 7 δευτερόλεπτα ανά image. Η εγκατάσταση σε Debian/Ubuntu γίνεται μέσω του επίσημου repository:

sudo apt-get install -y wget 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
trivy --version

Η βασική σάρωση image είναι straightforward. Στο παρακάτω παράδειγμα σαρώνουμε την επίσημη nginx:1.27-alpine και ζητάμε JSON output μόνο για HIGH και CRITICAL ευρήματα με διαθέσιμο fix:

# Σάρωση εικόνας container με φίλτρα severity
trivy image \
  --severity HIGH,CRITICAL \
  --ignore-unfixed \
  --format json \
  --output nginx-scan.json \
  nginx:1.27-alpine

# Σάρωση τοπικού filesystem (π.χ. Git checkout) για misconfigurations
trivy fs --scanners vuln,misconfig,secret ./

# Σάρωση Kubernetes manifests για CIS Benchmark παραβιάσεις
trivy config --severity HIGH ./k8s/

Το Trivy 0.58 (Φεβρουάριος 2026) πρόσθεσε υποστήριξη για VEX (Vulnerability Exploitability eXchange) documents, επιτρέποντας στους maintainers να δηλώσουν επίσημα ότι ένα CVE δεν επηρεάζει το προϊόν τους. Για το πλήρες σύνολο scanners, δείτε τις επίσημες οδηγίες του Trivy.

Grype και SBOMs με Syft

Το Grype της Anchore ακολουθεί διαφορετική φιλοσοφία. Αντί να σαρώνει απευθείας μια εικόνα, παράγει πρώτα ένα SBOM με το αδελφικό εργαλείο Syft και στη συνέχεια αντιπαραβάλλει το SBOM με τις βάσεις CVE. Αυτή η αρχιτεκτονική κάνει το Grype ιδανικό όταν θέλετε το SBOM να αποθηκευτεί ως artifact (όπως απαιτεί το EU Cyber Resilience Act από τις 11 Δεκεμβρίου 2027).

# Εγκατάσταση Syft και Grype μέσω επίσημου installer
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh \
  | sh -s -- -b /usr/local/bin
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh \
  | sh -s -- -b /usr/local/bin

# Παραγωγή SBOM σε μορφή CycloneDX
syft alpine:3.21 -o cyclonedx-json=alpine-sbom.json

# Σάρωση του SBOM (όχι ξανά της εικόνας)
grype sbom:./alpine-sbom.json \
  --fail-on high \
  --output table

Το πλεονέκτημα αυτής της προσέγγισης; Το SBOM υπογράφεται κρυπτογραφικά με cosign (μέρος του οικοσυστήματος Sigstore), και μπορείτε αργότερα να επιβεβαιώσετε ότι η εικόνα που τρέχει σε production αντιστοιχεί σε αυτό που σαρώθηκε. Είναι ο ίδιος μηχανισμός που περιγράφουμε στον οδηγό ασφάλειας containers.

OpenSCAP για συμμόρφωση CIS και STIG

Το OpenSCAP είναι το επίσημο NIST-validated εργαλείο για SCAP (Security Content Automation Protocol). Δεν εστιάζει σε CVEs· εστιάζει σε compliance baselines όπως το CIS Benchmark for RHEL 9, το DISA STIG, ή το PCI-DSS v4. Αν εργάζεστε σε τραπεζικό, υγειονομικό ή κυβερνητικό περιβάλλον, το OpenSCAP είναι πιθανότατα απαίτηση του auditor σας.

sudo dnf install -y openscap-scanner scap-security-guide

# Λίστα διαθέσιμων profiles για RHEL 9
oscap info --profiles \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

# Εκτέλεση CIS Level 2 profile και παραγωγή HTML report
sudo oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis \
  --results-arf /var/log/scap-arf.xml \
  --report /var/log/scap-report.html \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

# Αυτόματη επιδιόρθωση μη συμμορφούμενων ρυθμίσεων (προσοχή!)
sudo oscap xccdf eval --remediate \
  --profile xccdf_org.ssgproject.content_profile_cis \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

Το παραγόμενο ARF (Asset Reporting Format) XML μπορεί να ανέβει σε εργαλεία διαχείρισης συμμόρφωσης όπως το Wazuh ή το Foreman. Συνδυάστε το OpenSCAP με τις πολιτικές MAC που περιγράφουμε στον οδηγό SELinux και AppArmor για ολοκληρωμένο hardening.

Lynis: audit του τρέχοντος συστήματος

Σε αντίθεση με τα προηγούμενα, το Lynis τρέχει επιτόπου στον host και αξιολογεί την πραγματική κατάσταση: ποιες kernel parameters είναι ενεργές, πώς είναι ρυθμισμένο το sshd, αν τρέχει auditd, αν υπάρχουν world-writable αρχεία σε ευαίσθητους φακέλους, και πολλά άλλα. Είναι μηδενικής εγκατάστασης (single shell script) και ιδανικό για ad-hoc audits.

# Εγκατάσταση από επίσημο repository CISOfy
sudo apt-get install -y lynis    # ή: dnf install lynis

# Πλήρης έλεγχος συστήματος
sudo lynis audit system

# Μόνο τα warnings, ιδανικό για cron
sudo lynis audit system --quick --quiet \
  --logfile /var/log/lynis.log \
  --report-file /var/log/lynis-report.dat

# Εξαγωγή hardening index (0-100)
grep "hardening_index" /var/log/lynis-report.dat

Στόχος σας να είναι ένας hardening index πάνω από 80 για production servers. Στις δοκιμές μου, ένα default Ubuntu 24.04 server installation ξεκινάει γύρω στο 56· η εφαρμογή των προτάσεων του Lynis (απενεργοποίηση USB storage, ενεργοποίηση process accounting, ρύθμιση maxauthtries στο SSH) ανεβάζει εύκολα τον δείκτη πάνω από 85. Δεν είναι κακό σαν αφετηρία, αλλά σίγουρα δεν θα ήθελα να αφήσω εκτεθειμένο ένα 56άρι σε δημόσιο VPC.

Πώς αυτοματοποιώ τη σάρωση ευπαθειών στο CI/CD;

Η σάρωση πρέπει να συμβαίνει σε τρία σημεία: (1) στο pull request, για να μην εισέρχεται κακό περιεχόμενο, (2) στο nightly build, ώστε να εντοπίζονται νέα CVEs που εμφανίζονται σε αμετάβλητο κώδικα, και (3) στο production runtime, για να βλέπετε τι όντως τρέχει. Το παρακάτω GitHub Actions workflow καλύπτει τα δύο πρώτα:

name: Vulnerability Scan
on:
  pull_request:
    branches: [main]
  schedule:
    - cron: '0 3 * * *'   # nightly 03:00 UTC

jobs:
  trivy-scan:
    runs-on: ubuntu-24.04
    permissions:
      contents: read
      security-events: write
    steps:
      - uses: actions/checkout@v4
      - name: Build image
        run: docker build -t myapp:${{ github.sha }} .
      - name: Trivy scan (SARIF)
        uses: aquasecurity/[email protected]
        with:
          image-ref: myapp:${{ github.sha }}
          format: sarif
          output: trivy-results.sarif
          severity: HIGH,CRITICAL
          ignore-unfixed: true
          exit-code: 1
      - name: Upload to GitHub Security
        if: always()
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: trivy-results.sarif

Το SARIF output εμφανίζει τα ευρήματα κατευθείαν στο tab «Security» του repository και δημιουργεί inline annotations στα pull requests. Για compliance scans, προσθέστε ένα δεύτερο job που τρέχει OpenSCAP σε ένα registry.access.redhat.com/ubi9 container. Honestly, αν δεν έχετε ακόμα κάτι ανάλογο, αυτό το workflow αξίζει τα δέκα λεπτά setup.

Ιεράρχηση CVE με EPSS και KEV

Το πιο συχνό λάθος είναι η αντιμετώπιση κάθε CRITICAL ως «πρέπει να διορθωθεί αύριο». Στατιστικά, λιγότερο από το 5% των CVEs αξιοποιείται ποτέ in the wild. Η σωστή ιεράρχηση το 2026 βασίζεται σε τρεις δείκτες:

CVSS Base Score: η θεωρητική σοβαρότητα (0-10). Καλό για αρχικό φιλτράρισμα, αλλά υπερεκτιμά τον πραγματικό κίνδυνο.
EPSS (Exploit Prediction Scoring System): μοντέλο ML του FIRST.org που εκτιμά την πιθανότητα εκμετάλλευσης τις επόμενες 30 ημέρες. Score πάνω από 0.7 = επείγον.
CISA KEV Catalog: λίστα CVEs που αποδεδειγμένα εκμεταλλεύονται από επιτιθέμενους. Αν ένα CVE είναι στο KEV, πρέπει να διορθωθεί άμεσα, ανεξαρτήτως CVSS.

Το παρακάτω script συνδυάζει τα ευρήματα του Trivy με EPSS scores από το επίσημο API:

#!/usr/bin/env bash
# trivy-epss-priority.sh: εμφανίζει μόνο CVEs με EPSS > 0.5
set -euo pipefail

trivy image --format json --severity HIGH,CRITICAL "$1" \
  | jq -r '.Results[].Vulnerabilities[]?.VulnerabilityID' \
  | sort -u \
  | while read -r cve; do
      epss=$(curl -s "https://api.first.org/data/v1/epss?cve=$cve" \
        | jq -r '.data[0].epss // "0"')
      if (( $(echo "$epss > 0.5" | bc -l) )); then
        printf "%-18s EPSS=%s\n" "$cve" "$epss"
      fi
    done

Με αυτή την προσέγγιση, μια ομάδα 3 ατόμων μπορεί να διαχειριστεί χιλιάδες ευρήματα χωρίς να καεί. Σε δικό μου engagement πέρυσι, ένα fleet 800 containers έδειχνε 12.000 CVEs με Trivy· μετά το φιλτράρισμα με EPSS > 0.5 και KEV, η πραγματική λίστα προς διόρθωση κατέληξε στα 47. Δείτε την επίσημη μεθοδολογία EPSS του FIRST.org για περισσότερες λεπτομέρειες.

Συχνές ερωτήσεις

Ποιο είναι το καλύτερο εργαλείο σάρωσης ευπαθειών για Linux το 2026;

Δεν υπάρχει ένα «καλύτερο». Η σωστή απάντηση είναι συνδυασμός. Για containers και IaC χρησιμοποιήστε Trivy, για SBOM-driven supply chain το Grype, για compliance audits το OpenSCAP, και για host hardening checks το Lynis. Και τα τέσσερα είναι δωρεάν και ανοιχτού κώδικα.

Ποια η διαφορά μεταξύ Trivy και Grype;

Το Trivy σαρώνει απευθείας containers, filesystem και Git repos. Το Grype βασίζεται σε προ-παραγμένα SBOMs από το Syft. Το Grype ταιριάζει καλύτερα σε ώριμα supply-chain pipelines με Sigstore signing, ενώ το Trivy είναι πιο ολοκληρωμένο out-of-the-box.

Τι είναι το SBOM και γιατί το χρειάζομαι;

Το SBOM (Software Bill of Materials) είναι ένας μηχαναγνώσιμος κατάλογος όλων των components ενός λογισμικού. Από τις 11 Δεκεμβρίου 2027, το EU Cyber Resilience Act απαιτεί SBOM σε CycloneDX ή SPDX format για κάθε εμπορικό λογισμικό. Επίσης επιτρέπει instant re-scanning όταν εμφανίζονται νέα CVEs, χωρίς νέο rebuild.

Πρέπει να αποτυγχάνει το build μου σε κάθε εύρημα HIGH;

Όχι. Αποτυγχάνετε το build μόνο όταν το CVE είναι HIGH/CRITICAL και έχει διαθέσιμο fix και (ιδανικά) EPSS πάνω από 0.3 ή υπάρχει στο CISA KEV. Διαφορετικά θα μπλοκάρετε deployments για θεωρητικούς κινδύνους που δεν εκμεταλλεύεται κανείς.

Πόσο συχνά πρέπει να τρέχω vulnerability scans;

Στο CI σε κάθε pull request, στο production fleet ημερησίως, και σε προϋπάρχοντα images εβδομαδιαία ως nightly job. Νέα CVEs δημοσιεύονται καθημερινά, οπότε μια εικόνα «καθαρή» χθες μπορεί να είναι ευάλωτη σήμερα, χωρίς καμία αλλαγή κώδικα.