Aktualisierungen und Schwachstellenverwaltung

2017 wurde Equifax durch eine ungepatchte Apache-Struts-Schwachstelle kompromittiert. Der Patch war seit zwei Monaten verfügbar. Sie hatten ihn einfach nicht eingespielt. Einer der größten Datenverstöße der Geschichte – und durch ein zeitnahes Update vollständig vermeidbar.

Sie sind nicht Equifax, aber die Lektion gilt trotzdem. Die meisten Einbrüche kommen nicht durch raffinierte Zero-Day-Exploits. Sie passieren, weil jemand Software mit einer bekannten, veröffentlichten Schwachstelle nicht aktualisiert hat. Angreifer scannen ständig nach veralteter Software. Wenn ein kritischer CVE veröffentlicht wird, beginnen Exploit-Versuche innerhalb von Stunden.

Dieses Kapitel richtet ein System ein, mit dem Sie wissen, wenn Ihre Software Schwachstellen hat – und sie beheben, bevor Angreifer sie finden.

Warum Aktualisierungen vernachlässigt werden

Alle wissen, dass Aktualisierungen wichtig sind. Warum werden sie trotzdem übersprungen?

„Es könnte etwas kaputt machen." Das ist der Hauptgrund. Sie aktualisieren eine Bibliothek und plötzlich schlagen die Hälfte Ihrer Tests fehl. Sie patchen das Betriebssystem und ein kritischer Dienst hört auf zu funktionieren. Nach ein paar schlechten Erfahrungen werden Menschen vorsichtig. Aktualisierungen häufen sich an.

Niemand ist zuständig. Entwickler gehen davon aus, dass Ops die Aktualisierungen übernimmt. Ops geht davon aus, dass Entwickler ihre Abhängigkeiten pflegen. Niemand prüft die Server, die „einfach laufen".

Keine Transparenz. Sie wissen nicht, welche Versionen Sie betreiben. Sie wissen nicht, welche CVEs Sie betreffen. Sie erfahren es, wenn etwas kaputt geht oder ein Sicherheitsforscher Sie kontaktiert.

Es kostet Zeit. Aktualisierungen einspielen, testen, deployen – das ist keine glamouröse Arbeit. Wenn es Produktarbeit zu liefern gibt, werden Aktualisierungen auf „nächsten Sprint" verschoben, auf unbestimmte Zeit.

Der Security Champion patcht nicht persönlich alles. Aber er schafft Transparenz und Verantwortlichkeit, damit Aktualisierungen tatsächlich passieren.

Die zwei Arten von Aktualisierungen

Denken Sie in zwei Kategorien:

Betriebssystem und Infrastruktur

Das sind Ihre Server, Container, Cloud-Dienste. Linux-Kernel-Aktualisierungen, Paket-Aktualisierungen, Docker-Base-Image-Aktualisierungen.

Wer ist typischerweise zuständig: DevOps, Systemadministratoren oder wer auch immer die Infrastruktur verwaltet.

Aktualisierungsstrategie: Automatisch wo möglich, geplante Wartungsfenster für manuelle Aktualisierungen.

Risiko bei Vernachlässigung: Remote Code Execution, Privilege Escalation, vollständige Systemkompromittierung.

Anwendungsabhängigkeiten

Das sind Bibliotheken und Pakete, von denen Ihr Code abhängt. npm-Pakete, Python-Bibliotheken, Ruby-Gems, Go-Module.

Wer ist typischerweise zuständig: Entwickler, aber oft niemand konkret.

Aktualisierungsstrategie: Automatisierte PRs von Dependabot/Renovate, regelmäßige Review-Zyklen.

Risiko bei Vernachlässigung: Supply-Chain-Angriffe, bekannte Schwachstellen in verwendeten Bibliotheken.

Beide sind wichtig. Ein vollständig gepatchtes Betriebssystem hilft nicht, wenn Ihre Anwendung eine verwundbare Version von Log4j enthält.

Automatische Aktualisierungen einrichten

Automatische Aktualisierungen klingen beängstigend, bis Sie erkennen, dass die Alternative gar keine Aktualisierungen sind.

Linux-Server

Für Ubuntu/Debian-Server aktivieren Sie unattended-upgrades:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

Damit werden Sicherheits-Aktualisierungen automatisch installiert. Sie können konfigurieren, was automatisch aktualisiert wird, in /etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
};

// Automatically reboot if required
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";

Für RHEL/CentOS/Rocky:

sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic-install.timer

Soll automatisch neugestartet werden? Für nicht-kritische Server: ja. Für Produktion möchten Sie Neustarts wahrscheinlich in Wartungsfenstern planen. Aber Kernel-Aktualisierungen wirken erst nach einem Neustart – wenn Sie nie neustarten, laufen Sie mit verwundbaren Kerneln.

Docker-Container

Ihre Container erben Schwachstellen von ihren Base-Images. Wenn Sie python:3.9 von vor zwei Jahren nutzen, laufen Sie mit zwei Jahren ungepatchter Schwachstellen.

