0800 71 20000
Kontakt
...
Security & Hardening

Linux Patch-Management, das die NIS2-Anforderungen wirklich abdeckt

§ 30 BSIG verlangt ein dokumentiertes Schwachstellen- und Patchmanagement. Im Audit zählt nicht, dass du patchst, sondern dass du es nachweisen kannst. Ohne Inventar, Zeitvorgaben und Protokollierung wird jede noch so saubere Praxis wertlos.

5 Kapitel mit allen Befehlen
Passende Kurse ansehen Persönlich beraten lassen
Zwei Security-Fachleute prüfen ein Dashboard im Betriebsraum
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team
Worum es geht

Warum unattended-upgrades allein den Nachweis nicht trägt

Auf den meisten Linux-Flotten existiert Patching längst, nur eben verteilt: ein Cronjob mit dnf -y update hier, unattended-upgrades dort, dazu eine Handvoll Systeme, die niemand anfassen darf, weil eine Applikation daran hängt. Solange nichts passiert, funktioniert das. Sobald das BSI oder ein Kunde eine Nachweisführung verlangt, fehlt genau das, was NIS2 fordert: eine belastbare Aussage darüber, welche Systeme es überhaupt gibt, welche Schwachstellen darauf offen sind, nach welchen Kriterien du sie bewertet hast und wann sie geschlossen wurden.

Die Umsetzung scheitert selten an fehlenden Werkzeugen und meistens an fehlender Struktur. Typisch sind ein Inventar, das aus einer Excel-Liste und dem alten Nagios-Host-Katalog zusammengeschraubt wird, eine CVE-Bewertung, die pauschal alles ab CVSS 7.0 als kritisch behandelt und dadurch handlungsunfähig macht, sowie Wartungsfenster, die für Kernel-Updates nie freigegeben werden. Das Ergebnis sind Server mit Uptimes jenseits von 400 Tagen und einer Kernel-Version, die mit dem installierten Paketstand nichts mehr zu tun hat.

Dazu kommt ein Dokumentationsproblem. Ein Ansible-Playbook, das brav durchläuft, erzeugt für sich genommen keinen Audit-Nachweis. Gefragt sind nachvollziehbare Artefakte: wer hat wann welchen Patchstand freigegeben, welche Systeme wurden bewusst ausgenommen, welche kompensierenden Maßnahmen greifen dort und wie lange bleibt eine Ausnahme bestehen.

Miniatur-Szene: Serverschrank in einer Schutzhülle, Vorhängeschlösser und ein Schild davor
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Patch-Zyklus nach NIS2-Logik

  1. 01 Inventar erfassen
  2. 02 Schwachstellen scannen
  3. 03 Nach CVSS, KEV und Exposition priorisieren
  4. 04 Gestuft ausrollen oder livepatchen
  5. 05 Wirksamkeit prüfen
  6. 06 Nachweis dokumentieren
Was du mitnimmst

Der Weg zu einem prüffesten Patch-Prozess

NIS2 schreibt dir keine Produkte vor, sondern einen funktionierenden und dokumentierten Prozess. Die folgenden Bausteine bilden ihn auf einer typischen Mischflotte aus RHEL, SLES, Debian und Ubuntu ab, ohne dass du deine Toolchain komplett austauschen musst.

Vollständiges Inventar als Grundlage

Ohne verlässliche Asset-Liste ist jede Aussage zum Patchstand wertlos. Ein zentrales System wie der SUSE Multi-Linux Manager oder ein Ansible-Inventory mit dynamischer Quelle liefert dir pro Host Distribution, Kernel, Paketstand, Rolle und Verantwortlichen. Wichtig ist, dass Neuzugänge automatisch auftauchen und nicht per Zuruf gepflegt werden.

Schwachstellen erfassen statt nur Updates zählen

