Was bedeutet Schwachstellenmanagement?

Schwachstellenmanagement ist ein kontinuierlicher Kreislauf: Sicherheitslücken erkennen, bewerten, priorisieren und beheben – unabhängig davon, ob sie in Drittanbieter-Bibliotheken oder im eigenen Code stecken.

Moderne Software besteht aus einer Vielzahl von Open-Source- und kommerziellen Komponenten. Jede einzelne kann potenzielle Sicherheitsrisiken bergen. Unsere Aufgabe ist es, diese Schwachstellen zu identifizieren, bevor Angreifer es tun – und unsere Entwickler effizient zur Lösung zu führen, ohne sie auszubremsen.

Unsere Erfahrung zeigt: Schwachstellenmanagement funktioniert nicht als isolierter Prozess. Deshalb verfolgen wir einen DevSecOps-Ansatz, bei dem Sicherheitsprozesse direkt in den Softwareentwicklungszyklus integriert werden. So erkennen wir Probleme frühzeitig und können schnell gegensteuern.

Infografik des DevOps-Lebenszyklus als Unendlichkeitsschleife, die die Phasen veranschaulicht: Code, Plan, Build, Test (DEV); Release, Deploy, Operate, Monitor (OPS). Jede Phase ist mit einem Symbol gekennzeichnet, das ihre Funktion darstellt.

Abbildung 1: DevSecOps-Ansatz im Schwachstellenmanagement.

Unsere Sicherheitsservices bei Open Systems basieren auf einem ganzheitlichen Software-Stack:

  • Upstream-Open-Source-Projekte
  • Originalgerätehersteller (OEM) und kommerzielle Komponenten mit eigenem Patch-Zyklus
  • Tausende Zeilen Eigenentwicklungen, die alles zusammenführen und einzigartigen Mehrwert schaffen

Da die Angriffsfläche Code, Abhängigkeiten und Infrastruktur umfasst, nutzen wir zwei sich ergänzende Modi im Schwachstellenmanagement: proaktiv und reaktiv.

Ein Flussdiagramm, das die proaktive Überwachung bekannter Schwachstellen, die regelmäßige Überprüfung auf Schwachstellen alle 2 Stunden und die Identifizierung neu entdeckter Schwachstellen veranschaulicht; der Text ist in Deutsch.

Abbildung 2: Proaktiver Modus verhindert bekannte Schwachstellen, reaktiver Modus adressiert neu entdeckte Sicherheitslücken.

Beide Modi sichern unsere Umgebung wirksam und flexibel:

  • Der proaktive Modus verhindert, dass Schwachstellen überhaupt entstehen: kontinuierliche Analysen von Abhängigkeiten und Quellcode (SCA & SAST) bei jedem Pull Request, Sicherheitsarchitektur-Reviews vor neuen Implementierungen sowie konkrete Behebungsvorschläge.
  • Der reaktive Modus tritt in Kraft, wenn neue externe Bedrohungen auftauchen. Dazu gehören:
    • 24×7-Monitoring auf CVEs
    • Eine stets aktuelle Inventarliste aller Software- und Infrastrukturkomponenten
    • Automatisierte Notfall-Patch-Pipelines
    • Kompensierende Schutzmassnahmen durch unser Operations Center – Mission Control

In der Praxis bedeutet das: Wir identifizieren, bewerten, priorisieren und beheben Schwachstellen kontinuierlich – egal ob sie aus Open Source, kommerziellen Tools oder eigenem Code stammen. Das Ergebnis: ein einheitlicher, wiederholbarer Workflow, der sowohl Eigenentwicklungen als auch integrierte Komponenten schützt – vor, während und nach kritischen Angriffen.

Warum wir etwas ändern mussten

Eine Woche vor Weihnachten 2021 erhielten die Entwicklungsleiter eine interne E-Mail mit der Frage:
„Sind wir von Log4Shell betroffen? “Eine scheinbar einfache Frage – aber die Antwort war alles andere als simpel.