Strategie 1: Regelmäßige Neubauten

Bauen und deployen Sie Container wöchentlich neu, auch wenn sich Ihr Code nicht geändert hat. Damit werden aktuelle Base-Images mit den neuesten Patches gezogen.

Zu Ihrer CI-Pipeline hinzufügen:

# GitHub Actions example
on:
  schedule:
    - cron: '0 3 * * 0'  # Every Sunday at 3 AM
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build with fresh base image
        run: docker build --pull -t myapp:latest .

Das --pull-Flag zwingt Docker, auf aktualisierte Base-Images zu prüfen.

Strategie 2: Minimale Base-Images verwenden

Weniger Pakete = weniger Schwachstellen. Erwägen Sie:

• alpine statt ubuntu für einfache Anwendungen
• distroless-Images für Produktion (keine Shell, minimale Angriffsfläche)
• Sprachspezifische Slim-Images (python:3.11-slim, node:20-slim)

Cloud-Dienste

AWS, GCP und Azure übernehmen Infrastruktur-Aktualisierungen für verwaltete Dienste. Aber Sie sind noch immer verantwortlich für:

• EC2/Compute Engine/VM-Instanzen – das sind Ihre Server, aktualisieren Sie sie
• Container-Images in ECS/EKS/GKE – regelmäßig neu bauen
• Lambda/Cloud-Functions-Runtime-Versionen – upgraden, wenn neue Runtimes erscheinen
• Verwaltete Datenbanken – einige Aktualisierungen erfordern geplante Wartungsfenster

Prüfen Sie Ihre Cloud-Konsole auf veraltete Ressourcen. AWS hat Trusted Advisor (kostenlose Stufe eingeschränkt), GCP hat Security Command Center.

Abhängigkeits-Aktualisierungen mit Dependabot (oder Renovate)

GitHubs Dependabot ist kostenlos und übernimmt den mühsamsten Teil der Abhängigkeits-Aktualisierungen: zu wissen, dass sie existieren. Wenn Sie GitLab, Bitbucket oder mehr Konfigurationsoptionen benötigen, ist Renovate eine ausgezeichnete Alternative mit ähnlicher Funktionalität.

Dependabot einrichten

Erstellen Sie .github/dependabot.yml in Ihrem Repository:

version: 2
updates:
  # JavaScript/npm
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 10

  # Python
  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "weekly"

  # Docker
  - package-ecosystem: "docker"
    directory: "/"
    schedule:
      interval: "weekly"

  # GitHub Actions
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

Dependabot erstellt nun Pull-Requests, wenn Abhängigkeiten Aktualisierungen haben.

Dependabot nützlich machen

Das Problem mit Dependabot ist PR-Ermüdung. Es öffnet 15 PRs pro Woche, und die Leute fangen an, sie zu ignorieren.

Nicht-Sicherheits-Aktualisierungen gruppieren:

- package-ecosystem: "npm"
  directory: "/"
  schedule:
    interval: "weekly"
  groups:
    dev-dependencies:
      patterns:
        - "*"
      update-types:
        - "minor"
        - "patch"

Damit werden Minor- und Patch-Aktualisierungen in einzelne PRs gruppiert und das Rauschen reduziert.

Sicherheits-Aktualisierungen priorisieren:

Dependabot-Sicherheits-Aktualisierungen sind von Versions-Aktualisierungen getrennt. Aktivieren Sie sie in Ihren Repository-Einstellungen (Settings → Security → Dependabot alerts). Diese erstellen PRs speziell für bekannte Schwachstellen.

Auto-Merge für risikoarme Aktualisierungen einrichten:

# In your CI workflow
- name: Auto-merge Dependabot PRs
  if: github.actor == 'dependabot[bot]'
  run: gh pr merge --auto --squash "$PR_URL"
  env:
    PR_URL: ${{ github.event.pull_request.html_url }}
    GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Tun Sie das nur, wenn Sie eine gute Testabdeckung haben. Sonst deployen Sie automatisch Fehler.

Schwachstellen-Scanning jenseits von Dependabot

Dependabot prüft Ihre deklarierten Abhängigkeiten. Aber es gibt mehr zu scannen.

Snyk

Snyk bietet eine kostenlose Stufe, die folgendes umfasst:

• Abhängigkeits-Scanning (wie Dependabot, aber mit mehr Kontext)
• Container-Image-Scanning
• Infrastructure-as-Code-Scanning

Für kleine Teams reicht die kostenlose Stufe meist aus. Integrieren Sie es in Ihre CI-Pipeline:

# GitHub Actions
- name: Run Snyk
  uses: snyk/actions/node@master  # or /python, /docker, etc.
  env:
    SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

Snyk gibt Ihnen Schweregrad-Bewertungen und Ausnutzbarkeitsinformationen, die bei der Priorisierung von Behebungen helfen.

Trivy für Container

Trivy ist kostenlos und scannt Container-Images auf Betriebssystem- und Bibliotheks-Schwachstellen:

# Scan a local image
trivy image myapp:latest