Die Distributionen liefern maschinenlesbare Sicherheitsdaten, etwa OVAL-Daten von Red Hat und SUSE oder den Debian Security Tracker. Damit bekommst du je Host eine CVE-Liste statt einer anonymen Anzahl offener Pakete. Scanner wie Trivy ergänzen das um Container-Images und erzeugen gleich eine SBOM, die du für Lieferketten-Fragen ohnehin brauchst.

Priorisieren nach Ausnutzbarkeit, nicht nur nach Score

CVSS beschreibt die technische Schwere, nicht dein Risiko. Kombiniere den Basis-Score mit der KEV-Liste der CISA und dem EPSS-Wert sowie mit deiner eigenen Exposition, also ob der Dienst überhaupt erreichbar ist und ob der verwundbare Codepfad läuft. Daraus leitest du Fristen ab, zum Beispiel 72 Stunden für aktiv ausgenutzte Lücken an exponierten Systemen.

Rollout in Stufen und automatisiert

Ein Patchlauf gehört in Ringe: Testsysteme, dann unkritische Produktion, dann die sensiblen Cluster. Ansible-Rollen mit serial und Health-Checks vor und nach dem Reboot, dnf needs-restarting beziehungsweise zypper ps zur Erkennung laufender alter Prozesse, dazu ein sauberes Draining bei Kubernetes-Nodes oder Pacemaker-Ressourcen. So bleibt der Rollout wiederholbar und ohne Handarbeit an der Konsole.

Livepatching für die Systeme, die nicht rebooten dürfen

Wo ein Wartungsfenster praktisch nicht zu bekommen ist, schließt Kernel-Livepatching mit kpatch oder SUSE Live Patching die Lücke zwischen Verfügbarkeitsanspruch und Sicherheitsanforderung. Das ersetzt den Reboot nicht dauerhaft, verschafft dir aber die Zeit, ihn geplant statt panisch durchzuführen. Userspace-Bibliotheken bleiben davon unberührt, deshalb gehört ein Neustart der betroffenen Dienste weiterhin dazu.

Nachweise erzeugen, die ein Auditor akzeptiert

Reporting ist kein Nebenprodukt, sondern Teil der Pflicht. Sinnvoll sind ein regelmäßiger Compliance-Report je Systemgruppe, ein dokumentierter Freigabe- und Ausnahmeprozess mit Ablaufdatum sowie Kennzahlen zur Zeit zwischen Veröffentlichung einer Schwachstelle und ihrer Behebung. Wer das aus dem Managementsystem heraus generiert, muss vor dem Audit nichts rekonstruieren.

Tutorial

Vom Ist-Stand zum Nachweis, Befehl für Befehl

Hier geht es um die Handgriffe, mit denen aus gepflegten Servern ein nachweisbarer Prozess wird. Zuerst erhebst du den Patchstand je Host maschinenlesbar, dann bewertest du die offenen Befunde, danach rollst du in Ringen aus und ermittelst zuverlässig, was neu gestartet werden muss. Am Ende steht das Artefakt, das im Audit tatsächlich gelesen wird.

01

Patchstand je Host maschinenlesbar erheben

Eine Liste offener Pakete ist noch kein Befund. Was du brauchst, ist die Zuordnung von CVE zu Host, und die liefern alle großen Distributionen aus ihren eigenen Metadaten.

Sicherheitsrelevante Updates je Distribution
# RHEL, Rocky, Alma
dnf updateinfo summary
dnf updateinfo list --security --available
dnf -q repoquery --upgrades --queryformat '%{name} %{evr}\n'

# SLES und openSUSE
zypper list-patches --category security
zypper list-patches --cve

# Debian und Ubuntu
apt list --upgradable 2>/dev/null
sudo unattended-upgrade --dry-run --debug
debsecan --format detail          # CVE je installiertem Paket
pro security-status --format=json # Ubuntu: was ist überhaupt abgedeckt

debsecan fragt den Debian Security Tracker ab und liefert die CVE-Sicht, die apt nicht kennt. Unter Ubuntu ergänzt pro security-status, welche Pakete überhaupt unter Support stehen.