Log4Shell war eine kritische Sicherheitslücke in der weit verbreiteten Java-Bibliothek Log4J mit einem CVSS-Score von 10.0 – dem Höchstwert. Betroffen waren Cloud-Anwendungen genauso wie IoT-Geräte. Bis heute gilt sie als eine der schwerwiegendsten Schwachstellen überhaupt.

Das Tückische: Die Bibliothek konnte tief in transitive Abhängigkeiten eingebettet sein – und war dadurch schwer aufzuspüren.

Manuelles Durchforsten sämtlicher Repositories nach bestimmten Versionen oder Log4J-Verwendungen kostete Zeit, Nerven und machte uns klar: Wir dürfen beim nächsten Zero-Day-Angriff nicht im Dunkeln tappen. Wir brauchten Echtzeiteinblicke und standardisierte Prozesse – keine heldenhaften Excel-Tabellen und doppelten Espressi. Als Entwickler, der für Sicherheit brennt, war mir klar: Hier kann ich einen echten Beitrag leisten.

Fundament schaffen: OWASP SAMM und Open Source

Statt das Rad neu zu erfinden, nutzten wir das OWASP Software Assurance Maturity Model (SAMM) als Fahrplan und Benchmark. SAMM liefert messbare Praktiken, die sich gut in DevSecOps integrieren lassen. So konnten wir uns auf die Umsetzung konzentrieren – und unsere Methoden bleiben nachvollziehbar und auditierbar.

Bei den Tools führten wir einen offenen Vergleich von kommerziellen und Open-Source-Scannern durch für:

  • Software Composition Analysis (SCA) – erkennt verwundbare Abhängigkeiten
  • Static Application Security Testing (SAST) – entdeckt unsichere Code-Muster

Open-Source-Lösungen erfüllten unsere Anforderungen an Genauigkeit und Performance, vermieden Vendor-Lock-in und ermöglichten uns, Upstream-Fixes beizutragen – also setzten wir auf sie.

Eine Code-Scan-Ausgabe zeigt "Sicherheitsprüfungen fehlgeschlagen!" mit Fehlern, die als SCA und SAST gekennzeichnet sind, hervorgehoben durch grüne Pfeile, die auf "Software Composition Analysis (SCA)" und "Static Application Security Testing (SAST)" zeigen.

Abbildung 3: SCA und SAST.

„Shift left“ ohne Umwege

Entwickler sollten nicht in ihren Workflow unterbrochen werden. Deshalb haben wir Scanner direkt in die GitHub Pull Requests integriert. Die Bots kommentieren den Code wie menschliche Reviewer und zeigen:

  • das betroffene Paket oder API
  • CVSS-Schweregrad und Links zu Security-Advisories
  • Konkrete Lösungsvorschläge (z.B. sichere API oder Upgrade)
  • Geheimnisse, die nicht ins Repository gehören

Ein Pull Request kann nicht gemerged werden, solange eine kritische Schwachstelle offen ist – neue Fehler gelangen somit nie ins produktive System. Für bestehenden Code führen wir alle zwei Stunden Scans durch, benachrichtigen Teams per Chat bei neuen Findings und erstellen automatisch Wartungstickets inklusive SLA-basierten Deadlines.

Screenshot der Diskussion zur Codeüberprüfung. Es wird eine hervorgehobene SQL-Abfrage mit einer potenziellen Schwachstelle gezeigt. Zwei grüne Pfeile zeigen auf den Code ("Schwachstelle im Code") und die darunter liegende Erklärung der Schwachstelle ("Erklärung der Schwachstelle").

Abbildung 4: Schwachstellen direkt im Code sichtbar machen.

„Ich fühle mich beim Coden sicherer. Der Bot erkennt Probleme frühzeitig – so kann ich mich auf Features konzentrieren und mich trotzdem als Entwickler verbessern.“
– Security Engineer

