Sicherheit von Open-Source-Software: Lehren aus Heartbleed und Log4Shell, Komponenten bewerten, SBOM, SLSA, Schwachstellen und Meldung.
Open Source und Sicherheit: Heartbleed, Log4Shell und die Lehren daraus
Begriffe vorab
Open Source: Software, deren Quellcode öffentlich einsehbar ist und unter einer offenen Lizenz weitergegeben werden darf.
Maintainer: Person, die ein Open-Source-Projekt pflegt.
OpenSSF: Open Source Security Foundation: Gemeinschaftsinitiative zur Verbesserung der Sicherheit von Open-Source-Software.
Buffer Over-read: Fehler, bei dem mehr Speicher gelesen wird als vorgesehen.
Zero-Day: Schwachstelle, die ausgenutzt wird, bevor ein Fix existiert.
Offen heißt nicht automatisch geprüft
Die Offenheit von Quellcode ermöglicht Prüfung durch alle. Sie garantiert sie nicht: Wenn niemand hinsieht, hilft Offenheit nicht. Zwei große Fälle machten das sichtbar.
Heartbleed (2014)
Am 7. April 2014 wurde eine Schwachstelle in OpenSSL öffentlich (CVE-2014-0160, „Heartbleed“): Ein Fehler in der Heartbeat-Erweiterung von TLS erlaubte es, pro Anfrage bis zu 64 KB Arbeitsspeicher eines Servers auszulesen, ohne dass das in normalen Protokollen sichtbar war. Betroffen waren die Versionen 1.0.1 bis 1.0.1f. Am Tag der Veröffentlichung erschien eine korrigierte Version.
Die Folge ging über den Code hinaus: Es wurde berichtet, dass das OpenSSL-Projekt zuvor nur etwa 2.000 US-Dollar Spenden pro Jahr erhielt, obwohl es von Millionen Webseiten genutzt wird. Am 24. April 2014 gründete die Linux Foundation die Core Infrastructure Initiative: Zwölf Unternehmen sagten jeweils 100.000 US-Dollar pro Jahr für drei Jahre zu. 2020 ging daraus gemeinsam mit weiteren Initiativen die Open Source Security Foundation (OpenSSF) hervor (Start am 3. August 2020).
Log4Shell (2021)
Die Schwachstelle CVE-2021-44228 in der Java-Protokollierungsbibliothek Apache Log4j2 wurde von Chen Zhaojun (Alibaba Cloud Security Team) am 24. November 2021 an Apache gemeldet. Am 9. Dezember 2021 wurde ein Exploit bekannt, am 10. Dezember erschien die Korrektur in Version 2.15.0; weitere Versionen (2.16.0, 2.17.0, 2.17.1) folgten, als zusätzliche Probleme gefunden wurden. Der CVSS-Wert beträgt 10,0. Die Wirkung war so groß, weil die Bibliothek in sehr vielen Produkten steckt – oft ohne dass Betreiber das wussten.
Die Lehren
Wissen, was drinsteckt: Ohne Liste der Bestandteile (siehe SBOM-Lektion) lässt sich nicht beantworten, ob man betroffen ist.
Schnell patchen können: Updates müssen eingespielt und getestet werden können, ohne dass das Wochen dauert.
Projekte unterstützen: Wer Open Source nutzt, hängt von Menschen ab. Mitarbeit, Spenden und Prüfungen verbessern die Lage.
Fallstudie XZ Utils (2024): Ein Angreifer nutzte den Vertrauensprozess eines Projekts (siehe Lektion zur Lieferkette).
Open Source ist nicht unsicherer oder sicherer als proprietäre Software – es hängt davon ab, wer prüft, pflegt und aktualisiert.
Zum Selbermachen
Frage dich für ein eigenes Projekt: Welche zwei Open-Source-Bibliotheken würden im Ausfall am meisten schaden? Wer pflegt sie?
Lege fest, wie schnell du ein kritisches Update einspielen könntest.
Verwandte Themen
Open Source → „Komponenten bewerten“ und „SBOM und SLSA“. Lieferkette → „XZ Utils“. WordPress → Plugins sind ebenfalls Open-Source-Komponenten („WordPress-Plugin-Deepdive“).
Prüfstatus: Belegt (Stand 1. Oktober 2026): Heartbleed (öffentlich am 7. April 2014, CVE-2014-0160, Versionen 1.0.1 bis 1.0.1f, bis zu 64 KB pro Anfrage), die Gründung der Core Infrastructure Initiative am 24. April 2014 (zwölf Firmen, je 100.000 US-Dollar jährlich für drei Jahre), der Start der OpenSSF am 3. August 2020 sowie Log4Shell (CVE-2021-44228, Meldung 24. November 2021, Exploit 9. Dezember, Fix 2.15.0 am 10. Dezember, CVSS 10,0) wurden gegen CISA, Linux Foundation und Fachberichte geprüft. Nicht einzeln belegt: die Zahl von etwa 2.000 US-Dollar Spenden pro Jahr (aus Berichten, nicht aus einer Primärquelle), die Wertung „Open Source ist nicht per se sicherer oder unsicherer“ (Einordnung in eigenen Worten) und die Handlungsliste.
Quellen
CISA – „OpenSSL ‚Heartbleed‘ vulnerability (CVE-2014-0160)“ (8. April 2014)
Linux Foundation – Pressemitteilungen zur Core Infrastructure Initiative (April 2014) und zur Gründung der Open Source Security Foundation (August 2020)
Abhängigkeit: Fremde Bibliothek oder Paket, das dein Projekt nutzt.
Transitive Abhängigkeit: Abhängigkeit einer Abhängigkeit.
Lockfile: Datei, die genaue Versionen festschreibt.
Pinning: Festlegen auf eine bestimmte Version oder einen bestimmten Prüfwert.
OpenSSF Scorecard: Automatisches Werkzeug, das Sicherheitspraktiken eines Open-Source-Projekts bewertet.
Vor dem Einbau: Ist die Komponente gesund?
Jede Abhängigkeit vergrößert die Angriffsfläche. Prüfe vor dem Einbau, ob sie gepflegt wird, wer dahintersteht, wie schnell auf Meldungen reagiert wird und ob es einen Weg gibt, Schwachstellen zu melden. Ein Hilfsmittel ist die OpenSSF Scorecard, die im November 2020 vorgestellt wurde: Sie prüft automatisch Sicherheitspraktiken eines Projekts und vergibt eine Bewertung von 0 bis 10. Zu den Prüfungen gehören zum Beispiel Branch-Protection (Schutz vor ungeprüften Änderungen), Dependency-Update-Tool (automatische Aktualisierung der Abhängigkeiten) und Pinned-Dependencies (festgelegte Versionen). Nach einer Quelle sind es 18 Kriterien.
Während des Betriebs: Pflegen statt vergessen
Versionen festschreiben (Lockfile), damit Builds reproduzierbar bleiben und sich keine Überraschungen einschleichen.
Automatische Update-Vorschläge nutzen und diese prüfen, statt blind zu übernehmen.
Ungenutztes entfernen: Jede entfernte Abhängigkeit ist eine weniger.
Sicherheitsmeldungen beobachten für die Komponenten, die wirklich kritisch sind.
Bei Aufgabe eines Projekts rechtzeitig einen Ersatz suchen.
Die Grenzen von Bewertungen
Ein hoher Score bedeutet gute Praxis, nicht fehlerfreien Code. Ein niedriger Score kann bei kleinen, ruhigen Projekten auch einfach heißen, dass Automatisierung fehlt. Der Score ersetzt weder Codeprüfung noch eigene Tests.
Beispiel: Plugin auswählen
Zwei WordPress-Plugins erfüllen dieselbe Aufgabe. Plugin A wurde zuletzt vor drei Jahren aktualisiert, hat keinen Meldeweg für Schwachstellen und viele Abhängigkeiten. Plugin B wird regelmäßig gepflegt, veröffentlicht Änderungen mit nachvollziehbaren Hinweisen und hat eine security.txt. Die Wahl fällt auf B, auch wenn A ein paar Funktionen mehr bietet.
Weniger Abhängigkeiten sind besser als besser bewertete Abhängigkeiten.
Zum Selbermachen
Liste die zehn wichtigsten Abhängigkeiten eines Projekts auf und notiere Datum der letzten Version und den Meldeweg für Schwachstellen.
Aktiviere für ein Projekt einen automatischen Update-Hinweis und prüfe die ersten Vorschläge.
Verwandte Themen
Open Source → „SBOM und SLSA“ und „Schwachstellen verstehen und melden“. WordPress → „WordPress-Plugin-Deepdive“. Lieferkette → „XZ Utils und CRA“.
Prüfstatus: Belegt (Stand 1. Oktober 2026): Die OpenSSF Scorecard (Vorstellung im November 2020, Bewertung 0–10, die Prüfungen Branch-Protection, Dependency-Update-Tool und Pinned-Dependencies) wurde gegen OpenSSF-Seiten und Fachbeiträge geprüft. Nicht einzeln belegt: die Zahl von 18 Kriterien (nur aus einer Fachpublikation; die Zahl kann sich mit neuen Versionen ändern), die Pflegeliste (Einordnung in eigenen Worten) und das Pluginbeispiel (konstruiert).
Quellen
OpenSSF – „Security Scorecards for Open Source Projects“ (6. November 2020) und scorecard.dev
SBOM: Software Bill of Materials: maschinenlesbare Liste der Bestandteile einer Software.
SPDX: Offenes SBOM-Format, standardisiert als ISO/IEC 5962:2021.
CycloneDX: Weiteres verbreitetes SBOM-Format.
Provenienz: Nachweis, wie, wo und aus welchem Quellcode ein Artefakt gebaut wurde.
SLSA: Supply-chain Levels for Software Artifacts: Rahmen für abgesicherte Build-Prozesse.
Warum eine Stückliste?
Als Log4Shell bekannt wurde, lautete die erste Frage in vielen Organisationen: Setzen wir das ein, und wo? Eine SBOM beantwortet das, weil sie Bestandteile einer Software listet. Die US-Behörde NTIA beschrieb 2021 Mindestangaben: sieben Datenfelder – Lieferant, Komponentenname, Version, weitere eindeutige Kennungen, Abhängigkeitsbeziehung, Autor der SBOM-Daten und Zeitstempel. Dazu kommen Anforderungen an Maschinenlesbarkeit und Abläufe (Häufigkeit, Tiefe, Verteilung).
Formate
Verbreitet sind SPDX (Version 2.2.1 wurde im August 2021 als ISO/IEC 5962:2021 veröffentlicht) und CycloneDX (ein Projekt der OWASP-Community). Moderne Werkzeuge erzeugen sie automatisch aus dem Build.
SLSA: Wie wurde gebaut?
SLSA („Salsa“) wurde von Google initiiert und wird von der OpenSSF betreut. Version 1.0 betrachtet den Build-Track mit den Stufen 0 bis 3:
Stufe 1: Es gibt eine Provenienz, also einen Nachweis, wie das Artefakt gebaut wurde – noch unsigniert.
Stufe 2: Die Provenienz ist signiert und stammt von einer dedizierten Build-Plattform; Manipulation nach dem Build ist erkennbar.
Stufe 3: Die Build-Plattform ist so gehärtet, dass sich Builds nicht gegenseitig manipulieren können.
Nach Berichten wurde die Version 1.2 im November 2025 beschlossen und ergänzt einen Source-Track, der Quellhistorie und Schutz vor nachträglicher Manipulation behandelt.
Wie beides zusammenpasst
Die SBOM sagt was drinsteckt, SLSA sagt wie es entstanden ist. Zusammen helfen sie, nach einem Vorfall schnell zu klären, ob man betroffen ist, und im Vorfeld, Manipulationen im Build zu erschweren.
Beispiel
Ein Team erzeugt bei jedem Build automatisch eine SBOM und legt sie zusammen mit dem Release ab. Wird eine Schwachstelle in einer Bibliothek bekannt, durchsucht das Team die SBOMs aller Releases und kennt innerhalb von Minuten die betroffenen Produkte.
Fang klein an: eine automatisch erzeugte SBOM pro Release bringt bereits viel Nutzen.
Zum Selbermachen
Erzeuge für ein eigenes Projekt mit einem Werkzeug deiner Wahl eine SBOM im SPDX- oder CycloneDX-Format und sieh sie dir an.
Prüfe, ob dein Build-Prozess nachvollziehbar dokumentiert und reproduzierbar ist.
Verwandte Themen
Open Source → „Lehren aus Heartbleed und Log4Shell“. Lieferkette → „XZ Utils und CRA“ (der CRA verlangt Aufmerksamkeit für Komponenten). Normen → „NIST CSF 2.0“.
Prüfstatus: Belegt (Stand 1. Oktober 2026): Die sieben Mindestdatenfelder der NTIA (2021), SPDX als ISO/IEC 5962:2021 (August 2021), CycloneDX als verbreitetes Format und die SLSA-Stufen 0 bis 3 der Version 1.0 wurden gegen NTIA und Fachquellen geprüft. Nicht einzeln belegt: die Zuordnung von CycloneDX zur OWASP-Community (verbreitete Angabe, hier nicht gegen die Primärseite geprüft), die Aussage zu SLSA 1.2 und dem Source-Track (nur Sekundärberichte) sowie das Beispiel (konstruiert).
Quellen
NTIA – „The Minimum Elements For a Software Bill of Materials (SBOM)“ (Juli 2021)
CycloneDX – „Authoritative Guide to SBOM“ (cyclonedx.org)
SLSA – Spezifikation (slsa.dev), betreut von der OpenSSF
Schwachstellen verstehen und melden: CVE, CVSS, KEV, EPSS, security.txt
Begriffe vorab
CVE: Eindeutige Kennung einer öffentlich bekannten Schwachstelle.
CVSS: Common Vulnerability Scoring System: Bewertung des Schweregrads von 0 bis 10.
KEV: Known Exploited Vulnerabilities: CISA-Katalog der nachweislich ausgenutzten Schwachstellen.
EPSS: Exploit Prediction Scoring System: Schätzung der Wahrscheinlichkeit einer Ausnutzung.
Coordinated Disclosure: Abgestimmte Veröffentlichung, die Herstellern Zeit zum Beheben gibt.
Vier Begriffe, vier Fragen
CVE:Welche Schwachstelle ist gemeint? Beispiel: CVE-2021-44228 (Log4Shell).
CVSS:Wie schlimm kann sie im schlimmsten Fall sein? Die Version 4.0 wurde am 1. November 2023 vom FIRST veröffentlicht. Sie unterscheidet Base-, Threat-, Environmental- und Supplemental-Metriken. CVSS bewertet den Schweregrad, nicht das konkrete Risiko für dich.
KEV: Wird sie tatsächlich ausgenutzt? Der Katalog der CISA nennt Schwachstellen, für die eine Ausnutzung bekannt ist.
EPSS: Wie wahrscheinlich ist eine Ausnutzung? Ein Modell des FIRST schätzt das.
Priorisieren
Nicht jede „kritische“ Schwachstelle trifft dich gleich. Eine Lücke mit Wert 9,8 in einem System, das nicht aus dem Internet erreichbar ist und keine wichtigen Daten hält, ist weniger dringend als eine mittlere Lücke auf dem öffentlichen Datenbankserver. Eine sinnvolle Reihenfolge: (1) steht sie im KEV-Katalog? (2) Ist das System erreichbar und wichtig? (3) Wie hoch sind CVSS und EPSS? (4) Gibt es Ausweichmaßnahmen?
Schwachstellen melden und empfangen
Wenn du eine Schwachstelle findest, melde sie dem Hersteller auf dem vorgesehenen Weg und gib ihm Zeit zur Behebung (Coordinated Disclosure). Als Betreiber erleichterst du das, indem du eine security.txt bereitstellst. Der Standard RFC 9116 beschreibt dieses maschinenlesbare Format: Es liegt unter /.well-known/security.txt, wird über HTTPS ausgeliefert und enthält Felder wie Contact: mit der Meldeadresse.
Contact: mailto:security@example.org
Expires: 2027-12-31T23:59:00.000Z
Preferred-Languages: de, en
Canonical: https://example.org/.well-known/security.txt
Beispiel
Ein Team erhält Meldungen zu 40 Schwachstellen in Abhängigkeiten. Statt nach CVSS allein zu sortieren, prüft es zuerst die KEV-Liste, danach, welche Komponenten aus dem Internet erreichbar sind, und plant die übrigen in regulären Update-Zyklen ein.
Ein Meldeweg ist Teil von Sicherheit: Wer Hinweise nicht empfangen kann, erfährt von Lücken zuletzt.
Zum Selbermachen
Lege eine security.txt für ein eigenes Projekt an und veröffentliche sie.
Sortiere eine Liste bekannter Schwachstellen nach der obigen Priorisierung.
Verwandte Themen
Open Source → „Komponenten bewerten“. Betrieb → „Incident Response“. Normen & Recht → CRA (Meldepflichten für ausgenutzte Schwachstellen).
Prüfstatus: Belegt (Stand 1. Oktober 2026): Veröffentlichung von CVSS v4.0 am 1. November 2023 und seine Metrikgruppen, die Rolle von CVE, KEV und EPSS sowie der Aufbau von security.txt nach RFC 9116 (/.well-known/security.txt, HTTPS, Contact-Feld) wurden gegen FIRST, CISA und RFC-Verzeichnisse bzw. Fachquellen geprüft. Nicht einzeln belegt: die vorgeschlagene Prioritätenreihenfolge (Einordnung in eigenen Worten) und die Beschreibungen von KEV und EPSS (aus Sekundärquellen). Das Codebeispiel ist konstruiert; die Beispieldaten sind fiktiv.
Quellen
FIRST – „CVSS v4.0 Specification Document“ (first.org/cvss)
CISA – „Known Exploited Vulnerabilities Catalog“
IETF – RFC 9116 „A File Format to Aid in Security Vulnerability Disclosure“