OVAL-Prüfung mit OpenSCAP
sudo dnf install -y openscap-scanner scap-security-guide bzip2

# OVAL-Daten der Distribution laden und auswerten
curl -sSLo rhel.oval.xml.bz2 \
  https://security.access.redhat.com/data/oval/v2/RHEL9/rhel-9.oval.xml.bz2
bunzip2 -f rhel.oval.xml.bz2
oscap oval eval --results oval-ergebnis.xml --report oval-bericht.html rhel.oval.xml

# Ganze Flotte über SSH, ohne Installation auf dem Ziel
oscap-ssh root@server01 22 oval eval --report s01.html rhel.oval.xml

Der Bericht nennt je Definition die CVE, den Paketstand und das Ergebnis. Er ist ohne Nachbearbeitung als Anlage im Auditordner brauchbar. Debian und Ubuntu veröffentlichen ihre Sicherheitsdaten ebenfalls maschinenlesbar, dort ist debsecan der kürzere Weg.

02

Priorisieren, damit die Liste bearbeitbar wird

Ohne Filter meldet jede Flotte mehr kritische Befunde, als ein Team abarbeiten kann. Die Reihenfolge entsteht aus vier Fragen, die du je Befund beantwortest und dokumentierst.

Vier Fragen je Schwachstelle

  • Steht die CVE in der KEV-Liste der CISA oder hat sie einen hohen EPSS-Wert?Beides beschreibt, ob eine Lücke tatsächlich ausgenutzt wird. Ein CVSS von 9,8 ohne verfügbaren Exploit ist weniger dringend als eine 7,5, für die seit einer Woche Code kursiert.
  • Ist der verwundbare Dienst überhaupt erreichbar?Ein Paket kann installiert sein, ohne dass der Dienst läuft oder aus dem Netz erreichbar ist. ss -tulpn und ein Blick in deine nftables-Regeln beantworten das in zwei Minuten und verschieben viele Befunde nach hinten.
  • Läuft der verwundbare Codepfad in deiner Konfiguration?Viele Errata betreffen Module, die du gar nicht geladen hast. Das ist eine zulässige Begründung für eine spätere Frist, aber nur, wenn du sie aufschreibst statt sie zu behaupten.
  • Ist je Risikoklasse eine verbindliche Frist festgelegt und veröffentlicht?Ohne feste Frist ist jede Priorisierung eine Meinung. Prüfer fragen zuerst nach der Regel und danach nach Stichproben, ob du sie eingehalten hast.

Für den unabhängigen Blick von außen bietet sich die Greenbone Community Edition an, der Nachfolger von OpenVAS aus Osnabrück. Ein authentifizierter Scan liefert dir die Sicht des Angreifers zusammen mit dem lokalen Paketstand und deckt vor allem die Systeme auf, die in keinem Inventar stehen. Plane ihn als wiederkehrenden Auftrag ein und exportiere die Berichte automatisch, dann hast du neben den Daten aus deiner eigenen Automatisierung einen zweiten Beleg aus einer anderen Quelle.

03

Ausrollen in Ringen mit Ansible

Ein Patchlauf, der alle Systeme gleichzeitig trifft, ist ein Ausfall mit Ankündigung. Mit gestaffelten Ringen und einer Abbruchschwelle bleibt der Schaden auf einen Ring begrenzt.

patch.yml, Auszug
- hosts: ring2
  serial: "20%"
  max_fail_percentage: 10
  become: true
  tasks:
    - name: Sicherheitsupdates einspielen (RHEL-Familie)
      ansible.builtin.dnf:
        name: "*"
        state: latest
        security: true
      when: ansible_os_family == "RedHat"

    - name: Sicherheitsupdates einspielen (Debian-Familie)
      ansible.builtin.apt:
        upgrade: safe
        update_cache: true
      when: ansible_os_family == "Debian"

    - name: Reboot-Bedarf ermitteln
      ansible.builtin.command: needs-restarting -r
      register: reboot_noetig
      changed_when: false
      failed_when: reboot_noetig.rc not in [0, 1]
      when: ansible_os_family == "RedHat"

    - name: Neustart nur wenn nötig
      ansible.builtin.reboot:
        reboot_timeout: 900
      when: reboot_noetig.rc | default(0) == 1

    - name: Dienst nach dem Neustart prüfen
      ansible.builtin.uri:
        url: "https://{{ inventory_hostname }}/healthz"
        status_code: 200
      register: ergebnis
      until: ergebnis is succeeded
      retries: 10
      delay: 15

