Betroffenheit prüfen: bin ich das überhaupt?

Die häufigste Reaktion auf eine Sicherheitsmeldung ist eine halbe Stunde Unsicherheit: Setzen wir das ein? In welcher Version? Läuft das irgendwo noch? Diese halbe Stunde lässt sich auf zwei Minuten drücken, mit einer Bestandsliste, die man nicht pflegen muss, weil die Maschine sie selbst erzeugt.

Ebene 1: Distributionspakete#

# Ist das Paket installiert, und in welcher Version?
dpkg -l | grep -i openssl
apt-cache policy openssl

# Gibt es ein Sicherheitsupdate dafür?
apt-get -s -o Debug::NoLocking=true upgrade | grep -i '^Inst.*security'

Wichtig zu wissen: Debian und Ubuntu backporten Sicherheitskorrekturen in die vorhandene Version, statt auf die neueste Programmversion zu springen. Die Versionsnummer sieht dann alt aus, obwohl die Lücke geschlossen ist. Der verlässliche Weg ist das Änderungsprotokoll:

apt changelog openssl 2>/dev/null | head -30 | grep -i 'CVE-'

Steht die CVE-Nummer dort, ist sie in dieser Paketversion behandelt. Das ist die Antwort, die zählt, nicht der Vergleich mit der Versionsnummer aus dem Herstellerbulletin.

Ebene 2: Container-Images#

Container umgehen die Paketverwaltung des Hosts vollständig. Ein aktuelles Debian auf dem Host sagt nichts über das Alpine-Image von vor acht Monaten darin.

# Welche Images laufen, in welcher Version?
docker ps --format 'table {{.Names}}\t{{.Image}}'

# Welche Images liegen insgesamt herum?
docker images --format '{{.Repository}}:{{.Tag}}\t{{.CreatedSince}}'

# Innerhalb eines Images nachsehen
docker run --rm --entrypoint sh postgres:17.4-alpine -c 'apk list --installed 2>/dev/null | grep -i openssl'

Für eine systematische Prüfung ein Scanner, die Ausgabe ist beim ersten Mal ernüchternd und das ist normal:

docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
  aquasec/trivy:latest image --severity HIGH,CRITICAL --ignore-unfixed postgres:17.4-alpine

--ignore-unfixed blendet aus, wofür es ohnehin keinen Patch gibt. Das kürzt die Liste auf das, wo Handeln möglich ist.

Ebene 3: Sprachabhängigkeiten#

Die Ebene, die am häufigsten vergessen wird und in der die meisten Lücken stecken.

# Node
npm audit --omit=dev

# Python
pip list --outdated
pip-audit 2>/dev/null || echo "pip install pip-audit"

# PHP
composer audit

# Rust, Go
cargo audit 2>/dev/null
govulncheck ./... 2>/dev/null

govulncheck ist dabei bemerkenswert: Es meldet nur Lücken in Code, der tatsächlich aufgerufen wird, genau die Unterscheidung, um die es bei der Betroffenheitsprüfung geht.

Die Bestandsliste, die sich selbst pflegt#

Statt eine Tabelle zu führen, die veraltet: ein Skript, das den Zustand erhebt.

#!/bin/bash
# /usr/local/bin/bestand.sh — läuft wöchentlich, Ergebnis ins Repo
set -euo pipefail
echo "== $(hostname) — $(date -I) =="
echo "-- OS"
. /etc/os-release && echo "$PRETTY_NAME (Kernel $(uname -r))"
echo "-- Dienste mit offenen Ports"
ss -tulpn | awk '/LISTEN/ {print $5, $7}' | sort -u
echo "-- Container"
command -v docker >/dev/null && docker ps --format '{{.Image}}' | sort -u
echo "-- Ausgewählte Pakete"
dpkg-query -W -f='${Package} ${Version}\n' openssl nginx postgresql-* openssh-server 2>/dev/null
echo "-- Ausstehende Sicherheitsupdates"
apt-get -s -o Debug::NoLocking=true upgrade 2>/dev/null | grep -c '^Inst.*security' || true

# /etc/systemd/system/bestand.timer
[Timer]
OnCalendar=Mon 06:00
Persistent=true
[Install]
WantedBy=timers.target

Die Ausgaben aller Maschinen an einem Ort, dann ist die Frage „läuft irgendwo noch Version X?“ ein grep statt einer Runde durch alle Hosts.

Ein Durchlauf, wie er wirklich abläuft#

Angenommen, eine Meldung betrifft eine Bibliothek, die in Webservern steckt:

# 1. Setzen wir das ein?
dpkg -l | grep -i libbeispiel || echo "nicht installiert"

# 2. Falls ja: ist die CVE in unserer Version behandelt?
apt changelog libbeispiel 2>/dev/null | grep -i 'CVE-2026-' | head

# 3. Steckt es zusätzlich in Containern?
for img in $(docker ps --format '{{.Image}}' | sort -u); do
  echo "== $img"
  docker run --rm --entrypoint sh "$img" -c 'dpkg -l 2>/dev/null | grep -i libbeispiel || apk list --installed 2>/dev/null | grep -i libbeispiel' || true
done

# 4. Ist der betroffene Dienst von außen erreichbar?
ss -tulpn | grep LISTEN

Vier Befehle, und die Frage ist beantwortet, mit einem Beleg statt einer Vermutung.

Was danach kommt#

Ist die Betroffenheit bestätigt, entscheidet die Einordnung über die Dringlichkeit: CVSS richtig lesen. Ist sie dringend, aber das nächste Wartungsfenster weit weg, geht es um den Ablauf für einen Patch außer der Reihe: Wartungsfenster und der Weg zurück.

Und wenn die Prüfung ergibt, dass die Software gar nicht mehr gepflegt wird, kein Patch, kein Bulletin, letzte Veröffentlichung vor drei Jahren, dann ist das kein CVE-Problem mehr, sondern eine Ablösungsentscheidung.