Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
In Software-Teams überall spielt sich eine stille Krise ab, und die meisten von ihnen bemerken dies erst, wenn ein Sicherheitsaudit auf ihrem Schreibtisch landet. Eine Kernbibliothek, auf die sie sich seit Jahren verlassen haben, hat das EOL erreicht, oder End of Life. Die Upstream-Betreuer haben sich anderen Projekten zugewandt. Keine Patches mehr. Keine Fehlerbehebungen mehr. Aber die Bibliothek? Sie ist nach wie vor fest in der Produktion verankert und eng in eine Anwendung eingebunden, deren sichere Umgestaltung Monate dauern würde.
Das Upgrade auf eine unterstützte Version ist keine Aufgabe, die man mal eben am Wochenende erledigen kann. Es bedeutet defekte APIs, Regressionstests und Entwicklungszeit, die eigentlich für neue Funktionen vorgesehen war. Also tut das Team das, was Teams unter Druck oft tun: Sie schieben es auf. Und während sie es aufschieben, häufen sich die Sicherheitslücken.
EOL-Krise
Wenn Sie schon seit einiger Zeit im Web entwickeln, ist Ihnen der Begriff „EOL“ wahrscheinlich geläufig. Er bezeichnet den Zeitpunkt, zu dem ein Anbieter oder die Community keine Patches mehr für Sicherheitslücken bereitstellt. Was bedeutet das für Sie? Es bedeutet, dass die Uhr zu ticken beginnt. EOL bietet böswilligen Akteuren ein leichtes Ziel: Software, die noch in der Produktion läuft, für die aber keine Patches mehr bereitgestellt werden. Nur weil ein Upstream-Betreuer sich aus dem Code zurückzieht, heißt das nicht, dass dieser aus den Produktionsumgebungen verschwindet. Er ist nach wie vor vorhanden und potenziell völlig ungeschützt.
Definition von „Fertig“
Software-Teams ringen ständig mit der Frage, was die „Definition of Done“ (DoD) eigentlich bedeutet. Die ehrliche Antwort lautet: Das kommt darauf an – im Kern handelt es sich jedoch um eine gemeinsame Vereinbarung darüber, wie ein „veröffentlichungsreifes“ Produkt aussieht. Eine Version zu aktualisieren, auf GitHub hochzuladen und bereitzustellen, bedeutet noch lange nicht, dass das Projekt „fertig“ ist.
Es gibt eine ganze Reihe von Punkten, die überprüft werden müssen, bevor ein Versions-Upgrade als abgeschlossen betrachtet werden kann. Nehmen wir zum Beispiel an, ein Projekt nutzt verschiedene APIs, doch nach der Versionsänderung funktionieren diese APIs nicht mehr. Was bedeutet das? Es bedeutet, dass jede Funktion und jede Integration durchgehen und testen muss, um sicherzustellen, dass alles weiterhin funktioniert.
Alle Builds müssen erfolgreich abgeschlossen werden. Sie haben richtig gehört: ALLE Builds müssen jede Umgebung erfolgreich durchlaufen. Wenn ein Build fehlschlägt, weil sich das Upgrade anders verhält als die Version, die es ersetzt hat, muss der Prozess gestoppt werden, da keine weiteren Tests durchgeführt werden können, bis wieder „grün“ angezeigt wird.
Änderungen an der Funktionalität erfordern einen erheblichen Aufwand für Regressionstests. Jede funktionale und nicht-funktionale Funktion muss getestet werden, um sicherzustellen, dass die aktualisierte Version keine Fehler verursacht hat. Und je tiefer der Abhängigkeitsbaum reicht, desto länger dauern die Regressionstests.
Schließlich muss noch die Freigabe durch die Entwickler erfolgen. Manchmal müssen sie von ihrer aktuellen Arbeit abgezogen werden, um die Änderungen zu überprüfen. Dies ist ein versteckter Kostenfaktor des gesamten Prozesses: Wenn etwas voreilig als „fertig“ bezeichnet wird, gerät die Geschwindigkeit des gesamten Projekts aus dem Takt.
Nichts tun
Sich zurückzulehnen und nichts zu tun, ist in der Regel ein kostspieliger Fehler. Wir können das Problem zwar immer unter den Teppich kehren, doch damit erweisen wir nicht nur dem Produkt, sondern auch unseren Nutzern und jedem anderen Produkt, das auf dieser Software basiert – unabhängig davon, ob es sich um ein EOL-Produkt handelt oder nicht –, einen Bärendienst.
Ständig werden neue CVEs (Common Vulnerabilities and Exposures) veröffentlicht, und einige davon betreffen zwangsläufig genau das Paket, auf das Sie angewiesen sind. Sobald Sicherheitsscanner diese Probleme erkennen, wird die Liste immer länger. Auch wenn die Betreuer sich vielleicht zurückgezogen haben, läuft die Software weiter. Genau hier kommt ein Schutzschild zum Tragen, das Ihre Software von Anfang bis Ende umgibt.
Eine Rüstungskuppel
Das Beste an Open-Source-Software ist das Engagement und die Leidenschaft der Community, die dafür sorgt, dass Pakete auch dann weiter funktionieren, wenn neue Sicherheitslücken entdeckt werden. Wir verdanken nicht nur den Anbietern, sondern auch der Community hinter diesen Projekten sehr viel. Wäre es nicht besser, die gesamte Lieferkette abzusichern, bevor ein Paket überhaupt das Ende seines Lebenszyklus (EOL) erreicht?
Schritt für Schritt SecureChain. Nehmen wir Angular 20 als Beispiel. Angular 22 ist die aktuell aktiv unterstützte Version, während Angular 20 in die LTS-Phase übergegangen ist und Ende 2026 jeglichen offiziellen Support verlieren wird. Das macht es genau zu der Art von Version, bei der es sich lohnt, vorzuarbeiten: Sie ist bei vielen Teams noch im Einsatz, wird heute noch unterstützt, hat aber ein bekanntes Ablaufdatum am Horizont.
Wir können nun Schutzmaßnahmen ergreifen – eine Art Schutzschild um v20 – noch bevor das Produkt das Ende seiner Lebensdauer (EOL) erreicht, solange es noch Patches aus dem Upstream erhält. Der Vorteil einer Absicherung der Software vor Erreichen des EOL besteht darin, dass das Paket aus dem Quellcode neu kompiliert, auf Malware überprüft, kontinuierlich gepatcht und konform gehalten werden kann. Die Kontrolle liegt wieder bei den Entwicklern und Sicherheitsteams, die die Software nach ihren eigenen Vorgaben warten können.
Dieser Ansatz spart Zeit und Geld und hält gleichzeitig die technische Verschuldung in Schach. Neue CVEs tauchen schneller denn je auf, was zum Teil daran liegt, dass KI-basierte Programmierwerkzeuge sowohl die Entdeckung als auch die versehentliche Einführung von Schwachstellen beschleunigen – was zu mehr Angriffen über die Lieferkette führt. Ein Ansatz, der den gesamten Lebenszyklus abdeckt – Sicherheit für jedes Paket über den gesamten Stack hinweg –, ermöglicht es Ihnen, all dem mit dem „Supply Chain Dome of Armor“ einen Schritt voraus zu sein.
Einpacken
Die Realität der modernen Softwareentwicklung sieht so aus, dass Open-Source-Abhängigkeiten für Ihr Unternehmen nicht an Bedeutung verlieren, nur weil ihre Upstream-Betreuer das Projekt verlassen haben. EOL-Pakete ungepatcht zu lassen, ist keine neutrale Entscheidung; es ist eine bewusste Entscheidung, mit jedem neuen, unbehandelten CVE-Eintrag ein wachsendes Risiko in Kauf zu nehmen.
Die gute Nachricht ist, dass erzwungene Upgrades und aufwendige Neuprogrammierungen nicht mehr die einzigen Alternativen sind. Durch das Backporting von Sicherheitspatches auf die Versionen, die Sie bereits einsetzen, kann Ihr Team weiterhin geschützt bleiben, ohne dass Ihre Roadmap oder Ihre „Definition of Done“ durcheinandergerät. Sicherheitsschutz sollte kein Verfallsdatum haben – und mit der richtigen Patching-Strategie muss das auch nicht der Fall sein.
Entdecken Sie die Abdeckung des gesamten Lebenszyklus durch SecureChain →