needs-restarting -r liefert den Rückgabewert 1, wenn ein Neustart nötig ist, deshalb die Sonderbehandlung mit failed_when. Auf Debian und Ubuntu prüfst du stattdessen auf die Datei /var/run/reboot-required. max_fail_percentage stoppt den Lauf, sobald zu viele Hosts eines Rings scheitern, statt den Fehler über die ganze Flotte zu tragen.

Trockenlauf, begrenzter Start, Protokoll
ansible-playbook patch.yml --limit ring1 --check --diff
ansible-playbook patch.yml --limit ring1

# Ergebnis je Host als JSON ablegen, das ist später dein Nachweis
ansible-playbook patch.yml --limit ring2 \
  --tree /var/log/patch/$(date +%F)

--tree schreibt je Host eine JSON-Datei mit dem Ergebnis jeder Aufgabe. Zusammen mit dem Zeitstempel und dem Git-Commit des Playbooks hast du damit einen reproduzierbaren Beleg dafür, was wann auf welchem System passiert ist, und musst dich nicht auf Erinnerungen stützen.

04

Reboot-Bedarf und Dienstneustarts zuverlässig ermitteln

Das Paket ist eingespielt, die Lücke aber erst geschlossen, wenn der Prozess die neue Bibliothek auch geladen hat. Genau hier entsteht der Unterschied zwischen einem grünen Report und einem wirklich gepatchten System.

Gleiche Frage, drei Distributionsfamilien

FrageRHEL, Rocky, AlmaSLESDebian, Ubuntu
Ist ein Neustart nötig?needs-restarting -rzypper needs-rebooting/var/run/reboot-required
Welche Dienste laufen mit alten Bibliotheken?needs-restarting -szypper ps -sneedrestart -b
Was wurde eingespielt?dnf history list/var/log/zypp/history/var/log/apt/history.log
Rücknahme des letzten Laufsdnf history undo IDsnapper rollback bei btrfskein direkter Weg, Restore nötig
Nach dem Patchlauf prüfen
# RHEL-Familie
needs-restarting -r || echo "Neustart erforderlich"
needs-restarting -s
dnf history info last

# Debian und Ubuntu
sudo needrestart -b               # maschinenlesbar für die Automatisierung
test -f /var/run/reboot-required && cat /var/run/reboot-required.pkgs
grep -E '^(Start-Date|Commandline)' /var/log/apt/history.log | tail -20

# Läuft der Kernel, den du installiert hast?
uname -r
rpm -q --last kernel | head -3    # bzw. dpkg -l 'linux-image-*'

Der Vergleich zwischen uname -r und dem zuletzt installierten Kernelpaket ist die ehrlichste Kennzahl deiner Flotte. Weichen beide auf vielen Systemen ab, hast du kein Patch-Problem, sondern ein Reboot-Problem. Das ist ein Thema für die Leitung und nicht für die Administration, denn es geht um Wartungsfenster.

05

Das Artefakt erzeugen, das im Audit zählt

Prüfer lesen keine Playbooks. Sie fragen nach dem Geltungsbereich, nach der Regel, nach Belegen für einen Zeitraum und nach dem Umgang mit Ausnahmen. Alle vier Dinge lassen sich automatisch erzeugen.