# Scan in CI
trivy image --exit-code 1 --severity HIGH,CRITICAL myapp:latest

Der --exit-code 1 lässt Ihre Pipeline fehlschlagen, wenn Schwachstellen mit hohem/kritischem Schweregrad gefunden werden. Nützlich, um zu verhindern, dass verwundbare Images deployed werden.

GitHub-Sicherheitsfunktionen

GitHub bietet mehrere kostenlose Sicherheitsfunktionen:

• Dependabot-Warnungen — Benachrichtigungen, wenn Abhängigkeiten bekannte Schwachstellen haben
• Code-Scanning — SAST (statische Analyse) mit CodeQL
• Secret-Scanning — Findet versehentlich eingecheckte Zugangsdaten

Aktivieren Sie alle unter Settings → Security. Kostenlos für öffentliche Repos und inbegriffen in GitHub Advanced Security für private Repos.

Tools für die Schwachstellenverwaltung

Hier ist eine umfassende Liste von Tools, nach Kategorie und Kosten geordnet.

Abhängigkeits-Scanning

Kostenlos/Open Source:

• Dependabot — In GitHub integriert, scannt Abhängigkeiten und öffnet PRs. Null Einrichtungsaufwand für GitHub-Repos.
• Renovate — Flexibler als Dependabot, unterstützt mehr Plattformen (GitLab, Bitbucket, Azure DevOps). Self-hosted oder kostenlose gehostete Version von Mend.
• OWASP Dependency-Check — Scannt Java, .NET, Node.js, Python, Ruby. CLI-Tool, gut für CI/CD. Vollständig kostenlos.
• Grype — Schneller Schwachstellen-Scanner von Anchore. Scannt Container-Images und Dateisysteme. Open Source.
• Safety — Python-spezifischer Abhängigkeitsprüfer. Kostenlose CLI, prüft gegen die PyUp.io-Datenbank.
• npm audit / yarn audit — In npm und yarn eingebaut. Führen Sie npm audit aus, um Schwachstellen in Ihren node_modules zu sehen.

Kommerziell mit kostenlosen Stufen:

• Snyk — Kostenlose Stufe: 200 Tests/Monat, unbegrenzt für Open Source. Deckt Abhängigkeiten, Container, IaC ab.
• Socket — Fokussiert auf Supply-Chain-Angriffe (Typosquatting, bösartige Pakete). Kostenlos für Open Source.
• Mend (ehemals WhiteSource) — Kostenlos für Open-Source-Projekte über Mend Bolt. Enterprise-Funktionen für bezahlte Versionen.

Enterprise:

• Sonatype Nexus Lifecycle — Tiefe Komponenten-Intelligence, Policy-Durchsetzung. Teuer, aber umfassend.
• Veracode SCA — Teil von Veracodes Anwendungssicherheitsplattform.
• Black Duck — Von Synopsys. Vollständige Lizenz-Compliance und Sicherheitsanalyse.

Container-Sicherheit

Kostenlos/Open Source:

• Trivy — Der Standard-Free-Scanner. Deckt Images, Dateisysteme, Git-Repos, Kubernetes ab. Aktive Entwicklung.
• Grype — In manchen Benchmarks schneller als Trivy, gutes Schwachstellen-Matching.
• Clair — Von Red Hat/Quay. Für Container-Registries ausgelegt. Komplexeres Setup.
• Docker Scout — In Docker Desktop und Docker Hub integriert. Kostenlose Stufe verfügbar.
• Cosign — Signiert und verifiziert Container-Images. Teil des Sigstore-Projekts.

Kommerziell:

• Snyk Container — Integriert sich in Registries und CI/CD. Teil der Snyk-Plattform.
• Aqua Security — Vollständige Container- und Kubernetes-Sicherheitsplattform. Enterprise-Preise.
• Sysdig Secure — Laufzeitschutz plus Schwachstellen-Scanning.
• Prisma Cloud (Twistlock) — Palo Altos Container-Sicherheit. Enterprise.

Infrastruktur-Schwachstellen-Scanning

Kostenlos/Open Source:

• OpenVAS — Vollständiger Schwachstellen-Scanner. Community-Edition ist kostenlos. Scannt Netzwerke und Hosts.
• Nuclei — Schneller, vorlagen-basierter Scanner. Hervorragend für benutzerdefinierte Prüfungen. Sehr aktive Community.
• Nmap — Kein Schwachstellen-Scanner per se, aber unverzichtbar für Discovery. Mit Skripten für grundlegende Schwachstellenerkennung verwendbar.
• Lynis — Sicherheits-Auditing für Linux/Unix. Prüft Konfiguration, keine Schwachstellen.

Kommerziell:

• Nessus — Industriestandard. Essentials-Version (16 IPs) ist kostenlos. Professional ab ~3.000 $/Jahr.
• Qualys — Cloud-basierte Scanning-Plattform. Enterprise-Preise.
• Rapid7 InsightVM — Schwachstellenverwaltung mit Behebungs-Tracking.
• AWS Inspector — Scannt EC2-Instanzen und Container-Images in AWS. Bezahlung pro Scan.

