TrustSource ergänzt EoL-Information
EoL bezeichnet den Zeitpunkt, ab dem ein Softwareprodukt oder eine Komponente vom Hersteller nicht mehr gepflegt wird. Keine Sicherheitsupdates. Keine Bugfixes. Kein Support. Wer EoL-Software einsetzt, betreibt de facto ein offenes Scheunentor – und das vollkommen legal, aber höchst riskant.
Das hat mehrere Implikationen:
- Sicherheit: Bekannte Schwachstellen bleiben dauerhaft ungepatcht. Jede neue CVE-Meldung kann zum existenziellen Risiko werden – ohne Gegenmittel.
- Betrieb: EoL-Komponenten verlieren die Kompatibilität mit modernen Systemen, Bibliotheken und Schnittstellen. Was heute noch funktioniert, kann morgen kritische Prozesse lahmlegen.
- Compliance:
Mit dem Cyber Resilience Act (CRA) der EU, der 2024 in Kraft getreten ist und dessen Pflichten bis 2027 schrittweise greifen, wird EoL zur regulatorischen Kernfrage.
Der CRA verpflichtet Hersteller digitaler Produkte zu:
-
Transparenz über Supportzeiträume – vor dem Kauf, verständlich kommuniziert
-
Mindest-Support von fünf Jahren (oder der erwarteten Produktlebensdauer)
-
Kostenlose Sicherheitsupdates während der gesamten Supportperiode
-
Klare Abkündigungsprozesse mit ausreichend Vorlaufzeit und Migrationspfaden
Das ist ein Paradigmenwechsel: EoL ist keine interne Produktentscheidung mehr, sondern eine regulierte Verpflichtung mit Rechtsfolgen. Hersteller, die zu kurze Support-Zeiträume deklarieren, müssen diese gegenüber Marktaufsichtsbehörden rechtfertigen.
Wollen Sie wissen, welche Auswirkungen der CRA auf Ihren Software-Entwicklungsprozess haben wird? Nutzen Sie unsere kostenlose Impact-Analyse!
Moderne IT-Landschaften umfassen Tausende von Softwarekomponenten. Da dies kein Mensch mehr manuell managemenn kann oder will, entwickeln sich derzeit zwei Ansätze, um die Sache maschinenlesbaren abzubilden:
- EoX (Cisco/OASIS): Ein strukturiertes Datenmodell mit definierten Meilensteinen – von End of Sale über End of Security Support bis End of Service Life. Automatisierte Asset-Management-Systeme lesen diese Daten und können proaktiv warnen.
- CycloneDX (OWASP): Der Standard für Software Bills of Materials (SBOMs) bildet Lifecycle-Phasen strukturiert ab: von aktiver Entwicklung bis EoL. Wenn ein Bibliotheks-Maintainer EoL im SBOM deklariert, erben alle nachgelagerten Nutzer automatisch diese Information.
EoL betrifft nicht nur Betriebssysteme – es betrifft Open-Source-Bibliotheken, Frameworks, Middleware, Container-Images und kommerzielle Komponenten gleichermaßen. In einem durchschnittlichen Unternehmens-Portfolio laufen mehr EoL-Komponenten, als die meisten IT-Teams ahnen.
Um dies zu adressieren, sollte jedes Führungsgremium die folgenden Fragen an die Entwicklung stellen:
-
Haben wir EoL-Komponenten im Einsatz?
-
Welche erreichen in den nächsten 6–12 Monaten ihr EoL?
-
TrustSource hat EoL-Monitoring in seine Software-Supply-Chain-Security-Plattform integriert.
Die Plattform aggregiert teils automatisiert, teils manuell ergänzt, EoL-Daten aus verschiedenen Quellen – für Komponenten und Distributionen gleichermaßen – und stellt diese direkt im Kontext der Projekte zur Verfügung. Das bedeutet konkret:
- Policy-basierte Alerts: Jedes Projekt in TrustSource kann individuelle Richtlinien definieren – etwa eine Warnung 9 Monate vor EoL und eine Verletzungsmeldung 2 Monate vor EoL. So erreichen Warnungen die Verantwortlichen, bevor das Fenster zum Handeln schließt.
- Portfolio-Reports für die Führungsebene: CISOs und zentrale Sicherheitsverantwortliche können mit einem einzigen Report das gesamte Portfolio oder einzelne Projekte auf EoL-Risiken screenen. Transparenz auf Knopfdruck – für fundierte Entscheidungen und Compliance-Nachweise.
- Downstream-API:
Der Cyber Resilience Act macht EoL zur Chefsache. Maschinenlesbare Standards erlauben es, die Herausforderung zu beherrschen. Und Plattformen wie TrustSource operationalisieren diese Informationen – automatisiert, kontinuierlich, skalierbar.
Die Frage ist nicht ob EoL-Risiken in Ihrem Portfolio schlummern. Die Frage ist:
Möchten Sie wissen, wie Sie die EOL-Informationen optimal in ihren Prozess integrieren?
ts-scan nun auch als Github Action im Github Marketplace verfügbar
Optimieren Sie die Sicherheit Ihrer Lieferkette: TrustSource ts-scan jetzt als GitHub Action verfügbar
Wir freuen uns, Ihnen mitteilen zu können, dass das leistungsstarke Software Composition Analysis (SCA)-Tool von TrustSource, ts-scan, jetzt direkt im GitHub Marketplace verfügbar ist. Die Integration robuster Sicherheitsscans und Compliance in Ihre CI/CD-Pipeline war noch nie so einfach.
Mit der neuen ts-scan-action können Entwickler Software-Stücklisten (SBOMs) in Standardformaten – einschließlich SPDX und CycloneDX – direkt in ihren Workflows und direkt aus dem GitHub Marketplace heraus automatisch generieren.
Entscheidend ist, dass ts-scan auf Einfachheit und Datenschutz ausgelegt ist. Es arbeitet vollständig lokal, d. h. für die grundlegenden Aktionen sind keine API-Schlüssel erforderlich und während des Scanvorgangs verlassen keine Daten Ihre Umgebung, sofern Sie nicht die zusätzlichen TrustSource-SaaS-Angebote wie Risikomanagement, automatisierte Rechtskonformität oder Genehmigungsabläufe nutzen möchten. (Weitere Informationen finden Sie unter https://www.trustsource.io )
Intelligentes Scannen ohne viel Konfiguration
Das Alleinstellungsmerkmal von ts-scan ist seine intelligente Ziel-Erkennung. Im Gegensatz zu vielen Tools, die eine mühsame Konfiguration zur Definition des zu scannenden Zieles erfordern, ist ts-scan in der Lage, fast alle Zieltypen automatisch zu scannen, ohne dass explizite Anweisungen erforderlich werden.
Unabhängig davon, ob Sie gängige Paketverwaltungssysteme, bestimmte Dateien, ganze Repositorys oder Docker-Images scannen möchten, ts-scan identifiziert die Struktur und führt die Analyse durch.
Sie überlegen noch? Einfach ausprobieren!
Steigern Sie noch heute die Transparenz und Sicherheit Ihres Projekts, indem Sie TrustSource in Ihre GitHub-Workflows integrieren.
- Holen Sie sich die GitHub-Aktion: Starten Sie sofort über den Marktplatz: https://github.com/trustsource/ts-scan-action
- Tiefgehende Informationen: Erfahren Sie mehr über die umfangreichen Funktionen des Tools in unserer Dokumentation: https://trustsource.github.io/ts-scan
- Entdecken Sie den Code: Sehen Sie sich das Kern-Tool-Repository auf GitHub an: https://github.com/trustsource/ts-scan
PostQuantumGefahr
DER STILLE STURM: WIE SIE DIE POST-QUANTUM-KRYPTOGRAPHIE-GEFAHR MEISTERN
In der digitalen Welt halten wir unsere „Verschlüsselung“ – die Algorithmen, die unsere Banküberweisungen, Staatsgeheimnisse und privaten Nachrichten sichern – oft für unüberwindbar. Jahrzehntelang war dies auch der Fall. Doch am Informatik-Horizont braut sich ein stiller Sturm zusammen: das Aufkommen von kryptoanalytisch relevanten Quantencomputern.
Die Quantenbedrohung: Das Unknackbare knacken
Aktuelle kryptografische Standards wie RSA und Elliptic Curve Cryptography (ECC) basieren auf mathematischen Problemen, deren Lösung für klassische Computer unmöglich ist (z. B. die Faktorisierung großer Primzahlen). Ein Quantencomputer, der die Prinzipien der Superposition und Verschränkung nutzt, kann Informationen auf eine Weise verarbeiten, die für klassische Maschinen unmöglich ist.
Insbesondere ermöglicht der Shor-Algorithmus einem ausreichend leistungsfähigen Quantencomputer, diese asymmetrischen „Schlösser” innerhalb von Minuten zu knacken. Daraus entsteht ein Risiko, das man mit der Bezeichnung „jetzt ernten, später entschlüsseln” beschreibt: Angreifer könnten heute verschlüsselte Daten erfassen, bzw. einsammeln und darauf warten, dass die Technologie ausgereift ist, um sie in Zukunft zu entschlüsseln.
Lehren aus der Geschichte: Die Qualen des Übergangs
Wir haben das schon einmal erlebt, allerdings noch nie mit so hohen Einsätzen. Historische Übergänge bieten jedoch eine warnende Lehre:
- DES zu AES: Als der Data Encryption Standard (DES) Ende der 90er Jahre geknackt wurde, dauerte die Umstellung auf den Advanced Encryption Standard (AES) fast ein Jahrzehnt.
- SHA-1-Abkündigung: Die Abkehr vom SHA-1-Hashing-Algorithmus (nachdem er als anfällig erkannt wurde) wurde durch „Zombie“-Systeme erschwert, die den unsicheren Standard noch jahrelang weiterverwendeten, was zu weit verbreiteten Schwachstellen führte.
- Der Y2K-Vergleich: Wie bei Y2K gibt es auch bei der PQC-Migration eine „Frist“, die durch den Fortschritt der Hardware vorgegeben ist. Im Gegensatz zu Y2K kennen wir jedoch nicht das genaue Datum, an dem die Uhr „12“ schlägt. Eine Näherung s.bspw. Quantum doom clock.
Die größte Herausforderung bei diesen historischen Veränderungen war nicht die neue Mathematik, sondern die Sichtbarkeit. Unternehmen wussten oft nicht, wo ihre Kryptografie „fest codiert” war, was Updates zu einem manuellen, fehleranfälligen Albtraum machte, bei dem man sich durch Legacy-Code und Hardware kämpfen musste.
Die Lösung: Kryptografische Agilität
Globale Sicherheitsexperten, Kryptografie-Wissenschaftler und inzwischen auch das US-Kriegsministerium in einem Memo an seine Führung im vergangenen November fordern einen pro-aktiven Ansatz: Kryptografische Agilität.
Krypto-Agilität ist die Fähigkeit eines Informationssystems, zwischen kryptografischen Algorithmen zu wechseln, ohne dass dafür erhebliche Änderungen an der Infrastruktur oder umfangreiche Code-Neuprogrammierungen erforderlich sind. Anstatt „angeschraubt“ zu sein, wird Sicherheit modular. Dieser Ansatz ist aus folgenden Gründen unerlässlich:
- Algorithmen entwickeln sich weiter: Da das NIST PQC standardisiert, müssen die ersten Versionen möglicherweise aktualisiert werden, wenn neue Schwachstellen entdeckt werden.
- Hybridisierung: Bei der Migration müssen während einer Übergangsphase häufig ältere und quantenresistente Algorithmen parallel ausgeführt werden.
- Zukunftssicherheit: Ein agiles System kann sich an die nächste Bedrohung anpassen, ohne dass ein mehrjähriger „Rip-and-Replace“-Zyklus erforderlich ist.
Um dies zu erreichen, müssen Unternehmen zunächst ein umfassendes Kryptografie-Inventar erstellen und dabei jede Instanz der Verschlüsselung in nationalen Sicherheitssystemen, Cloud-Assets und IoT-Geräten identifizieren.
„ Seien Sie der Zeit voraus. Sichern Sie noch heute Ihre digitale Zukunft
Machen Sie den nächsten Schritt mit TrustSource
Die Umstellung auf Post-Quantum-Kryptografie (PQC) muss keine Reise ins Ungewisse sein. TrustSource bietet die Tools und das Fachwissen, um sicherzustellen, dass Ihre Software Lösungen widerstandsfähig bleiben.
- TrustSource Cryptographic Discovery Services:
Wir helfen Ihnen dabei, Ihre aktuelle kryptografischen Algorithmen zu identifizieren, zu inventarisieren und zu bewerten, um einen Risiko-orientierten Weg zur Quantenresistenz zu entwerfen. - TrustSource SBOM-Bestands- und Compliance-Workflows:
Speichern Sie Ihre SBOMs im TrustSource-Bestand oder nutzen Sie die Genehmigungs-Workflows, um die Risiken vor der Veröffentlichung Ihrer Software zu verwalten. Dokumentieren Sie die Existenz und Verwendung von Kryptoalgorithmen auf der Grundlage unseres Komponenten-Know-hows, sei es für Exportkontrollen oder Ihre Krypto-Agility-Implementierungen. - TrustSource Crypto Reporting:
Profitieren Sie von der Portfolio-weiten Analyse der verwendeten Kryptoalgorithmen und definieren Sie Migrationsstrategien auf der Grundlage von Komponenten und Portfolio-Risiken. - TrustSource Crypto Policies:
Verwenden Sie Richtlinien, um die Implementierung und/oder Verwendung schwacher Algorithmen im gesamten Unternehmen direkt in beim Bau der Software zu verhindern.
Wollen Sie mehr zu dem Thema erfahren?
Wichtiges ts-scan update
ts-scan update v1.5.2
Auf Basis der Ereignisse rund um den Shai-Hulud-Wurmhaben wir die Grundkonfiguration von unserem SCA Scanner ts-scan angepasst. Er führt in der Standard-Konfiguration keine Skripten aus der <scripts> Sektion der package.json mehr aus. Stattdessen wird eine Warnung ausgegeben, dass eine ggf. unsichere Konfiguration vorliegt. Um die Skripten dennoch auszuführen, ist ab Version 1.5.2 dem Scan-Aufruf explizit der Parameter node:enableLifecycleScripts hinzuzufügen.
Wir empfehlen unseren Kunden und Benutzern, ts-scan auf die neueste Version – hier v1.5.2 – zu aktualisieren, um Ihre Umgebung besser vor böswilligen Aktivitäten zu schützen, die durch unerwünschte Skriptausführungen ausgelöst werden.
BITTE BEACHTEN SIE: Dies ist keine durch ts-scan verursachte Schwachstelle. Die Fähigkeit, beliebige Skripten in der package.json zu verankern und ausführen zu lassen, ist eine Eigenschaft der Node-Umgebung. Diese existiert bereits seit geraumer Zeit und wurde auch bereits vor Jahren als mögliche Sicherheitslücke thematisiert. Jedoch wurde bisher nichts dagegen unternommen.