ausnahmen.yml, versioniert im selben Repository wie das Playbook
- host: sap-db01.intern
  cve: CVE-JAHR-NUMMER            # Kennung aus dem Befund übernehmen
  paket: openssl
  grund: "Herstellerfreigabe der Fachanwendung steht aus, Ticket CHG-4711"
  kompensation:
    - "Dienst nur aus VLAN 42 erreichbar, nftables-Regel fw-042"
    - "zusätzliche Protokollierung auf dem Loadbalancer aktiv"
  entscheider: "Leitung IT-Betrieb"
  entschieden_am: 2026-03-02
  gueltig_bis: 2026-06-30         # danach fällt der Host wieder in den Report

Den Wert dieser Datei macht das Feld gueltig_bis aus. Ohne Ablaufdatum wird aus einer Ausnahme ein Dauerzustand, den niemand mehr prüfen lässt. Weil die Datei im Git liegt, liefert die Historie gleich mit, wer wann was entschieden hat, und du musst diesen Nachweis nicht getrennt führen.

Vier Belege, die aus dem Betrieb heraus entstehen sollten

  • Bestandsliste mit Distribution, Kernel, Rolle und verantwortlicher Person, automatisch aus dem Inventar erzeugt und nicht von Hand gepflegt
  • Offene Befunde je Systemgruppe, mit dem Datum der Veröffentlichung und dem aktuellen Stand der Bearbeitung
  • Zeit zwischen Veröffentlichung eines Sicherheitsupdates und seiner Installation, als Mittelwert und als schlechtester Einzelfall je Ring
  • Liste der aktiven Ausnahmen mit Ablaufdatum und den kompensierenden Maßnahmen

Diese vier Artefakte decken ab, was § 30 BSIG im Bereich Schwachstellenbehandlung verlangt, und sie funktionieren unabhängig davon, ob du mit einem zentralen Managementsystem, mit Ansible oder mit einer Mischung aus beidem arbeitest. Entscheidend ist, dass sie im laufenden Betrieb entstehen. Alles, was erst vor dem Prüftermin zusammengesucht wird, kostet mehr Zeit als der Prozess selbst.

Passende Kurse

Kurse zu Patchmanagement nach NIS2 bei cmt

Diese Kurse vertiefen genau das, an echten Systemen statt nur an Folien. Als Präsenz oder Live-Online, auf Wunsch auch Inhouse für dein Team.

SUSE Multi-Linux Manager 5 Operations - SMGR201v5 3 Tage Präsenz nächster Termin 30.11.2026 Zum Kurs AU294 Red Hat Enterprise Linux Automation with Ansible 4 Tage Präsenz oder Live-Online nächster Termin 28.09.2026 Zum Kurs Ansible Kompaktkurs 5 Tage Präsenz oder Live-Online nächster Termin 19.10.2026 Garantietermin Zum Kurs Linux Security Intensivkurs 3 Tage Präsenz nächster Termin 16.11.2026 Garantietermin Zum Kurs
Unverbindlich beraten lassen Alle IT-Security-Kurse ansehen
Gut zu wissen