Patch-Management

Kostenlos/Open Source:

• Ansible — Automatisiert das Patchen über Server hinweg. Kostenlos und Open Source. Steile Lernkurve, aber mächtig.
• Puppet / Chef — Konfigurationsmanagement, das Patch-Levels durchsetzen kann. Open-Source-Kerne.

Cloud-nativ:

• AWS Systems Manager Patch Manager — Kostenlos für AWS-Ressourcen. Patch-Baselines definieren, Patch-Fenster planen.
• Azure Update Management — In Azure enthalten. Aktualisierungen über Windows- und Linux-VMs verwalten.
• GCP OS Patch Management — Teil des VM-Managers. Compute-Engine-VMs patchen.

Kommerziell:

• Automox — Cloud-natives Patch-Management. Funktioniert über Windows, macOS, Linux. Preise pro Endpunkt.
• ManageEngine Patch Manager Plus — On-Premise oder Cloud. Unterstützt viele Betriebssysteme und Drittanbieter-Apps.
• Ivanti — Enterprise-Patch-Management.

SBOM (Software Bill of Materials)

SBOMs werden für Compliance und Supply-Chain-Sicherheit unverzichtbar. Sie listen alle Komponenten Ihrer Software auf.

Kostenlos/Open Source:

• Syft — Generiert SBOMs aus Container-Images und Dateisystemen. Gibt SPDX- und CycloneDX-Formate aus.
• Trivy — Generiert ebenfalls SBOMs. Verwenden Sie trivy image --format spdx myimage:latest.
• CycloneDX — SBOM-Standard mit Tools für viele Sprachen (Maven, npm, pip usw.).

Kommerziell:

• Anchore Enterprise — SBOM-Generierung plus Policy-Durchsetzung und Compliance.
• Dependency-Track — Open-Source-Plattform zum Verfolgen von SBOMs und Schwachstellen in Ihrem Portfolio. Self-hosted.

Was für ein kleines Unternehmen zu wählen ist

Wenn Sie gerade erst anfangen, ist hier ein praktischer Stack:

1. Dependabot oder Renovate für Abhängigkeits-Aktualisierungen (kostenlos)
2. Trivy für Container-Scanning (kostenlos)
3. GitHub-Sicherheitsfunktionen für Code-Scanning und Secret-Erkennung (kostenlos für öffentliche Repos)
4. OpenVAS oder Nessus Essentials für Infrastruktur-Scanning (kostenlos)
5. Ansible für Patch-Automatisierung bei vielen Servern (kostenlos)
6. Syft für SBOM-Generierung bei Compliance-Bedarf (kostenlos)

Fügen Sie kommerzielle Tools hinzu, wenn:

• Sie zentralisierte Dashboards über viele Repositories benötigen
• Compliance spezifische Berichte erfordert
• Sie Priorisierungs-Intelligence benötigen (welche Schwachstellen sind tatsächlich ausnutzbar)
• Sie über kostenlose Stufen hinauswachsen

Aufbau eines CVE-Monitoring-Prozesses

Über Schwachstellen in Ihrem spezifischen Stack informiert zu sein, erfordert mehr als automatisiertes Scanning.

Ihren Stack kennen

Dokumentieren Sie zunächst, was Sie betreiben. Mindestens:

• Programmiersprachen und Versionen (Python 3.11, Node 20 usw.)
• Frameworks (Django 4.2, Express 4.18, React 18)
• Datenbanken (PostgreSQL 15, MongoDB 7)
• Infrastruktur (Ubuntu 22.04, nginx 1.24, Redis 7)
• Kritische SaaS-Abhängigkeiten (Stripe SDK, AWS SDK usw.)

Das dauert 30 Minuten zum Zusammenstellen. Speichern Sie es an einem Ort, auf den alle zugreifen können – Ihre SaaS-Inventar-Tabelle ist ein guter Platz.

Benachrichtigungen für Ihren Stack einrichten

Option 1: CVE-Datenbanken direkt

Abonnieren Sie Benachrichtigungen von:

• NVD — Die National Vulnerability Database, umfassend, aber laut
• CISA KEV — Known Exploited Vulnerabilities, kleinere Liste aktiv ausgenutzter Probleme

Option 2: Anbieter-Sicherheitsseiten

Die meisten großen Projekte haben Sicherheits-Ankündigungslisten:

• Ubuntu Security Notices
• Node.js Security Releases
• Django Security Releases
• PostgreSQL Security

Abonnieren Sie die RSS-Feeds oder Mailinglisten für Ihre kritischen Abhängigkeiten.

Option 3: Aggregierte Benachrichtigungen

• OSV — Open-Source-Schwachstellendatenbank, gut organisiert
• GitHub Advisory Database — Gut für Abhängigkeiten von GitHub

Die wöchentliche CVE-Prüfung

Setzen Sie ein wiederkehrendes Kalender-Ereignis: „CVE-Review" – 30 Minuten, einmal pro Woche.

In dieser Zeit:

1. Dependabot-/Snyk-Warnungen prüfen, die diese Woche geöffnet wurden
2. CISA-KEV auf neue Einträge für Ihren Stack scannen
3. Sicherheitsnachrichten auf wichtige Schwachstellen überfliegen (kurze RSS-Prüfung oder Folgen von Sicherheitsforschern)
4. Priorisieren, was diese Woche vs. nächsten Monat gepatcht werden muss

Es geht nicht darum, jeden CVE zu lesen. Es geht darum, von den kritischen nicht überrascht zu werden.

Priorisierung von Aktualisierungen

Nicht jede Schwachstelle erfordert sofortiges Handeln. Hier ist ein praktischer Priorisierungsrahmen:

Sofort patchen (innerhalb von 24–48 Stunden)

• Kritischer/hoher Schweregrad UND aktiv in freier Wildbahn ausgenutzt
• Betrifft internet-zugängliche Systeme
• CISA fügt es der KEV-Liste hinzu

Beispiele: Log4Shell, ProxyLogon, aktuelle Zero-Days in Browsern.

Diese Woche patchen

• Kritischer/hoher Schweregrad, noch nicht ausgenutzt
• Betrifft interne Systeme mit sensiblen Daten
• Hat einen funktionierenden Proof-of-Concept-Exploit veröffentlicht

Diesen Monat patchen

• Mittlerer Schweregrad
• Erfordert spezifische Bedingungen zur Ausnutzung
• Betrifft nicht-kritische Systeme

Während regulärer Zyklen bewerten

• Niedriger Schweregrad
• Theoretische Schwachstellen ohne praktische Exploits
• Defense-in-Depth-Anliegen

Schauen Sie im Zweifel auf den CVSS-Score und ob es aktive Ausnutzung gibt. Eine theoretische Schwachstelle ohne bekannten Exploit ist weniger dringend als eine moderate Schwachstelle mit einem Metasploit-Modul.

Wie man einen CVE liest und das tatsächliche Risiko bewertet

Wenn ein CVE in Ihren Benachrichtigungen erscheint, so beurteilen Sie schnell, ob Panik angebracht ist:

1. CVSS-Score und Vektor prüfen

CVSS-Scores reichen von 0–10. Aber der Score allein reicht nicht – schauen Sie auf den Vektor:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Schlüsselteile:

• AV (Attack Vector): N=Netzwerk (schlimmster Fall), A=Benachbart, L=Lokal, P=Physisch
• AC (Attack Complexity): L=Niedrig (leicht auszunutzen), H=Hoch (braucht spezifische Bedingungen)
• PR (Privileges Required): N=Keine (schlimmster Fall), L=Niedrig, H=Hoch
• UI (User Interaction): N=Keine (schlimmster Fall), R=Erforderlich

Eine netzwerk-zugängliche, niedrig-komplexe, authentifizierungsfreie Schwachstelle ist schlimmer als ein hoch-komplexer lokaler Exploit, der Admin-Zugriff erfordert – auch wenn beide 8.0 erzielen.

2. Bekannte Ausnutzung prüfen

• Steht es auf CISA KEV? → Angreifer nutzen es aktiv aus
• Gibt es ein Metasploit-Modul? → Script-Kiddies können es ausnutzen
• Gibt es Berichte über Ausnutzung in freier Wildbahn? → Twitter/Mastodon, Sicherheitsnachrichten prüfen

Ein CVE mit aktiver Ausnutzung ist dringend, unabhängig vom CVSS-Score.

3. Prüfen, ob Sie tatsächlich verwundbar sind

• Verwenden Sie die betroffene Komponente?
• Ist die verwundbare Funktion/das verwundbare Feature aktiviert?
• Ist es dem Netzwerk oder nur intern zugänglich?

Beispiel: Eine kritische Schwachstelle in Apaches mod_proxy betrifft Sie nicht, wenn Sie nginx verwenden.

4. Prüfen, ob Sie bereits geschützt sind

Manchmal mildern andere Abwehrmaßnahmen das Risiko:

• WAF-Regeln blockieren den Angriff
• Netzwerksegmentierung begrenzt die Exposition
• Der verwundbare Dienst ist nicht internet-zugänglich

Das bedeutet nicht „nicht patchen", beeinflusst aber die Priorität.

5. Das Advisory lesen, nicht nur die Schlagzeile

Sicherheitsnachrichten dramatisieren oft. Das eigentliche Anbieter-Advisory sagt Ihnen:

• Genau welche Versionen betroffen sind
• Was die Lösung ist
• Workarounds, wenn Sie nicht sofort aktualisieren können
• Ob die Schwachstelle eine spezifische Konfiguration erfordert

Verantwortlichkeit schaffen

Aktualisierungen passieren nicht ohne Eigentümerschaft.

Aktualisierungs-Verantwortlichkeiten zuweisen

In Ihrer SaaS-Inventar-Tabelle oder einem separaten Dokument, weisen Sie Eigentümer zu:

System	Aktualisierungs-Verantwortlicher	Aktualisierungshäufigkeit	Zuletzt aktualisiert
Ubuntu-Server	DevOps Lead	Wöchentlich automatisch + monatlich manuell	2024-01-15
Docker-Base-Images	Jedes Team	Wöchentliche Neubauten	Kontinuierlich
npm-Abhängigkeiten	Frontend-Team	Wöchentliche Dependabot-Review	2024-01-12
Python-Abhängigkeiten	Backend-Team	Wöchentliche Dependabot-Review	2024-01-12
PostgreSQL	DevOps Lead	Vierteljährlich oder kritische Patches	2024-01-01

Aktualisierungs-Rückstand verfolgen

Führen Sie ein einfaches Protokoll überfälliger Aktualisierungen:

Komponente	Aktuelle Version	Neueste Version	Tage zurück	Blocker
React	17.0.2	18.2.0	180	Breaking Changes erfordern Tests
lodash	4.17.15	4.17.21	90	Keiner, nur vernachlässigt

Prüfen Sie das monatlich. Dinge, die 90+ Tage liegen, brauchen eine Entscheidung: aktualisieren, Risiko akzeptieren oder Abhängigkeit ersetzen.

Das monatliche Aktualisierungs-Meeting

15 Minuten, einmal im Monat. Teilnehmer: Security Champion, DevOps Lead, ein Entwickler pro Team.

Agenda:

1. Kritische CVEs des letzten Monats prüfen (2 Min.)
2. Aktualisierungs-Rückstand auf Überfälligkeiten prüfen (3 Min.)
3. Was wird nächsten Monat priorisiert (5 Min.)
4. Aktualisierungsfehler oder Rollbacks besprechen (5 Min.)

Das ist alles. Regelmäßige Sichtbarkeit verhindert, dass Aktualisierungen durchs Raster fallen.

Praktische Tipps, die Zeit und Schmerz sparen

Diese Tricks stehen nicht in der offiziellen Dokumentation, machen aber das Leben leichter.

Verifizieren, dass automatische Aktualisierungen wirklich funktionieren

Automatische Aktualisierungen einrichten und dann tatsächlich prüfen, ob sie laufen. Ein häufiger Fehler: unattended-upgrades installiert, aber nie ausgeführt.

# Ubuntu/Debian: check last run
cat /var/log/unattended-upgrades/unattended-upgrades.log | tail -50

# Check if it's scheduled
systemctl status apt-daily-upgrade.timer

# RHEL/CentOS: check dnf-automatic
journalctl -u dnf-automatic-install.service --since "7 days ago"

Wenn die Protokolle leer sind oder der Timer deaktiviert ist, finden Ihre „automatischen" Aktualisierungen nicht statt.

Schnelles Versions-Audit-Skript

Bevor Sie aktualisieren können, müssen Sie wissen, was Sie betreiben. Diese Einzeiler geben Ihnen einen schnellen Überblick:

# Get all installed packages with versions (Debian/Ubuntu)
dpkg-query -W -f='${Package} ${Version}\n' > installed-packages.txt

# For Python projects
pip freeze > python-deps.txt

# For Node projects
npm list --depth=0 > node-deps.txt

# For Docker base images in your codebase
grep -r "FROM " --include="Dockerfile*" . | sort -u

Speichern Sie diese Snapshots. Wenn ein CVE auftaucht, können Sie schnell per grep prüfen, ob Sie betroffen sind.

Die Freitags-Regel

Deployen Sie niemals Aktualisierungen am Freitagnachmittag. Wenn etwas kaputt geht, reparieren Sie es entweder am Wochenende oder lassen es bis Montag defekt.

Beste Zeiten zum Patchen:

• Dienstag- oder Mittwochmorgen (Zeit zur Erholung vor dem Wochenende)
• Nach einem großen Release, nicht davor (fügen Sie keine Variablen vor großen Deployments hinzu)
• Während Niedriglastzeiten für Produktionssysteme

Stellen Sie Ihre automatischen Aktualisierungszeiten entsprechend ein. Die 03:00-Neustartzeit in den Konfigurationsbeispielen ist kein Zufall.

Canary-Aktualisierungen für Produktion

Aktualisieren Sie nicht alle Produktionsserver auf einmal. Wenn Sie mehrere Server haben:

1. Zuerst einen Server aktualisieren (den Canary)
2. 15–30 Minuten überwachen
3. Wenn keine Probleme, die restlichen aktualisieren
4. Bei Problemen den Canary rollbacken, bevor die anderen berührt werden

Für Kubernetes verwenden Sie Rolling Updates mit Readiness-Probes. Für traditionelle Server ermöglicht Ansibles serial-Parameter die Aktualisierung in Batches.

Notfall-Rollback-Checkliste

Vor jeder bedeutenden Aktualisierung wissen, wie man zurückrollt:

Für Pakete:

# Debian/Ubuntu: downgrade to specific version
apt install package=1.2.3-4

# See available versions
apt-cache policy package

Für Container:

# Keep previous image tagged
docker tag myapp:latest myapp:previous
docker build -t myapp:latest .