Developer Experience trifft Security

Sicherheitstools werden oft als Stolpersteine empfunden. Unser Ziel war daher, sofortigen Mehrwert zu zeigen – durch unmittelbares Feedback, ohne Kontextwechsel und mit der Möglichkeit, Regeln selbst anzupassen oder zu erweitern. Sicherheit wurde in bestehende Prozesse und Tools integriert. Schulungen und Schnellstart-Dokumentationen machten skeptische Entwickler zu Security-Champions.

Jedes Team hat heute Sicherheitsverantwortliche, die Schwachstellen identifizieren, bewerten und beheben. Sie nutzen mehrere Quellen:

  • Integrierter Schwachstellenscanner
  • Hinweise von Herstellern
  • Weitere Quellen:
    • Automatisierte Codeanalysen
    • Interne/externe Audits
    • Kundenanfragen über Mission Control

Und wichtig: Zwei Schwachstellen mit gleicher Kritikalität müssen nicht gleich dringend sein. Deshalb bewerten wir kritische und hohe Findings individuell, um sofortige Massnahmen gezielt und priorisiert einzuleiten.

Ein Flussdiagramm in deutscher Sprache mit grünen Kästchen, das die Schritte für die automatische Verfolgung von Abhängigkeiten, die Erstellung von Tickets und Benachrichtigungen sowie Sicherheitsstatus-Dashboards in der Softwareentwicklung beschreibt, einschließlich Teamverantwortung und Code-Abhängigkeiten.

Abbildung 5: Übersicht des Schwachstellenmanagements bei Open Systems.

Der Kundennutzen im Fokus

Bei einem kürzlichen Onsite-Besuch sagte uns ein Kunde:

„Ich wünschte, unsere Entwickler könnten sehen, wie Schwachstellenmanagement wirklich funktioniert.“

Ein Kompliment, das uns stolz macht – aber nicht träge. Denn wir entwickeln unsere Prozesse laufend weiter und lernen aus neuen Bedrohungen. Die Vorteile für unsere Kunden:

  • Skalierbare Konsistenz: Ein Repository + dedizierte Security-Pipeline bedeuten: Jede Software durchläuft dieselben strengen Prüfungen. Keine vergessenen Spezialfälle.
  • Geschwindigkeit: Automatisierte Erkennung + vorgefertigte Projektmanagement-Tickets reduzieren die mittlere Reaktionszeit von Tagen auf Stunden.
  • Mission Control Support: Bei kritischen CVEs koordiniert unser Operations Center Notfall-Patchfenster oder implementiert sofortige Gegenmassnahmen (Firewall-Regeln, NDR-Signaturen), während das Engineering-Team am finalen Fix arbeitet.
Ein Praxisbeispiel: OpenSSH CVE-2024-6387

Für diese Schwachstelle wurden von Mission Control die Wartungsfenster koordiniert, Systeme gepatcht und neu gestartet – ohne ungeplante Ausfälle.

Ein Dashboard-Screenshot zeigt die wichtigsten Daten: CVE wurde am Montag, dem 1. Juli, veröffentlicht; die Korrektur wurde vom 1. bis 2. Juli bereitgestellt; und die gesamte Flotte wurde am 5. Juli eingeführt, wobei grüne Pfeile auf die entsprechenden Abschnitte verweisen.

Abbildung 6: Ein Praxisbeispiel.

Blick in die Zukunft

Schwachstellenmanagement wird nie „abgeschlossen“ sein – aber mit einem SAMM-basierten Prozess, Community-getriebenen Tools und einer Kultur gemeinsamer Verantwortung in Dev, Ops und Security sind wir bereit für die nächste Zero-Day-Bedrohung. Und unsere Kunden ebenso.

Möchten Sie wissen, wie dieses Vorgehen Ihre Sicherheitslage stärken kann?
Kontaktieren Sie uns – wir tauchen gerne mit Ihnen tiefer ein.