Häufige Fragen zu Patchmanagement nach NIS2

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt
Was genau verlangt NIS2 beim Patch-Management?
Die NIS2-Richtlinie und ihre deutsche Umsetzung im BSIG nennen keine konkreten Werkzeuge oder Fristen, sondern fordern angemessene technische und organisatorische Maßnahmen zur Behandlung von Schwachstellen. In der Praxis heißt das, dass du einen definierten Prozess brauchst, ihn dokumentierst, seine Wirksamkeit überprüfst und die Ergebnisse gegenüber der Geschäftsleitung und im Prüfungsfall gegenüber dem BSI darlegen kannst.
Reicht automatisches Patchen über unattended-upgrades oder dnf-automatic aus?
Als technische Maßnahme sind beide sinnvoll, als Nachweis reichen sie nicht. Es fehlt die Verbindung zu einem Inventar, die Risikobewertung einzelner Schwachstellen, ein geregelter Umgang mit Ausnahmen und ein Reporting über den Ist-Stand der Flotte. Sinnvoll ist die Kombination aus automatischem Einspielen unkritischer Sicherheitsupdates und einem gesteuerten Prozess für alles, was einen Reboot oder eine Freigabe braucht.
Wie patche ich Linux-Server ohne Reboot?
Kernel-Livepatching spielt Korrekturen in den laufenden Kernel ein, ohne dass das System neu startet. Unter SLES steht dafür SUSE Live Patching bereit, unter RHEL kpatch, unter Ubuntu Livepatch. Abgedeckt sind ausgewählte Sicherheitslücken im Kernel, nicht jede Änderung. Für Updates an glibc, OpenSSL oder anderen Bibliotheken musst du weiterhin die betroffenen Dienste neu starten, was du mit needs-restarting oder zypper ps zuverlässig ermittelst.
Nach welchen Kriterien priorisiere ich CVEs sinnvoll?
Ein tragfähiges Modell kombiniert drei Dimensionen: die technische Schwere über CVSS, die Wahrscheinlichkeit einer Ausnutzung über EPSS und die KEV-Liste der CISA, sowie die eigene Exposition, also Erreichbarkeit des Dienstes, Datenklassifizierung und vorhandene Schutzschichten wie nftables oder SELinux. Wer nur nach Score sortiert, arbeitet zwangsläufig an der falschen Stelle, weil die Menge der Meldungen mit hohem Score jede realistische Kapazität übersteigt.
Wie dokumentiere ich Ausnahmen für Systeme, die nicht gepatcht werden können?
Jede Ausnahme braucht eine benannte technische Begründung, eine verantwortliche Person, kompensierende Maßnahmen wie Netzsegmentierung oder verschärftes Monitoring und ein festes Ablaufdatum, zu dem erneut entschieden wird. Genau diese Struktur erwarten Prüfer, denn ein bewusst getragenes und begründetes Risiko ist zulässig, ein unbemerkt offenes nicht.

Quellen

Zuletzt geprüft am 26. Juli 2026.

Weiterlesen

Verwandte Linux-Themen

Alle Linux-Themen im Überblick

Passt dazu: Weiterbildung für den öffentlichen Dienst

Security & Hardening SELinux verstehen statt abschalten: Kontexte, Booleans und Troubleshooting Ansehen Security & Hardening SSH absichern: So machst du den Fernzugriff auf deine Linux-Server dicht Ansehen Security & Hardening Cyber Resilience Act und Open Source: Was auf dich zukommt, wenn dein Produkt Software enthält Ansehen Security & Hardening nftables, iptables oder firewalld: Welche Linux-Firewall du heute nutzen solltest Ansehen
Das sagen Teilnehmer

Echte Stimmen aus unseren IT-Kursen

“
Qualitativ sehr guter Kurs. Ruhiger und wertschätzender Umgang. Keine Informationsüberlastung.
Rückmeldung aus dem Kurs „Ansible Kompaktkurs“
“
Der Trainer konnte die Inhalte sehr gut vermitteln. Ich habe dabei viel gelernt.
Rückmeldung aus dem Kurs „Monitoring mit Prometheus und Grafana - Grundkurs“
Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.

0800 71 20000 E-Mail
Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.

0800 71 20000 E-Mail
Nächster Schritt

Setz den Prozess mit unseren Trainern auf

Wenn du die Automatisierung aufbauen willst, sind der Ansible Kompaktkurs und AU294 Red Hat Enterprise Linux Automation with Ansible der direkte Weg. Für zentrale Verwaltung und Reporting auf SUSE-Flotten passt SUSE Multi-Linux Manager 5 Operations, für den Betrieb ohne Wartungsfenster SUSE Linux Enterprise Live Patching. Und wenn du das Härtungs- und Sicherheitsthema breiter angehen willst, schau dir den Linux Security Intensivkurs an. Alle Kurse gibt es als Präsenz- oder Live-Online-Termin, und wenn du unsicher bist, welche Kombination zu deiner Flotte passt, sprich uns einfach an.

Beratung anfragen 0800 71 20000