# Rollback = redeploy previous tag
docker run myapp:previous

Für Datenbanken: Nehmen Sie vor jedem Datenbankversions-Upgrade einen Snapshot. Ernsthaft. Jedes Mal. Datenbank-Rollbacks sind ohne Snapshots schmerzhaft.

Für Cloud-VMs: Snapshot der Instanz vor größeren OS-Aktualisierungen. AWS, GCP und Azure unterstützen das alle. Es ist eine günstige Versicherung.

Changelogs als Freund nutzen

Wenn Dependabot oder Renovate einen PR öffnet, mergen Sie nicht blind. Nehmen Sie sich 60 Sekunden:

1. Den Changelog-Link anklicken (meist in der PR-Beschreibung)
2. Auf „BREAKING CHANGES" oder „Deprecation" überfliegen
3. Prüfen, ob es ein Sicherheits-Fix ist (diese priorisieren)

Die meisten Aktualisierungen sind problemlos. Aber das eine Mal, wenn Sie das überspringen und die Produktion kaputt machen, werden Sie sich wünschen, die Minute investiert zu haben.

Slack/Teams-Benachrichtigungen für kritische CVEs

Richten Sie automatische Benachrichtigungen ein, damit Sie nicht daran denken müssen, nachzuschauen:

Option 1: RSS nach Slack

Verwenden Sie IFTTT oder Zapier, um RSS-Feeds in einen Slack-Kanal zu leiten:

• CISA KEV RSS: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
• NVD RSS: https://nvd.nist.gov/feeds/xml/cve/misc/nvd-rss.xml

Option 2: GitHub nach Slack

GitHub kann Dependabot-Warnungen über Webhooks an Slack senden. Settings → Integrations → Slack → Subscribe to security alerts.

Option 3: Snyk-Slack-Integration

Wenn Sie Snyk verwenden, haben diese eine native Slack-Integration. Neue Schwachstellen in Ihren Projekten werden automatisch in Ihren Kanal gepostet.

Der „Anbieter-Sicherheitsseiten"-Lesezeichen-Ordner

Erstellen Sie einen Browser-Lesezeichen-Ordner mit Sicherheitsseiten für Ihre kritischen Abhängigkeiten. Wenn ein großer CVE auftaucht, können Sie schnell prüfen, ob Ihre Anbieter Aktualisierungen haben:

• Den Sicherheits-Tracker Ihrer Linux-Distribution
• Die Sicherheitsseite Ihrer Sprache (Python, Node usw.)
• Die Sicherheitsankündigungen Ihres Frameworks
• Die Sicherheitsbulletins Ihres Cloud-Anbieters

Braucht 2 Minuten zur Einrichtung. Spart 20 Minuten Googeln während eines Vorfalls.

Lock-Dateien: der unbesungene Held

Stellen Sie sicher, dass Sie Lock-Dateien einchecken:

• package-lock.json oder yarn.lock für Node
• Pipfile.lock oder poetry.lock für Python
• go.sum für Go
• Gemfile.lock für Ruby

Lock-Dateien stellen sicher, dass alle exakt dieselben Versionen installieren. Ohne sie könnte npm install auf Ihrem Laptop andere Versionen bekommen als npm install in der CI-Umgebung.

Dependabot aktualisiert Lock-Dateien automatisch. Wenn Sie manuell aktualisieren, führen Sie immer den Installationsbefehl aus, um die Lock-Datei neu zu generieren.

Aktualisierungen testen ohne vollständige CI

Für schnelle lokale Tests von Abhängigkeits-Aktualisierungen:

# Create a branch
git checkout -b test-update

# Update the dependency
npm update lodash  # or pip install --upgrade package

# Run tests locally
npm test

# If tests pass, commit and push
# If tests fail, reset
git checkout -- package.json package-lock.json

Das ist schneller als auf CI zu warten für jede kleine Aktualisierung. Verwenden Sie es für Routine-Aktualisierungen; nutzen Sie vollständige CI für Sicherheits-Patches.

Die „bekannt gut"-Basislinie

Halten Sie fest, welche Versionen zusammen funktionieren. Wenn alles reibungslos läuft:

# Capture working state
npm list --depth=0 > known-good-$(date +%Y%m%d).txt
pip freeze > known-good-python-$(date +%Y%m%d).txt

Beim Debuggen von Aktualisierungsproblemen können Sie gegen Ihren bekannten guten Zustand vergleichen, um zu sehen, was sich geändert hat.

Mit aufgegebenen Abhängigkeiten umgehen

Einige Abhängigkeiten bekommen keine Sicherheits-Aktualisierungen mehr. Anzeichen für Aufgabe:

• Keine Commits seit 12+ Monaten
• Keine Reaktion auf Sicherheitsprobleme
• Maintainer hat End-of-Life angekündigt

Für diese:

1. Prüfen, ob es einen aktiv gepflegten Fork gibt
2. Erwägen, durch eine Alternative zu ersetzen
3. Wenn Sie es behalten müssen, den Code selbst prüfen oder isolieren

