CRA Preparations: What Software Manufacturers Must Do Before the Cyber Resilience Act Applies
CRA Preparations: Was Software-Hersteller noch tun müssen, bevor der CRA greift
Die Uhr tickt – Warum der CRA kein regulatorisches Hintergrundrauschen ist
Ich erlebe es regelmäßig in Gesprächen mit Sicherheitsverantwortlichen: Der Cyber Resilience Act wird erwähnt, genickt wird pflichtbewusst, und dann kehrt man zur Tagesordnung zurück. Das ist ein Fehler, den sich Softwarehersteller schlicht nicht leisten können.
Der CRA wurde im Oktober 2024 im Amtsblatt der EU veröffentlicht. Die Übergangsfristen sind definiert: Melde- und Überwachungspflichten gelten ab September 2026 - das sind jetzt noch D R E I Monate - die vollständigen Anforderungen ab Dezember 2027. Das klingt nach Spielraum. Ist es aber nicht — denn wer heute noch keine strukturierte Inventarisierung seiner Software-Komponenten betreibt, hat schlicht zu spät angefangen.
Die Bußgeldrahmen sprechen eine klare Sprache: bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes bei Verstößen gegen die wesentlichen Anforderungen. Bei wiederholtem Verstoß, kann es zum Marktausschluss führen. Zum Vergleich: Die DSGVO-Bußgelder, die Unternehmen jahrelang als abstrakte Bedrohung behandelten, haben sich inzwischen in der Realität materialisiert. Wer glaubt, der CRA verlaufe ähnlich folgenlos, sollte sich die Konsequenzen zweimal überlegen.
Was der CRA konkret fordert – Ein nüchterner Blick auf die Pflichten
Der CRA adressiert Hersteller von Products with Digital Elements, also im Wesentlichen jede Software und jedes hardwarenahe Produkt, das in vernetzten Umgebungen betrieben wird. Die Anforderungen lassen sich auf einige Kernpunkte verdichten:
- Security by Design: Sicherheit muss von Anfang an im Entwicklungsprozess verankert sein, nicht nachträglich aufgesetzt
- Schwachstellenmanagement: Hersteller müssen Schwachstellen über den gesamten Produktlebenszyklus aktiv identifizieren und beheben
- Sichere Standardkonfigurationen: Produkte dürfen nicht mit unsicheren Werkseinstellungen ausgeliefert werden
- Transparenzpflichten: Gegenüber Behörden und Nutzern müssen Sicherheitseigenschaften nachvollziehbar dokumentiert werden
Die SBOM — Software Bill of Materials — ist im CRA-Text nicht explizit vorgeschrieben. In der Praxis ist diese Unterscheidung jedoch akademisch. Ohne maschinenlesbare Komponentenliste lässt sich kein glaubwürdiger Nachweis führen, dass man tatsächlich weiß, was im eigenen Produkt steckt.
Wer sich noch nicht sicher ist, wo das eigene Unternehmen in Bezug auf CRA-Compliance steht, kann sich mit dem kostenlosen Tool unter cra-support.eacg.de durch einen strukturierten Fragebogen führen lassen. Die Firmen EACG und metaeffekt haben dort ihre Best Practices aus der MetaTrust-Methode in eine frei zugängliche Online-Lösung überführt — das Ergebnis ist eine priorisierte Aufgabenliste, die konkrete nächste Schritte liefert.
SBOM als Fundament – Warum ohne Komponententransparenz nichts geht
Eine vollständige, maschinenlesbare SBOM ist nicht Mittel zum Zweck — sie ist die Grundvoraussetzung dafür, überhaupt handlungsfähig zu sein. Wer nicht weiß, welche Open-Source-Bibliotheken, Transitivabhängigkeiten und Lizenzmodelle in seinen Produkten stecken, kann weder Schwachstellen systematisch adressieren noch behördliche Nachweispflichten erfüllen.
Bei der Formatfrage steht die Branche vor einer strategischen Entscheidung: CycloneDX oder SPDX? Beide Formate sind etabliert, beide werden von gängigen Tools unterstützt. Im CRA-Kontext hat CycloneDX jedoch einen pragmatischen Vorteil: Es wurde explizit für Security-Anwendungsfälle entwickelt, unterstützt VEX-Dokumente nativ und bildet Schwachstelleninformationen strukturierter ab. SPDX hingegen dominiert traditionell den Lizenz-Compliance-Bereich und ist als ISO-Standard (ISO 5962) formal breiter anerkannt. Die Entscheidung hängt vom primären Verwendungszweck ab — für Organisationen, die beides brauchen, bieten reife Plattformen heute Konvertierung zwischen den Formaten an.
Entscheidend ist aber ein anderer Punkt: Die SBOM darf kein einmaliges Audit-Artefakt sein. Sie muss kontinuierlich im CI/CD-Prozess generiert werden. Jeder Build, jede Abhängigkeitsänderung, jedes neue Release — der SBOM-Stand muss aktuell sein. Wer das als nachgelagerten Schritt behandelt, produziert Dokumente, die im Ernstfall nicht die Realität abbilden.
Software Composition Analysis – Schwachstellen finden, bevor andere es tun
SCA-Tools scannen Abhängigkeiten gegen bekannte Schwachstellendatenbanken — NVD, OSV, GitHub Advisory Database. Das ist unter dem CRA keine optionale Hygienemaßnahme mehr, sondern regulatorische Pflicht. Die Herausforderung liegt dabei weniger in der Technologie als in der Handhabbarkeit der Ergebnisse.
Wer schon einmal einen rohen CVE-Report eines größeren Projekts gesehen hat, weiß: Die Liste ist lang, und viele der gemeldeten Schwachstellen betreffen Code, der im konkreten Produktkontext gar nicht erreichbar ist. Ohne Reachability-Analyse überlasten solche Berichte Sicherheitsteams mit False Positives und lähmen die Priorisierung. Moderne SCA-Werkzeuge, die kontextsensitiv analysieren — also tatsächlich prüfen, ob verwundbare Codesegmente im Aufrufpfad liegen — reduzieren dieses Rauschen erheblich.
Noch wichtiger als die Erkennung ist aber der Prozess dahinter: SCA-Ergebnisse müssen in ein nachvollziehbares Risikomanagement münden. Ein Remediation-Prozess mit klarem Audit-Trail ist nicht nur für interne Steuerung relevant — er ist der Nachweis gegenüber Behörden, dass Schwachstellen systematisch und nicht ad hoc bearbeitet werden.
Vulnerability Disclosure und Meldepflichten – Der CRA schreibt Tempo vor
Hier wird es für viele Organisationen unbequem. Aktiv ausgenutzte Schwachstellen müssen innerhalb von 24 Stunden an ENISA gemeldet werden. Nicht 48 Stunden, nicht "zeitnah" — 24 Stunden. Ein solches Zeitfenster ist ohne automatisierte Monitoring-Infrastruktur schlicht nicht einzuhalten, wenn gleichzeitig noch Einschätzung, Klassifizierung und interne Eskalation stattfinden müssen.
Das bedeutet: Hersteller brauchen heute definierte Coordinated Vulnerability Disclosure (CVD)-Prozesse, die sowohl CRA-Anforderungen als auch bestehenden Standards wie ISO/IEC 29147 genügen. Das ist keine Frage von Werkzeugen allein — es ist eine organisatorische Frage, die Rollen, Eskalationspfade und Kommunikationskanäle klärt. Das Carnegie Mellon CERT hat entsprechende Best Practises im “Vultron”-Protokoll definiert. EACG hat diese in TrustSource implementiert.
VEX-Dokumente (Vulnerability Exploitability eXchange) sollen dabei die Kommunikation gegenüber Kunden und Behörden standardisieren: Ist eine bekannte Schwachstelle im eigenen Produkt tatsächlich ausnutzbar? Unter welchen Bedingungen? Wann ist ein Fix verfügbar? In der Theorie ist das ein elegantes Instrument. In der gelebten Praxis klaffen Anspruch und Realität noch weit auseinander — zu wenige Hersteller erstellen VEX-Dokumente systematisch, zu wenige Abnehmer wissen damit umzugehen. Für die Verteilung ist der Betrieb eines CSAF-Providers, der vom BSI-Lister erfasst wird, eine ideale Voraussetzung.
License Compliance im CRA-Kontext – Der unterschätzte Risikofaktor
Neben den Sicherheitsanforderungen lauert ein zweiter Risikofaktor, den Compliance-Teams häufig unterschätzen: Open-Source-Lizenzen. GPL, LGPL, AGPL — diese Lizenzen können bei kommerziellen Produkten Pflichten auslösen, die über den CRA hinausgehen. Eine AGPL-lizenzierte Komponente in einem SaaS-Produkt kann etwa Copyleft-Pflichten auslösen, die den gesamten Quellcode betreffen. Das ist kein theoretisches Szenario — es ist ein reales Risiko, das bei fehlender Inventarisierung unbemerkt in Produkte einzieht.
Automatisierte Lizenzerkennung und Policy-Enforcement im Build-Prozess sind hier der einzig praktikable Ansatz. Manuelle Audits skalieren nicht, wenn Abhängigkeitsbäume hunderte von Komponenten umfassen.
Der strategische Vorteil: SBOM-Daten dienen gleichzeitig als Basis für License-Audits. Ein Artefakt, zwei regulatorische Zwecke. Wer seine SBOM-Infrastruktur einmal sauber aufgebaut hat, vermeidet Doppelarbeit zwischen Sicherheits- und Rechtsabteilung.
Handlungsempfehlungen – Was Teams jetzt konkret tun können
Die verbleibende Zeit bis September 2026 klingt nach ausreichend Puffer. Sie ist es nicht, wenn man die Vorlaufzeiten für Prozessänderungen, Tool-Implementierungen und organisatorische Anpassungen realistisch einkalkuliert. Meine Empfehlung für Sofortmaßnahmen:
- SBOM-Generierung anstoßen: Für alle aktiven Produkte, automatisiert im CI/CD, heute — nicht nach dem nächsten Planungszyklus
- SCA in bestehende Pipelines integrieren: Mit Priorisierungslogik, nicht als rohe CVE-Dump-Lösung
- Meldeprozesse für Schwachstellen definieren: Klare Rollen, definierte Eskalationspfade, Zeitfenster eingeübt
- Lizenzchecks automatisieren: Policy-Regeln im Build-Prozess verankern, nicht als nachgelagerten Audit
Wer diese Prozesse nicht mit vielen, separaten Werkzeugen koordinieren möchte, findet in Plattformen wie TrustSource einen integrierten Ansatz für SBOM-Management, Software Composition Analysis und License Compliance. Das reduziert nicht nur Werkzeugkomplexität, sondern schafft auch die Datengrundlage für konsistente Nachweise gegenüber Behörden.
Der CRA ist kein Endpunkt regulatorischer Anforderungen — er ist deren Ausgangslage. Organisationen, die jetzt in eine belastbare Supply-Chain-Security-Infrastruktur investieren, bauen etwas auf, das auch künftige Anforderungen trägt. Wer wartet, kauft sich nur Zeit — und zahlt sie teuer.
Zur Person
Freier Tech-Journalist, promovierter Wirtschaftsinformatiker. Recherchiert zu Software Supply Chain Security und SBOM-Adoption.
Gastbeitrag. Dr. Brenner ist freier Journalist. Keine Vergütung für diesen Beitrag.
Why Every Software Team Needs an SBOM Strategy in 2026
Warum jedes Software-Team ab 2026 eine SBOM-Strategie braucht
Der Moment, der alles verändert hat
Es war ein Dienstagmorgen im April 2024. Eine Mail vom Risikomanagement landet in meinem Postfach: „Stefan, seid ihr von der XZ-Utils-Backdoor betroffen? Wir brauchen bis heute Mittag eine Antwort."
Ich kenne Kollegen aus anderen Unternehmen, die in diesem Moment schweißgebadet vor ihren Laptops saßen und händisch durch ihre Repo-Landschaft gegraben haben. Bei uns: ein einziger Bericht in TrustSource, Filterung auf das betroffene Package, Abgleich gegen unsere SBOM-Snapshots – keine drei Minuten, und ich hatte eine vollständige Antwort für alle 120 aktiven Produkte.
Das ist der Unterschied zwischen SBOM als lebendigem Betriebsmittel und dem klassischen „wir haben da irgendwo eine Inventarliste als Excel". Als XZ einschlug, waren CRA und NIS2 für viele noch abstrakte Brüsseler Konzepte. Heute sind sie Realität. Und wer kein strukturiertes SBOM-Management hat, hat ab 2026 nicht nur ein Compliance-Problem - er hat ein operatives Problem.
Der Paradigmenwechsel, den wir in unserem OSPO durchgemacht haben: SBOM ist kein PDF für den Auditor. Es ist das Nervensystem unserer Supply-Chain-Hygiene.
Was die Regulierung konkret verlangt - und was sie nicht sagt
Der Cyber Resilience Act macht maschinenlesbare SBOMs für alle „Products with Digital Elements" zur Pflicht - und zwar ab Markteintritt, nicht erst wenn der Auditor anklopft. Das ist ein fundamentaler Unterschied zu dem, was viele noch erwarten. Es geht nicht um eine einmalige Dokumentationsübung, sondern um einen kontinuierlichen Nachweis.
NIS2 erhöht den Druck auf kritische Lieferketten nochmals: Betroffene Organisationen müssen nachweisen können, welche Komponenten sie einsetzen und wie deren aktueller Vulnerability-Status aussieht. Ohne SBOM ist das schlicht nicht skalierbar.
Eine gute, erste Orientierung gibt die BSI TR-03183, die konkret definiert, was in einer SBOM stehen sollte: von SPDXID und Lizenzinformationen bis hin zu Relationship-Typen zwischen Komponenten. Praktisch hilfreich – aber in unserem Setup ist das längst automatisiert. TrustSource erzeugt SBOMs, die diese Anforderungen out-of-the-box erfüllen. Kein manueller Nachbau erforderlich.
SBOM-Inhalte nach BSI TR-03183 – was wirklich drinsteht
Die Pflichtfelder laut TR-03183 Tier 1 und 2 klingen zunächst überschaubar: Package Name, Version, Supplier, Unique Identifier (PURL oder CPE), Declared License, Copyright. Trivial? In der Praxis fehlen bei Legacy-Komponenten regelmäßig 30 bis 40 Prozent dieser Felder – das sehe ich in jedem SBOM-Audit, den wir bei Neuprojekten durchführen.
Deshalb haben wir ein hartes Quality-Gate eingeführt: Kein Merge ohne grünes Häkchen in TrustSource. Die Pipeline prüft automatisch, ob alle TR-03183-relevanten Felder befüllt sind. Was früher eine manuelle Compliance-Prüfung war, die Wochen gedauert hat, ist heute ein automatisierter Check, der Sekunden braucht.
Das SBOM als lebendiges Betriebsmittel – nicht als Momentaufnahme
Das größte Missverständnis, das ich immer noch höre: „Wir machen das einmal pro Release." Das ist ungefähr so hilfreich wie ein Feuerlöscher, den man am Eingang eines großen Gebäudes positioniert.
In unserem Setup erzeugt jeder CI/CD-Build einen neuen SBOM-Snapshot, der automatisch in TrustSource abgelegt wird. Das hat zwei unmittelbare Vorteile:
Erstens erkennen wir Komponentendrifts sofort. TrustSource schlägt sogar Alarm bei unerwarteten Version-Jumps – genau das Muster, das bei Dependency-Confusion-Attacks auftritt. Dieser Angriffsvektor ist subtil und ohne automatisierte SBOM-Überwachung kaum zu entdecken.
Zweitens ist die Vulnerability-Korrelation in Echtzeit möglich. Neue CVEs werden automatisch gegen unsere SBOM-Daten geprüft. Bei Log4Shell hatten wir innerhalb von 5 Minuten eine vollständige Betroffenheitsliste – für alle 120 Produkte gleichzeitig. Exakt klar, ab bzw. Bis zu welcher Version Produkte betroffen waren. Kein manuelles Durchsuchen, kein Raten.
Ein weiterer Effekt, den ich anfangs unterschätzt habe: Wir liefern unseren OEM-Kunden heute maschinenlesbare CycloneDX-Files on-demand. Was als Compliance-Overhead begann, ist inzwischen ein echtes Verkaufsargument geworden. Kunden aus dem Automotive- und Industrieumfeld fragen aktiv danach.
Supply-Chain-Risiko greifbar machen – Zahlen aus unserem Setup
Nach drei Jahren produktivem Einsatz von TrustSource haben wir belastbare Daten. Ein paar Zahlen, die ich regelmäßig im Management-Reporting verwende:
- 68 % unserer Komponenten sind transitiv. Wer nur die direkten Dependencies kennt, ist blind für den größten Angriffsvektor. Ohne vollständigen Dependency-Graph ist Supply-Chain-Security eine Illusion.
- Lizenz-Compliance-Findings sind um über 80 % gesunken, seit wir Policy-as-Code im SBOM-Workflow betreiben. Entwickler bekommen das Feedback direkt in der Pipeline – nicht sechs Wochen später im Legal-Review.
- Time-to-Detect bei kritischen Findings (CVSS ≥ 9.0 mit bekanntem Exploit) ist von durchschnittlich 12 Tagen auf unter 4 Stunden gesunken. Das ist der Unterschied zwischen einem kontrollierten Incident-Response-Prozess und einer Krisennacht.
Häufige Stolpersteine beim SBOM-Aufbau – und wie wir sie gelöst haben
„Wir haben zu viele Repos." Das höre ich oft als Argument, warum der Start zu komplex sei. Meine Antwort: Fang nicht mit dem gesamten Portfolio an. SBOM-Abdeckung von 20 % der richtigen Assets – also produktionskritische Services, alles was nach außen exponiert ist – bringt mehr als 100 % Coverage auf internen Testprojekten.
Tool-Fragmentierung ist ein echtes Problem. Unterschiedliche Scanner erzeugen inkonsistente PURLs, und wenn du SBOMs aus drei verschiedenen Tools konsolidieren willst, hast du schnell Chaos. Normalisierung ist Pflicht, bevor du anfängst zu aggregieren. TrustSource übernimmt das automatisch – wer es ohne Plattform lösen will, kann auch ts-scan auf GitHub als Open-Source-Basis nutzen.
Organisatorischer Widerstand ist ein oft unterschätzter Stolperstein. Der klassische Fehler: Das SBOM-Thema ins Compliance-Team schieben und hoffen, dass es von dort aus skaliert. Bei uns hat es erst funktioniert, als wir das Thema ins Security-Champion-Programm integriert haben. Wenn Entwickler sehen, dass sie dank SBOM eine Vulnerability-Triage in Minuten statt Tagen durchführen können, braucht es keine Überzeugungsarbeit mehr.
Fazit & nächste Schritte: Dein SBOM-Fahrplan für 2026
Drei Maßnahmen, die ich jedem Team empfehle – und die sich alle drei in einem einzigen Sprint umsetzen lassen:
- BSI TR-03183 als Qualitätsmaßstab adoptieren. Nicht als bürokratische Pflichtübung, sondern als konkretes Qualitätskriterium für jede erzeugte SBOM.
- SBOM-Erzeugung in jede CI/CD-Pipeline integrieren. Jeder Build, jeder Snapshot, automatisch abgelegt. Keine Ausnahmen.
- Vulnerability-Matching automatisieren. Manuelles CVE-Tracking ist 2026 keine Option mehr.
2026 wird das Jahr, in dem Kunden und Behörden SBOMs nicht mehr nett finden, sondern aktiv einfordern – als Vertragsbestandteil, als Lieferbedingung, als regulatorischen Nachweis. Wer jetzt in seine SBOM-Infrastruktur investiert, liefert dann auf Knopfdruck. Wer wartet, wird unter Zeitdruck nachrüsten müssen.
Der beste Zeitpunkt, mit einer SBOM-Strategie anzufangen, war vor zwei Jahren. Der zweitbeste ist jetzt.
Wenn du deinen eigenen SBOM-Reifegrad einschätzen willst, ohne monatelange Evaluierung: Eine TrustSource-Demo dauert 30 Minuten und zeigt dir konkret, wo du stehst und was der nächste realistische Schritt ist. Genau das hätte ich mir gewünscht, bevor ich selbst angefangen habe.
Anwender-Erfahrungsbericht. Endkunde von TrustSource. Nicht vergütet.
Architektur der Quantenresilienz
Vorausgeschaut: Die Architektur der Quantenresilienz
Kryptoanalytisch relevante Quantencomputer sind nur noch ein Frage der Zeit. Ob 2 oder 4 Jahre, ist noch unklar. Durch sie werden aber die Sicherheitsparadigmen von gestern schnell zu den Schwachstellen von morgen. Wahre Post-Quantum-Kryptografie (PQC) erfordert daher nicht nur den Wechsel eines Algorithmus, sondern eine strategische Verlagerung hin zu kryptografischer Agilität, sprich die Vorbereitung auf ein immer wieder anzunehmenden Austausch. Im Zentrum dieser Entwicklung steht die wichtigste – und doch oft übersehene – Grundlage: die umfassende Bestandsaufnahme.
Die Dokumentation Ihres kryptografischen Bestands
Um einen Perimeter zu verteidigen, müssen Sie ihn zunächst erfassen und kartografieren. Analog erfordert eine nachhaltige PQC-Umstellung ein zentrales Repository, das über einfache Tabellenkalkulationen hinausgeht. Dieses Inventar muss Folgendes sorgfältig dokumentieren:
- System-/Modulkategorisierung: Detaillierte Nachverfolgung von nationalen Sicherheitssystemen, Geschäftsanwendungen, Waffensystemen, Cloud-Umgebungen und IoT-/unbemannten Systemen.
- Kryptografische Metadaten: Identifizierung aller verwendeten Algorithmen, ihres Zwecks (Vertraulichkeit, Integrität oder Authentifizierung) und ihrer spezifischen Implementierung – sei es in Hardware, Mobilgeräten oder physischen Zugangskontrollen.
- Eigentumsverhältnisse und Governance: Identifizierung der Schlüsselpersonen und Komponentenleiter, die für die Migration, das Risikomanagement und die Koordination verantwortlich sind.
- Compliance-Artefakte: Pflege von Testplänen, Ergebnissen und Sicherheitsbewertungen, um sicherzustellen, dass jedes Engagement den strengen Standards des Bundes oder der Organisation entspricht.
Die Macht der Transparenz
Die Vorteile eines solchen Repositorys sind transformativ. Es bietet die strategische Transparenz, die erforderlich ist, um die Aufnahme zu optimieren und PQC-Lösungen dort zu priorisieren, wo das Risiko am höchsten ist. Durch die Identifizierung veralteter „Zombie“-Systeme – wie beispielsweise seit Jahrzehnten verwendete symmetrische Schlüsselprotokolle – können Unternehmen veraltete Technologien mit bewusster Dringlichkeit und ohne reaktive Panik auslaufen lassen, bzw. gezielt erneuern.
Integration von Risiken in den Prozess
Ein isoliertes Inventar ist statisch. Um echte Agilität zu erreichen, sollte Ihr kryptografisches Repository in Ihr Anwendungsrisikomanagement-Framework eingebunden sein. Nur diese Integration stellt sicher, dass eine Schwachstelle in einem bestimmten Algorithmus nicht nur ein Ticket auslöst, sondern eine automatisierte Bewertung der Auswirkungen auf das gesamte Ökosystem ihrer Lösung umfasst. So kann die Unternehmensleitung Risiken in Echtzeit bewerten und vor der Bereitstellung überprüfen, ob die Maßnahmen zur Risikominderung wirksam sind.
Der Vorteil von TrustSource
Um diese Komplexität zu bewältigen, benötigen Sie eine Lösung, die die Schnittstelle zwischen Sicherheit und Lieferkette versteht. TrustSource bietet eine einzigartige Integration von Risikomanagement und Software Supply Chain Security, deren Vorteile speziell im Kontext von Quantensicherheit zum Tragen kommen. Durch die Kombination von automatisierter Asset-Erkennung und der Überführung der Erkenntnisse in das Risiko-Management, stellt TrustSource sicher, dass Ihre Migration zu PQC nicht nur eine einzelne Compliance-Aufgabe ist, sondern eine nachhaltige Strategie in Sachen Resilienz darstellt.
Ist Ihr Bestand bereit für den Quantensprung?
Lesen Sie hier, wie TrustSource mit ts-scan die oben erwähnte Phase „Erkennung und Bestandsaufnahme” automatisieren kann!
Wollen Sie mehr zu dem Thema erfahren?
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?
Den nx-Hack meistern
So identifizieren Sie bösartige NX-Versionen in Ihrer Codebasis
Kürzlich ist es wieder passiert: Einige böswillige Akteure haben einen ausgeklügelten Supply-Chain-Angriff gestartet. Das nx-team und mehrere Sicherheitsforscher (1, 2) haben bereits über diesen Vorfall berichtet. Hier finden Sie eine kurze Zusammenfassung:
Was ist passiert?
nx ist ein Paket mit etwas mehr als 23 Millionen Downloads im NPM-Paketregister. Es umfasst mehrere Plugins, die Entwickler zur Vereinfachung von Code-Verwaltungsaktivitäten verwenden, wie z. B. einige Hilfsfunktionen zum Schreiben von Dateien, zum Aktualisieren der Konfiguration (devkit), zum Verwalten des Knotens selbst (node) oder zum Linitieren von JavaScript- und Typescript-Code (lint).
Die Versionen um 20.9.0 und 21.5.0 bzw. 3.2.0 (key & enterprise-cloud) wurden böswillig verändert. Sie führten eine KI-basierte Suche durch, bei der die lokalen Dateistrukturen des Arbeitsbereichs des Entwicklers ausgewertet und alle Arten von Geheimnissen zusammengetragen wurden. Diese wurden dann unter Verwendung der Git-Anmeldedaten des Entwicklers in einem öffentlichen Git-Repository veröffentlicht.
Was kann man dagegen tun?
Der allererste Schritt wäre, festzustellen, ob jemand in Ihrem Unternehmen die betroffenen nx-Tools verwendet. Wenn Sie TrustSource verwenden, müssen Sie lediglich den „Component Impact Report” öffnen und nach den betroffenen Komponenten in den angegebenen Versionen suchen, z. B. @nx/devkit in Version 21.5.0 oder 20.9.0. TrustSource listet Ihnen alle Projekte auf, in denen genau diese Komponentenversionen in der Liste der transitiven Abhängigkeiten enthalten sind.
Dies ist ein gutes Beispiel dafür, warum transitive Abhängigkeiten so wichtig sind. nx hat etwa 663 abhängige Projekte, oder anders ausgedrückt: Es gibt 663 andere Tools, die nx-Tools verwenden. Sie können sich vorstellen, wie schnell und weit sich die Verbreitung ausdehnen kann.
Wenn ein Projekt jedoch die betroffenen Versionen verwendet, müssen die Entwickler davon ausgehen, dass ihre gesamte CI/CD-Kette kompromittiert ist. Jeder Entwickler sollte überprüfen, ob er ein Repository mit „s1ngularity” im Namen hat, das in den letzten 2–3 Wochen veröffentlicht wurde. Alle Anmeldedaten, die Sie in diesem Repository finden, müssen als geleakt betrachtet werden.
Bevor Sie diese jedoch ersetzen, sollten Sie Ihren Arbeitsbereich bereinigen!
Weitere Informationen und Details zur Bereinigung Ihres Arbeitsbereichs finden Sie in diesem Artikel.
Was können wir daraus lernen?
Wir sind froh, dass wir dieses Tool nicht verwenden. Aber es gibt zwei interessante Erkenntnisse für uns:
a) Bislang haben wir uns sehr auf das Lieferartefakt konzentriert. Aus diesem Grund umfasst ts-scan beispielsweise standardmäßig keine Dev-Abhängigkeiten. Um Dev-Abhängigkeiten in Ihren Scan einzubeziehen, müssen Sie den Parameter npm:includeDevDependencieshinzufügen. Wenn Sie noch nie einen Scan mit diesen Parametern durchgeführt haben, ist es sehr wahrscheinlich, dass der oben genannte TrustSource-Komponenten-Auswirkungsbericht keine Ergebnisse anzeigt, obwohl die Tools möglicherweise von Ihren Entwicklern verwendet werden.
Dies ist wichtig zu verstehen und der Grund, warum wir empfehlen, alle Entwickler in Ihrem Unternehmen über die Situation zu informieren. Wir empfehlen sogar, Scans mit dem oben genannten Parameter anzufordern und den Bericht in den nächsten Tagen und Wochen erneut auszuführen. Einige der 663 Tools, die nx verwenden, nutzen es möglicherweise im Hintergrund, z. B. nx-python codegen, reactionary, goodiebag usw., sodass es für Ihre Entwickler möglicherweise nicht offensichtlich ist.
Wir empfehlen außerdem, die Scans, die die Entwicklungsabhängigkeiten enthalten, in ein separates Projekt/Modul zu verschieben. Angenommen, Sie haben Projekt A mit den Modulen A1 und A2, dann könnten die Scans mit den Entwicklungsabhängigkeiten auf Projekt A-DEV mit den Modulen A1 und A2 abzielen. Auf diese Weise könnten Sie alle Entwicklungsabhängigkeiten verfolgen, sie aber aus den üblichen Compliance-Abläufen heraushalten. Projekte, die kein PROJECTNAME-DEV bereitstellen, können einfach durch Sortieren der Projektliste in aufsteigender Reihenfolge identifiziert werden.
b) Oft sind Entwicklungsumgebungen offen und weniger sicher. Oft hört man den Spruch „Wer sollte in Betracht ziehen, dies zu brechen, und was könnte er dadurch erreichen?“ Aber hier sehen Sie, welche Auswirkungen dies haben kann. Angefangen bei der Verschlüsselung bis hin zur Offenlegung von Informationen und Anmeldedaten könnte die Arbeit jedes Entwicklers direkt beeinträchtigt werden. Indirekt kann dies zur Einführung von bösartigem Code führen, die Produkte des Entwicklers gefährden, den Ruf des Unternehmens des Entwicklers schädigen und das Geschäft seiner Kunden beeinträchtigen.
Während dies vor fünf Jahren noch unwahrscheinlich gewesen wäre, muss es heute als Realität berücksichtigt werden. Sie sollten Ihre Entwicklungsumgebungen entsprechend einrichten (interne Paket-Proxys, geschützte und klar dokumentierte Builds (SBOMs), strenger Schutz von CI/CD-Anmeldedaten, API-Schlüsseln und Verwendung von Schlüsselspeichern usw.). Führen Sie von Anfang an das richtige Risikomanagement ein: Was könnte schiefgehen, wenn unser Code bösartig/fehlerhaft/gehackt ist? Wie könnte das passieren? Welche Auswirkungen hätte dies auf die Vertraulichkeit/Verfügbarkeit oder Integrität der Daten/Geschäfte/Geschäftstätigkeiten unserer Kunden?
Wenn Sie Unterstützung bei der Beantwortung dieser Fragen benötigen, wenden Sie sich gerne an uns. Unsere Muttergesellschaft ist darauf spezialisiert, ihre Kunden bei der Beantwortung solcher Fragen zu unterstützen und Strategien zur Sicherung von CI/CD und den Entwicklungsergebnissen zu entwickeln. Weitere Informationen finden Sie hier.
Cyber Resilience Act veröffentlicht
EU Cyber Resilience Act veröffentlicht
Heute wurde der EU Cyber Resilience Act (CRA) veröffentlicht. Damit sind seine Gültigkeit und der Zeitplan festgeschrieben, da sich aus dem Veröffentlichungsdatum die entsprechenden Daten für die Umsetzung ergeben: Beginn der tatsächlichen Gültigkeit – also der Zeitpunkt, ab dem jeder Software-Hersteller oder Vertreter eines solchen, der in der EU eine Software auf den Markt bringt, sich konform verhalten muss – ist der 11. Dezember 2027.
Genauer: Die Regelungen, insbesondere Art. 13 sowie Anhang I und II, gelten für alle Produkte mit digitalen Elementen, die ab diesem Termin in der EU auf den Markt kommen. Für Produkte, die vor diesem Termin auf den Markt kommen oder gebracht wurden, gelten die Anforderungen, sobald sie nach dem Termin wesentliche Änderungen erfahren, s. Art. 69 II CRA. Die Berichtserfordernisse aus Art. 14 sind jedoch für alle Produkte bereits ab dem 11. September 2026 zu bedienen, unabhängig vom Termin des Markteintritts (Art. 69 III CRA).
Von jetzt an zählt die Übergangsfrist, bis zu der sich Software-Anbieter mit den neuen Anforderungen auseinandersetzen, bzw. diese umsetzen müssen. Die Umsetzung ist stellenweise nicht trivial und erfordert einiges an organisationalem Wandel, bspw. die Aufnahme ggf. noch nicht vorhandener Risikoanalysen und -bewertungen in den Release-Prozess, die Deklaration von Unterstützungszeiträumen oder den Aufbau geeigneter Schwachstellen-Management-Prozesse.
– soweit nicht anders dargestellt, beziehen sich im Folgenden alle Verweise auf den Text des CRA –
Sie wollen klären, welche Anforderungen der CRA an Ihre Organisation stellt?
Sprechen Sie unverbindlich mit unserem Experten!
Für wen ist der Cyber Resilience Act von Bedeutung?
Der CRA betrifft grundsätzlich alle, die ein Produkt mit digitalen Elementen, also einer Software-Unterstützung bereitstellen. Allerdings schränkt er seine Gültigkeit auch gegenüber bereits anderweitig regulierten Gruppen ein. So werden Produkte, die sich nur im Automotive-Bereich, im Marine- oder Aviation-Umfeld bewegen oder der Medical Device Regulation unterliegen, ausgenommen. Es ist jedoch anzunehmen, dass eine Dual-Use-Möglichkeit, also eine Nutzbarkeit in anderen, nicht regulierten Bereichen, die Gültigkeit auch wieder herstellen wird.
Rollen der Akteure
Weiterhin ist die Rolle des Handelnden relevant für die Beurteilung der Gültigkeit. Konzeptuell versucht die Regulierung den Nutznießer der wirtschaftlichen Transaktion in die Verantwortung zu nehmen, der innerhalb der EU das Geschäft abbildet. Was bedeutet das?
Im einfachen Fall stellt ein europäischer Anbieter ein Produkt mit digitalen Elemente her, welches in den regulierten Bereich (s.o.) fällt. Somit steht der Anbieter direkt in der Pflicht, die CRA-Anforderungen für sein Produkt zu erfüllen, beispielsweise ein Hersteller für Stereoanlagen oder Musikboxen, die Musik-Streaming unterstützen oder eine Werkzeugmaschine, welche per Fernüberwachung gewartete werden kann.
Sitzt der Hersteller des Produktes außerhalb der EU, gehen diese Pflichten an seinen Stellvertreter über, den „Inverkehrbringer“. Dies kann ein Händler, ein Partner oder ein Implementierungspartner sein, eben der nächste wirtschaftliche Nutznießer. Interessant ist, dass dieser auch für die Einhaltung der Pflichten bei der Herstellung bürgen muss. Das bringt eine komplett neues Haftungsregime für bspw. Lizenzverkäufer amerikanischer Software mit sich!
Open Source
Sobald Open Source ins Spiel kommt, wird die Kette etwas unklarer. Aber der CRA kennt und berücksichtigt das Open Source Konzept. Der eigentliche Urheber einer Open Source Lösung bleibt von den Anforderungen verschont. Nimmt ein Akteur jedoch eine Open Source Lösung und nutzt sie wirtschaftlich, sei es durch Support-Verträge, treffen ihn die Regelungen analog zu denen eines Anbieters. Beispielsweise ist eine SUSE im Sinne des CRA verantwortlich für die von ihr bereitgestellte Distribution.
Ausnahmen gibt es nur für sogenannte Stewards. Diese haben weniger scharfe Anforderungen zu erfüllen. Diese Rolle wurde für die sogenannten Foundations (Eclipse, Cloud native, etc.) geschaffen, da sie zwar eine Form des Inverkehrbringers darstellen, jedoch keine mit einem herkömmlichen Software-Anbieter vergleichbaren, wirtschaftlichen Vorteile aus der Bereitstellung und Verbreitung ziehen. Um als Steward zu gelten, ist eine Anerkennung erforderlich.
Was sind die wesentlichen Neuerungen?
Der leitende Gedanke hinter dem CRA ist die Verbesserung der Sicherheitslage für die Konsumenten von Software. Da heutzutage fast alles von und mit Software gesteuert wird, bzw. ausgestattet ist, sind Cyber-Angriffe fast überall möglich. Jede Komponente, die durch eine Internetverbindung, ein WLan oder auch eine Near-Field-Kommunikation wie ZigBee oder Bluetooth zählt zur potentiellen Angriffsoberfläche – neu-deutsch: Attack Surface- und ist daher mit Bedacht zu nutzen, bzw. bereitzustellen.
Der Anbieter einer Software im europäischen Markt hat daher zukünftig folgende Anforderungen zu erfüllen:
- Bereitstellen eines Software Bill of Materials (SBOM), s. Anhang I
- Regelmäßiges Durchführen einer Risikobetrachtung der Sicherheitsrisiken sowie deren Aufnahme in die Dokumentation, s Art. 13, III und IV
- Erstellen einer Konformitätserklärung, s. Art. 13 XII, bzw. Art. 28 I sowie Anhang IV
- Bereitstellen einer CE-Kennzeichnung, s. Art. 12 XII, bzw. Art. 30 I
- Definition einer zu erwartenden Lebensdauer des Produktes und die Bereitstellung kostenloser Sicherheits-Updates innerhalb dieses Zeitraumes, s. Art. 13 VIII ff
- Einfordern umfangreicher Meldepflichten (gem. Art. 14)
- Mitteilung aktiv ausgenutzter Schwachstellen innerhalb von 24h an die European Network and Information Security Agency (ENISA) über eine noch zu schaffende Meldeplattform (vermutlich analog der bereits im Telekom-Umfeld bestehenden Lösung)
- Ergänzend hierzu eine Präzisierung der Einschätzung sowie der Maßnahmen innerhalb von 72h
- Information der Nutzer des Produktes sowie die von diesen zu ergreifenden Maßnahmen, s. Art. 14 VIII.
Wie kann TrustSource helfen?
- Einheitliche Plattform für Software Analyse, Compliance & Release-Management
- Integriertes Risiko-Management
- Automatisiertes Schwachstellen-Management
- Durchgängige, CRA-konforme Dokumentation
- CSAF-konforme Meldungen
- Einheitlicher Schwachstellen-Meldeprozess
- Umsetzungsunterstützung
Was sind die Auswirkungen der Nicht-Einhaltung?
Jedes Gesetz ist zunächst nur die Deklaration einer Verhaltensvorgabe. Was ist jedoch die Folge, wenn man sich nicht der Vorgabe gemäß verhält? Welche Risiken drohen den Anbietern?
Mit Veröffentlichung werden die Mitgliedsstaaten beauftragt, eine Stelle zu benennen, die für die Aufsicht in dem jeweiligen Land verantwortlich ist. In Deutschland wird dies nach aller Voraussicht das BSI sein. Dieses wiederum kann dann im Verdachtsfall entsprechende Prüfungen durchführen, bzw. beauftragen. Werden dabei Missstände festgestellt, führt dies in der Regel zur Aufforderung der Nachbesserung, kann jedoch auch entsprechend sanktioniert werden. Der CRA sieht folgende, mögliche Sanktionen vor:
- Bei Verstoß gegen grundlegende Sicherheitsanforderungen (Anhang I) bis zu 15 Mil. EUR oder, bei Unternehmen, bis zu 2,5% des weltweiten Jahresumsatzes im vorangegangenen Geschäftsjahr. (s. Art. 64 II)
- Bei Verstoß gegen Pflichten, die der CRA auferlegt, bis zu 10 Mil. EUR oder – für Unternehmen – bis zu 2% des ww Umsatzes (Vorjahr) (s. Art. 64 III)
- Für unrichtige, unvollständige oder irreführende Meldungen gegenüber den Behörden, bis zu 5 Mil. EUR, bzw. 1% des Jahresumsatzes für Unternehmen (s. Art. 64 IV)
Darüber hinaus besteht die Möglichkeit, bei nachhaltiger Nicht-Konformität die Verbreitung des Produktes einzuschränken, bzw. es vom Markt zu nehmen, s. bspw. Art. 58 II.
Sie sind sich nicht sicher, was das für Ihre Organisation bedeutet?
Sprechen Sie unverbindlich mit einem unserer Experten!
TrustSource zeigt OpenSSF Scorcards an
Hier klicken, um das Bild zu vergrößern
In unserer Komponentendatenbank, in der wir Meta- und Clearing-Informationen zu Komponenten sammeln, haben wir die Open Source Security Foundation (OpenSSF) Scorecard ergänzt. Diese erlaubt es, den Sicherheitsstatus von Open-Source-Projekten zu erkennen. Der Score, der vom OpenSSF-Projekt der Linux Foundation im Jahr 2020 eingeführt wurde und derzeit regelmäßig für etwa 1 Million Open-Source-Projekte auf Github ausgewertet wird, ist ein aggregierter Wert, der die vom Open-Source-Projekt getroffenen Sicherheitsmaßnahmen widerspiegelt. Er kann als Anhaltspunkt dafür verwendet werden, wie sehr Sie den Sicherheitsbemühungen eines bestimmten Projekts vertrauen können, ohne es weiter zu evaluieren.
Was sagt die Scorecard aus?
Der Wert oder die Punktzahl der Scorecard ist das Ergebnis von sechzehn Prüfungen, die die Best Practise der sicheren Softwareentwicklung widerspiegeln. Sie umfassen die Bereiche Entwicklung, Tests, Wartung und Schwachstellen, aber auch Code- und Build-Management. Auf der Grundlage eines umfassenden Satzes Best Practises durchsuchen die Tests das Code-Repository nach Belegen dafür, dass die Praktiken vom Projekt aktiv angewendet werden.
Derzeit sind 18 Tests verfügbar, von denen 16 über die API zugänglich sind. Eine ausführliche Dokumentation der Tests ist hier zu finden. Jeder Test wird mit einer Punktzahl zwischen 0 und 10 bewertet, wobei 10 die bestmögliche Punktzahl darstellt. Die Testergebnis und einem Risiko gewichtet ergeben zusammen eine Gesamtpunktzahl.
In einigen Fällen, kann es sein, dass Tests aufgrund von Projekt-Setups nicht anwendbar sind. Beispielsweise könnte es sein, dass ein Projekt keine Pakete über Github bereitstellt. Dadurch wird der Test auf Pakete nicht anwendbar sein, da die aktuelle Implementierung noch keinen Mechanismus zur Überprüfung anderer Paketmanager bietet.
Wenn Sie jedoch eine Entscheidung treffen wollen, ob Sie eine bestimmte Komponente einsetzen wollen oder nicht, hilft Ihnen die Durchführung eines Scorecard-Tests – oder ein Blick auf die Komponente in unserer Datenbank – dabei, einen Eindruck zu bekommen, welchen Aufwand Sie in die Absicherung der Komponente investieren müssen. Je höher die Punktzahl, desto mehr Vertrauen können Sie in die Komponente setzen.
Was sagt die Scorecard NICHT aus?
Bitte verstehen Sie eine hohe Punktzahl aber nicht als Garantie für eine sichere Komponente! Auch eine niedrige Punktzahl deutet nicht unmittelbar auf eine schwache oder fehlerhafte Komponente hin! Es wäre schlicht falsch, anzunehmen, dass eine niedrige Punktzahl ein Hinweis auf eine anfällige Komponente ist! Derzeit sind die Tests noch nicht umfänglich und prüfen nur auf ein Set ihnen bekannter Sicherheitswerkzeuge. Auch werden nur die im Repository sichtbaren Informationen geprüft. Bleiben diese auf einem Entwickler- oder CI-System und finden nicht den Weg in das Git-Repository, tauchen sie auch nicht im Testergebnis auf!
Die Punktzahl gibt an, welche Schritte das Projekt unternimmt, um sicherzustellen, dass der von ihm bereitgestellte Code bewährten Praktiken folgt und daher mit hoher Wahrscheinlichkeit frei von Fehlern und Schwachstellen ist. Aber es ist eben keine Garantie! Wenn alles gut läuft, alle Tests 10 zurückgeben, kann es immer noch vorkommen, dass eine Schwachstelle in einer vorgelagerten Komponente auftritt, die für das Projekt selbst nicht einfach oder gar nicht zu beheben bzw. zu umgehen ist.
Verwenden Sie die Punktzahl als Indikator. Aber machen Sie die Entscheidung, ob Sie eine Komponente verwenden wollen oder nicht, primär von ihrer Funktionalität abhängig und nicht von der Punktzahl. Sie werden – vor allem in diesen frühen Tagen, in denen der Score noch nicht weit verbreitet ist – noch viele gute Projekte mit geringen Scores finden.
Was kommt als Nächstes?
Wir empfehlen, dies Scorecards als Indikator für eine Eignungsbeurteilung hinzuzuziehen, da sie einen Hinweis darauf geben, wie stark Sie sich auf Ihre vorgelagerten Komponenten verlassen können. Zudem lässt sich über eine historische Betrachtung der Veränderung des Scores eine Tendenz erkennen, die eine interesante Aussage über das Projekt und seine Einstellung zu den Best Practises erkennen lässt. Wir werden Anfang kommenden Jahres genügend Werte gesammelt haben, um diese „Tendenz“ auswerten zu können.
Da TrustSource alle KomponentenIhrer Lösung kennt, wird es nun auch möglich sein, mehr aus den einzelnen Scores in Bezug auf das Projekt zu machen. Ein einfacher Durchschnittswert wäre sinnlos. Aufgrund der Menge der Komponenten wäre ein Durchschnittswert irgendwo bei einer bedeutungslosen 5 zu erwarten. Aber wir experimentieren derzeit mit Quantilen oder Top-10- und Low-10-Durchschnitten sowie dem Verhältnis von Nicht-bewerteten Komponenten zu bewerteten Komponenten.
Außerdem werden wir einen Service anbieten, mit dem man seine eigenen Komponenten oder nicht geprüfte Open Source Repositories überprüfen kann, indem man – wie beim DeepScan einfach eine URL angibt oder auch die Scorecard auf nicht-Github-Projekte überträgt. Wenn wir erfolgreich sind, werden wir unsere Entwicklungen in OpenSSF einbringen.
Sie wollen mehr über SBOMs oder OpenSSF Coding Best Practises erfahren? Kontaktieren Sie uns!
Open Source Compliance im Kontext von CI/CD
In den letzte Jahren hat sich Continuous Integration und Deployment (CI/CD)- die ständige Integration von Änderungen, deren automatisiertes Testen und Ausbringen – als Best Practise etabliert. Die gesteigerte Qualität und die Produktivitätsverbesserungen, die sich hierdurch erzielen lassen, sind enorm und sollten daher von jedem Entwicklungsteam angestrebt werden. Gleichzeitig wächst jedoch auch die Herausforderung im Bereich Open Source eine solide Dokumentation und rechtliche Compliance herzustellen.
Durch das kontinuierlich neue Bauen von Lösungen kann sich auch kontinuierlich die Zusammensetzung der Lösung ändern. Da der Anteil an Dritt-Software (OpenSource-Komponenten) stetig zunimmt, wird mit dem neuen Bau auch die Wahrscheinlichkeit größer, dass sich die Zusammensetzung der automatisch hinzugezogenen Dritt-Software ändert. Das Upgrade der Komponente X von Version 1.5.7 auf 1.5.8 kann bereits neue Lizenzverpflichtungen auslösen.
Leider kann eine strikte Versionskontrolle alleine diese Problematik nicht auflösen, da immer wieder das Schließen von identifizierten Schwachstellen (Vulnerabilities) und anderen Fehlerbehebungen Versions-Upgrades in allen Ebenen erforderlich machen wird. Daher stellt sich die Frage, wie sich die Compliance (1) auch in diesem dynamischen Kontext sicherstellen lässt.
Branching-Konzept als Lösungsbaustein
Um diese Frage zu beantworten, ist es erforderlich, sich zunächst mit dem Prozedere des Entwicklungsteams vertraut zu machen. Leider lässt sich immer wieder feststellen, dass es keine generell einheitlich definierte Vorgehensweise gibt. Dabei ist die Branching-Strategie des Entwicklungsteams essentiell für den richtigen Ansatzpunkt einer Open Source Compliance.
Mit Git-Flow (2), Github-Flow (3) und Gitlab-Flow (4) stehen drei anerkannte, aber zunächst unterschiedlich anmutende Handlungsanweisungen zur Verfügung. Die Varianten unterscheiden sich jedoch weniger, als es auf den ersten Blick erscheint.
Im Git-Flow bleibt der Master unantastbar die Version, die sich auch im Produktivsystem findet. Hierdurch verspricht man sich, ein einfaches Rollback auf eine ältere Version, sollte das Deployment 2 PROD einer neuen Version fehlschlagen. Ausgehend von dem Develop-Branch werden einzelne Feature-Branches erzeugt und jeweils wieder auf den Develop-Branch zusammengeführt, um das parallele Entwickeln durch mehrere „Feature“-Teams an dem Develop-Objekt zuzulassen. Atlassian ergänzt in der Beschreibung zudem noch den Umgang mit Hot-Fixes und Releases.
Wesentlich einfacher erscheint der Github-Flow. Einen Teil der Vereinfachung erfährt das Modell jedoch aufgrund der Verlagerung des Masters auf die Rolle des (im Git-Flow) Develop-Branch. Das vereinfacht das Verständnis, da die meisten Werkzeuge #master als Default-Branch verwenden und somit der Entwickler im Default auf dem richtigen Branch arbeitet. Unbeantwortet bleiben im GitHub-Flow jedoch die Fragen nach dem Merge in umfangreicheren Projekten, die sich aus mehreren Modulen zusammensetzen. Damit ist man dann schnell wieder bei einem Release-Branch, wie ihn der Git-Flow kennt.
GitLab hat dies in seiner Flow-Darstellung noch einmal aufgegriffen und explizite Umgebungs-Branches eingeführt, bspw. PROD, PRE-PROD, die solche umgebungspezifischen Assemblies abbilden. Die Bedeutung solcher Varianten sollte jedoch dank dynamischer, bzw umgebungsspezifischer Container-Konfiguration sukzessive abnehmen.
Inwiefern sich das als geeignet erweist, mag nur der jeweilige Projektkontext bewerten. Aus unserer Erfahrung ist ein Failback im Kontext eines Zero-Downtime-Deployments eher weniger ein Thema, das irgendwelche Repositories betrifft. Man würde für ein Rollback sicher auch nicht auf das Soruce-Repository zurückgreifen wollen, sondern lieber die bereits gefertigten Artefakte aus einem Binary-Repository holen. Daher empfehlen wir den Verzicht auf den Git-Flow-„Master“ zugunsten eines „DEV-Masters“ im Sinne des GitHub-Flows.
Die Entscheidung, ob man noch unterschiedliche „Release“-Versionen aufhebt, ergibt sich dann aus der Deployment-Philosophie bzw. dem Geschäftsszenario. Im SaaS-Kontext ist die Dringlichkeit für Release-Branches eher geringer. Wird Software hingegen verteilt, bspw. auf Geräte, die nicht beliebig für Updates zur Verfügung stehen, ist das ein essentieller Schritt für die nachhaltige Wartung. Auf jeden Fall empfehlen wir unabhängig vom gewählten Flow eindringlich die Nutzung von Binary-Repositories, um das ewige Neubauen der Artefakte nach erfolgreichem Test und Dokumentation weitgehend zu unterbinden.
Unabhängig vom gewählten Flow emfpehlen wir stets die Nutzung von Binary-Repositories
Umgang mit Multi-Modul-Projekten
Unbeleuchtet bei all diesen Themen bleibt die Frage nach den „Multi-Modul-Projekten“. Zwar werden diese durch Modularisierungstrends wie Micro-Service-Architekturen mit der Zeit weniger werden, jedoch lässt sich nicht alles endlos teilen und nicht alle Commons lassen sich stets auflösen.
Die Frage nach der richtigen Granularität des Repository-Schnitts wird fall-, bzw. projektspezifische zu beantworten sein. Daher wird es um so wichtiger, auf Seiten der Composistion Analysis ein System zu haben, das hier vollkommene Flexibilität bietet. Wir haben TrustSource daher so konzipiert, dass es beliebige Granularitäten unterstützt. Dazu kennt es die Konstrukte „Projekt“, „Modul“ und „Komponente“.
Die Idee des Projektes ist es, ein Entwicklungsvorhaben zu klammern. Es bildet den Container, in den alles projektspezifische reinkommt: Rahmenbedingungen, allgemeine Berechtigungen, alle zugehörigen Artefakte, Infrastrukturelemente etc.
Das TrustSource-Projekt ist nur eine Klammer für eine Menge an Delivery-Artefakten.
Die Module bilden entweder einzelne Deployment- oder Build-Artefakte. Dabei kann ein Modul entweder das Ergebnis eines Builds oder eine eigenständige Drittkomponente sein. Als Build versteht sich in dem Kontext alles, was im Zuge der Eigenentwicklung gebaut wird. Das kann wiederum ein einzelnes Artefakt oder ein Multi-Komponenten Projekt (bspw. EAR) sein.
Die einzelnen Komponenten, die — auch transitiv — zum Bauen eines Moduls angezogen werden, löst der der Scanner während des Bauens auf und überträgt die Stückliste an TrustSource (s. nebenstehende Grafik). Dabei kann das /SCAN-API, welches die Information entgegennimmt, auch Informationen zu „Branch“ und „Tag“ aufnehmen. Dies hilft später, die Eingaben wiederzufinden.
Zudem unterstützt TrustSource die Verwaltung von Drittprodukten. Das können Komponenten sein, die nicht beim Bauen auftauchen, wie ein MySQL- oder JBoss-Server, eine Bild-Datei (Ressourcen) oder eine gekaufte Library. Diese lassen sich über die Mechanismen Infrastruktur Management (für Open Source-Komponenten) oder COTS-Management (für kommerzielle 3rd Party) verwalten und organisieren und einem Projekt manuell als eigenständige Module hinzufügen.
Das Modul ist also die Klammer der Informationen für ein Build-Artefakt. Es enthält den Teil der rechtlichen Informationen, die modulspezifisch sind, die Architekturposition, Zugriffsrechte etc.. Soweit Letztere nicht für das jeweilige Modul explizit geändert werden, sind sie bereits durch das übergeordnete Projekt gesetzt.
Beispiel
Nachstehendes Bild zeigt die Struktur eines Workplace-Servers. Dieser besteht aus einem Frontend- und einem Backend-Modul, die beide in einem Projekt-Repository abgelegt sind. Der Workplace-Server benötigt zudem einen Tomcat 8.5 und einen MySQL-Server als Ausführungsinfrastruktur. Diese beiden Module sind als Infrastruktur-Module hinzugefügt. Sie werden nicht gebaut, sind aber Bestandteil der Anwendung und entsprechend in die Compliance-Betrachtung einzubeziehen.
Dabei ist es egal, ob die Frontend und Backend-Module aus dem gleichen Repository kommen oder aus unterschiedlichen. Das Ergebnis in TrustSource sieht unverändert aus.
Interessant wird jetzt die Release-Strategie. Liegt die Release-Version auf Anwendungs-Ebene (äußeres Kästchen), wird es also immer nur eine Version der Anwendung geben, sind alle Module jeweils nachzuziehen, um mit der Release-Version Schritt zu halten, oder es muss eine Kombination unterschiedlicher Sub-Release zu dem Gesamt-Release geben. Zum Beispiel würde sich die Version 2.0.0 der Anwendung aus den Versionen Tomcat 8.5, MySQL 5.1 und Frontend 2.0.5 sowie Backend 1.5.16 konstituieren.
Für diesen Fall gibt es seitens des Repository nur dann eine Entsprechung, wenn ein GitLab-artiges Repository für die Produktionsumgebung gepflegt wird, in welches die unterschiedlichen Stände eingebracht werden. Es wird in diesem Kontext erforderlich – wie in allen Multi-Komponenten-on-premises-Projekten ohnehin – einen Release-Brach aufzusetzen, um das Zusammenspiel von Frontend und Backend zu testen, bevor sie ausgebracht werden.
Einbindung der Compliance in den CI/CD-Flow
Als Scan wird das Ergebnis des Scanners bezeichnet, welcher lokal oder auf dem Build-Server ausgeführt wird. Er erzeugt die Struktur inklusive Abhängigkeiten und überträgt diesen „Scan“ mit Hilfe des gleichnamigen API an TrustSource. Dort übernimmt der Scan-Processor den Scan, gleicht die gefundenen Informationen mit der internen Komponentendatenbank ab und bindet den Input an das zugehörige Modul.
Hierdurch entsteht der Kontext. Das Projekt und das Modul halten Rahmenbedingungen, welche für das Projekt bzw. Modul gelten sollen. Das betrifft die Kommerzialisierung sowie andere relevante Aspekte, wie bspw. den Schutzbedarf von IP. Diese Information zusammen mit den Komponenten und Lizenz-Informationen werden dann an den Legal-Check-Service übergeben, welcher die sich aus den Rahmenbedingungen und den Lizenzen ergebenden Verpflichtungen (Obligations) ableitet.
In der Detail-Ansicht findet der Benutzer letztendlich die Summe aller dieser Schritte, das Analyse-Ergebnis. Um eine engere Bindung zwischen dem Quellcode und der Management-Welt herzustellen, stellt TrustSource die Felder „branch“ und „tag“ in dem API /SCAN bereit. Somit lassen sich mehrere Zustände eines Moduls problemlos auseinanderhalten.
Wichtig für das Verständnis der weiteren Schritte ist es, zu verstehen, dass der SCAN die Struktur des Quellcodes wiedergibt. Dieser ist zunächst unbewertet. Erst das in der Detail-Ansicht dargestellte Analyse-Ergebnis ist eine Interpretation vor dem Hintergrund der zum Analysezeitpunkt gültigen Rahmenbedingungen! Daher gilt:
- Jeder Upload erzeugt einen neuen SCAN
- Ein SCAN wird in der Regel einem MODUL zugeordnet, wodurch er seine Rahmeninformationen erhält
- Jedes MODUL gehört zu genau einem PROJEKT – bis auf das systemeigene Sammelmodul „Unassigned“, hier findet sich alles, was nicht automatisch zugeordnet werden kann
- Jeder SCAN erzeugt mindestens ein ANALYSEERGEBNIS (automatisiert)
- Ein MODUL kann beliebig viele ANALYSEERGEBNISSE haben
- Ein SCAN kann beliebig oft an TrustSource übertragen werden, die Zuordnung zu einem MODUL lässt sich bei der Übertragung festlegen
Scans zuordnen
Aus dieser Menge an Fakten lassen sich beliebige Szenarien zusammenstellen. So kann jeder Entwickler an das Ziel-Modul seine Scans schicken und diese mit Hilfe von Branches und Tags differenzieren. Um eine direkte Zuordnung zwischen Code und Analyse-Information herzustellen, könnte man die Commit-ID als Tag anlegen.
Will ein Entwickler seine Experimente nicht in dem allgemeinen und für das gesamte Projekt ersichtlichen Modul einbringen, kann er eine eigene Projekt/Modul-Konstellation anlegen und die rechtlichen Einstellungen aus dem ursprünglichen Projekt kopieren. Somit kann er in seiner Version herumprobieren, ohne den allgemeinen Stack zu belasten.
Andererseits kann es auch sinnvoll sein, sämtliche Branches in dem Modul zu halten, um einen guten Überblick über die Veränderungen zu erhalten. Mit Hilfe des Branch-Selektors im User-Interface lässt sich jede Version direkt auswählen und einsehen.
Approvals einordnen
Doch was ist nun ein Approval? Das Approval ist ein administrativer Schritt, der es dem Projektleiter und den Entwicklern ermöglichen soll, sich von der Domänen-fremden Aufgabe der rechtlichen Begutachtung ihrer Leistung frei zu zeichnen. Hierzu bereitet TrustSource alle Unterlagen für eine Prüfung auf und stellt diese einem rechtlich gebildeten – im TrustSource-Sprech, dem Compliance Manager – zur Verfügung. Dieser muss dann nur noch die Vollständigkeit bzw. Eignung prüfen, wobei ihn TrustSource auch unterstützt, und kann dann eine Freigabe erteilen.
Die Approvals finden idealerweise nicht nach jedem Scan statt, sondern nur vor Merge-Schritten. Dabei sind der Umfang und die Häufigkeit organisationsspezifisch festzulegen. Im Regelfall erfolgt ein Merge in einem vergleichbaren Kontext wie in nachstehender Abbildung gezeigt. Dabei ist es unerheblich, ob es sich um einen Pull-request oder einen richtigen Merge handelt. Ist der zu integrierende Inhalt von einem für seinen Umfang vollständigen Notice-File versehen, kann dieser Inhalt auch in den zusammengeführten Baum übernommen werden und hält die Gesamtdokumentation somit vollständig.
Die obige Darstellung ist um die Scans und die Generierung der Notice Files erweitert. Wir empfehlen, die Notice-Files als Bestandteil einer Definition of Done aufzunehmen. TrustSource verfügt über einen Notice-File Generator. Dieser sammelt sämtliche vorhandenen Informationen und zeigt, welche Informationen noch fehlen, um den Notice-File zu vervollständigen.
Wir empfehlen, vor jedem Merge einen Notice-File zu erzeugen. So ist jeweils nur das Delta zum bisherigen Bestand zu ergänzen
Alle ergänzten Daten stehen ab dem Zeitpunkt der Ergänzung allen Projekten zur Verfügung. Somit sind allgemeine Informationen nur einmal zu erfassen. Das reduziert die Clearing-Aufwände erheblich
Die tatsächliche Gestaltung der Abläufe wird in jedem Unternehmen, vermutlich sogar in jedem Projekt, etwas anders verlaufen. Eine allgemeingültige Darstellung zu verordnen, ist daher weder sinnvoll, noch empfehlenswert. Die Wahrscheinlichkeit, dass sie mehr schadet als nutzt, ist einfach zu hoch. Auch kann es sinnvoll sein, das Vorgehen im Zeitablauf anzupassen. Wird ein Modul nur noch angepasst, ist ein weniger differenziertes Vorgehen empfehlenswert, als wenn mehrere Teams gleichzeitig an den Elementen arbeiten. Wird jedoch vor jedem Merge ein Notice-File erzeugt, ist jeweils nur as Delta zum bereits bestehenden Notice-File zu ergänzen und sowohl der Arbeitsaufwand als auch die spätere Herausforderung für die Compliance-Prüfung halten sich in Grenzen.
Literaturhinweise:
(1) Welche Herausforderungen die Compliance beantworten muss, findet sich in dem Artikel „Aktuelle Herausforderungen der Open Source Compliance“.
(2) Git-Flow: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
(3) GitHub-Flow: https://guides.github.com/introduction/flow/
(4) GitLab-Flow: https://about.gitlab.com/2014/09/29/gitlab-flow/
(5) s. https://github.com/dotnet/corefx/
TrustSource mit Vulnerability Lake (beta)
Vulnerability Lake ergänzt das TrustSource Angebot
Aufgrund vieler Anfragen haben wir uns entschlossen, unsere interne Schwachstellen-DB für unsere Kunden zu öffnen. Ab der Version 2.0 wird TrustSource seine interne „Known Vulnerability“-Datenbank für die Suche zur Verfügung stellen. Es werden mehrere Suchmöglichkeiten zur Verfügung stehen:
- TrustSource Vulnerability-Lake öffentliches Web-UI
eine öffentliche, kostenlose Suche über unsere Schwachstellendaten für die manuelle Nutzung. Zudem wird es möglich sein, sich für bis zu fünf Produkte zu registrieren, um Updates direkt in den eigenen Posteingang zu erhalten. - TrustSource Vulnerability-Lake Web-UI
eine in die TrustSource-Lösung integrierte Such-UI für unsere registrierten Benutzer - TrustSource Vulnerability-Lake API
eine API, die die Such- und Abgleichsfunktionen auch für die programmatische Nutzung bereitstellt. Eine bestimmte Anzahl von Transaktionen pro Monat wird kostenlos sein. Die API wird auch einige statistische Informationen zur besseren Interpretation der Schwachstellendaten bereitstellen.
Die öffentliche Web-Benutzeroberfläche sowie die in TrustSource integrierte Web-Benutzeroberfläche werden einen einfachen und einen Experten-Suchmodus bieten. Im einfachen Modus können Sie eine Produktinformation angeben und die Suche nach Organisation oder Version erweitern. In der professionellen Version kann dies in einem einzigen String kodiert werden, z.B. ’some-org:my-product:3.2.1′ Die Ergebnisse enthalten die typischen Informationen wie CVSS Base Score, CVE-ID, Beschreibung und weiterführende Links.
Die Daten werden alle zwei Stunden aktualisiert. Im ersten Anlauf wird die Lösung nur NVD-Daten enthalten. Später werden wir den Umfang dort erweitern, wo es sinnvoll ist. In den letzten Jahren haben wir eine steigende Verbreitung von CNAs – den Stellen, die CVEs vergeben – beobachtet. Das reduziert die Dringlichkeit, viele verschiedene Quellen zu verarbeiten. Abhängig von Ihrem Anwendungsfall kann es aber dennoch sinnvoll sein, weitere Quellen einzubeziehen. Zögern Sie daher nicht, uns zu kontaktieren, wenn Sie eine wichtige Quelle hingefügt haben möchten.
Wie TrustSource vor Dependency Konfusion schützen kann
Was ist passiert?
Sicherheitsforscher haben es mit Hilfe eines Dependency-Konfusion Angriffes geschafft, sich Zugang zu diversen Hochsicherheits-Netzwerken zu verschaffen. Mit Hilfe dieses Angriffes ist es Ihnen gelungen, Informationen und Daten aus den betroffenen Netzwerken nach draußen zu schicken. Je nach Ausgestaltung des Angriffsszenarios wären jedoch auch andere Aktivitäten denkbar. Erst einmal hinter den Verteidigungslinien angekommen, lässt sich das Schadensszenario frei wählen.
Wie ist der Angriff erfolgt?
Die Sicherheitsforscher sind auf die Idee gekommen, als Sie in den veröffentlichten Open Source Werkzeugen der Firmen (Apple, Adobe, etc.) Namen privater Pakete gefunden haben.
Oft nutzen Unternehmen Open source und ergänzen gewisse Funktionalitäten oder grafische Steuerelemente mit eigenen Bibliotheken. Diese wiederum werden nur von einem Team entwickelt und als eigene Pakete bzw. Bibliotheken für andere Entwicklungsteams bereitgestellt. Das ist effizient und komfortabel, da die breite Menge der Entwicklungs-Teams sich nicht kümmern muss, das Look-and-Feel dennoch konsistent über unterschiedliche Anwendungen bzw. Services bleibt.
Spielen die Unternehmen nun Software zurück an die Community und werden die Referenzen auf solche „privaten“ Pakete nicht aus dem Quellcode entfernt, trägt die Veröffentlichung dien Namen dieser Pakete nach draußen. Das an sich ist noch nicht so gefährlich. Interessant wird dies erst, wenn die Information für eine Dependency-Attack (s. nebenan) ausgenutzt wird.
Wie können Sie sich schützen?
- Komponenten-Namen:
Folgen die internen Komponentennamen einem Namens-Schema, wie bspw.ORG.COPMANY.UNIT.UITOOLSwird es für Dritte erheblich schwieriger entsprechende Namen in den Paketmanagern anzulegen, ohne dass es Aufsehen erregt.ORG.COPMANY.UNIT.UITOOLSfällt mehr auf, als die 100ste Version vonUITOOLS. - Nutzung von Paketmanager-Proxies:
Um in dem Angriff erfolgreich zu sein, sind die lokalen Verteilmechanismen zu überlisten. Es sollte sichergestellt sein, dass für gewisse Paket-Typen, u.a. bspw. mit Hilfe der Namenskennung ode reiner einfachen Blacklist, keine Updates von außen gezogen werden. - Versionsüberwachung:
Mit Hilfe einer Versionshistorie wird es schnell möglich, festzustellen, welche Versionen im Einsatz sind. Ein Sprung von 1.2.3 zu 69.1.0 lässt sich schnell entdecken, bzw. fällt auf.
Was ist eine Dependency-Konfusion?
Moderne Package-Systeme nutzen Paketmanager, insbesondere um die stetig wachsende Zahl von Open Source Komponenten zu verwalten. Jede Build-Vorschrift enthält daher eine Liste der einzubindenden Komponenten. Unter Java ist das die POM.XML-Datei, bei Node.JS (JavaScript) ist das die PACKAGES.JSON.
In dieser Datei sind die Komponenten und die Mindestanforderungen and die Komponenten, die Versionsnummern angegeben. Da sich viele Komponenten öfter ändern, steht in den Vorschriften oft nicht nur die exakte Versionsangabe, bspw. 1.2.3 sondern ein Vermerk wie ^1.2.3, was so viel bedeutet wie: „Gib mir mindestens die 1.2.3 oder neuer.“ . Erfolgt seitens der Maintainer der Komponente eine Update auf bspw. 1.2.4 (neuer Patch) oder 1.3.0 (neues Feature) würde die eigene Lösung mit Hilfe der Formulierung beim nächsten Bauen von den Neuerungen profitieren können.
Wird nun in einem Package Manager von einem bösartigen Akteur eine neuere Version eingestellt, bspw. eine 2.1.0, so kann er relativ sicher sein, dass diese Version vom Package Management für den oben beschriebenen Kontext bereitgestellt würde. Baut das Projekt nun anständig, würde dieser schadhafte Code in ein QS-System ausgebracht und dort ausgeführt. Je nach
Sie wollen Schwachstellen entlang des gesamten Produkt-Lebenszyklus Ihres Produkt verlässlich überwachen?
TrustSource kann gegen solche Angriffe schützen!
TrustSource kennt die aktuellen Versionen Ihrer Module und Lösungen sowie der öffentlich verfügbaren. plötzliche Versionssprünge öffentlich verfügbarer Komponenten werden von unseren Systemen erkannt und an unser Support-Team zur Prüfung gemeldet. Kritisch einzustufende Entwicklungen werden an die Projekte zurückgemeldet.
Nutzen Sie bereits TrustSource ist Ihnen vermutlich das Konzept des „linked Modules“, des Einbindens von Releases eigener Software bekannt. Tauchen hier Versionen auf, die bisher unbekannt sind, führt auch dies zu einer Meldung an den jeweiligen Projektleiter. Somit können Sie sicher sein, entsprechende Entwicklungen schnell zu bemerken.