Das npm-Ökosystem hat besondere Probleme mit aufgegebenen Paketen. Tools wie Socket kennzeichnen diese Risiken speziell.

Workshop: Aktualisierungen und Schwachstellen-Monitoring einrichten

Reservieren Sie 2–3 Stunden dafür.

Teil 1: Automatische Aktualisierungen aktivieren (45 Minuten)

1. Ihre Server auf aktuelle Aktualisierungskonfiguration prüfen
2. unattended-upgrades auf Ubuntu/Debian-Servern aktivieren
3. dnf-automatic auf RHEL/CentOS/Rocky-Servern aktivieren
4. Verifizieren, dass automatische Aktualisierungen funktionieren (Protokolle prüfen)
5. Server dokumentieren, bei denen Sie sich gegen automatische Aktualisierungen entschieden haben, und warum

Teil 2: Dependabot einrichten (30 Minuten)

1. .github/dependabot.yml in Ihren Haupt-Repositories erstellen
2. Für alle relevanten Paket-Ökosysteme konfigurieren
3. Dependabot-Sicherheitswarnungen in den Repository-Einstellungen aktivieren
4. Bestehende Dependabot-PRs prüfen und mergen oder schließen

Teil 3: Container-Scanning hinzufügen (30 Minuten)

1. Trivy oder Snyk zu einer CI-Pipeline hinzufügen
2. Konfigurieren, um bei HOCH/KRITISCH-Schwachstellen fehlzuschlagen
3. Ihre aktuellen Images scannen und Befunde dokumentieren
4. Kritische gefundene Probleme beheben oder dokumentieren

Teil 4: CVE-Monitoring-Prozess aufbauen (30 Minuten)

1. Ihren Technologie-Stack dokumentieren (Sprachen, Frameworks, Infrastruktur)
2. Sicherheitsankündigungen für Ihre 5 kritischsten Abhängigkeiten abonnieren
3. Wöchentliche Kalender-Erinnerung für CVE-Review einrichten
4. Aktualisierungs-Eigentümertabelle erstellen

Ergebnisse:

• Automatische Aktualisierungen auf allen anwendbaren Servern aktiviert
• Dependabot für alle Repositories konfiguriert
• Container-Scanning in mindestens einer CI-Pipeline
• Technologie-Stack dokumentiert
• Aktualisierungs-Eigentümerschaft zugewiesen
• Wöchentliche CVE-Review eingeplant

Gespräch mit der Unternehmensleitung

Wenn jemand fragt, warum Sie Zeit damit verbracht haben:

„Ich habe automatische Sicherheits-Aktualisierungen für unsere Server und automatisiertes Schwachstellen-Scanning für unseren Code und unsere Container eingerichtet. Die meisten Einbrüche passieren durch bekannte, gepatchte Schwachstellen – Angreifer scannen nach veralteter Software. Jetzt wissen wir, wenn wir verwundbare Komponenten haben, und haben einen Prozess, um sie zu patchen, bevor Angreifer sie finden. Das hat ein paar Stunden zum Einrichten gedauert und läuft automatisch."

Kurzfassung: „Ich habe unser Sicherheits-Patching automatisiert, damit wir nicht durch bekannte Schwachstellen kompromittiert werden."

Selbstcheck: Haben Sie es wirklich getan?

Automatische Aktualisierungen

• Unattended-upgrades oder dnf-automatic auf Servern aktiviert
• Verifiziert, dass Aktualisierungen tatsächlich laufen (Protokolle geprüft)
• Ausgeschlossene Server dokumentiert und warum
• Container-Images auf wöchentliche Neubauten eingestellt (oder manueller Prozess dokumentiert)

Abhängigkeits-Scanning

• Dependabot auf Haupt-Repositories aktiviert
• Für alle relevanten Paket-Ökosysteme konfiguriert (npm, pip, docker usw.)
• Bestehende Dependabot-PRs geprüft und behandelt
• Snyk oder Trivy in mindestens eine CI-Pipeline integriert

CVE-Monitoring

• Technologie-Stack dokumentiert (Sprachen, Frameworks, Versionen)
• Sicherheitsankündigungen für kritische Abhängigkeiten abonniert
• Wöchentliche CVE-Review-Kalender-Erinnerung gesetzt
• CISA KEV gegen Ihren Stack geprüft

Verantwortlichkeit

• Aktualisierungs-Eigentümerschaft für jeden Systemtyp zugewiesen
• Aktualisierungs-Rückstand dokumentiert (was zurückliegt und warum)
• Monatliches Aktualisierungs-Review eingeplant

Wenn Sie mindestens 12 dieser 15 Punkte abhaken können, sind Sie bereit, weiterzumachen.

Was kommt als Nächstes

Sie haben jetzt Transparenz über Ihre Schwachstellen und einen Prozess zu deren Behebung. Die offensichtlichen Lücken werden automatisch geschlossen.

Nächstes Kapitel: E-Mail-Sicherheit – SPF, DKIM, DMARC und der Schutz Ihres Unternehmens vor Phishing und Spoofing-Angriffen.