CRA und NIS2 machen Software-Sicherheit überprüfbar Jenseits des Vertrauens – Software muss Sicherheit technisch belegen

Anbieter zum Thema

FTAPI Software GmbH

Angriffe auf Software-Lieferketten wie bei SolarWinds, XZ-Utils oder npm zeigen: Vertrauen allein reicht nicht mehr. CRA und NIS2 fordern erstmals, dass Software ihre Sicherheit technisch belegt – nachvollziehbar und überprüfbar. Hersteller müssen sichere Entwicklung attestieren, Betreiber diese Nachweise validieren. Sicherheit wird zur überprüfbaren Eigenschaft.

Software ist zu einem Produkt globaler Zusammenarbeit geworden: Hunderte Bibliotheken, Open‑Source‑Komponenten und eigener Code fließen über automatisierte Build‑Pipelines in moderne Anwendungen ein. Eine Komplexität, die ihren Preis hat: Angriffe wie die Backdoor-Platzierungen im sogenannten „Sunburst“-Hack und XZ-Utils sowie kompromittierte CI/CD‑Systeme verdeutlichen, wie verwundbar Software‑Lieferketten geworden sind – und wie stark sie zunehmend in den Fokus von Hackerangriffen geraten.

Ein Kontext, in dem unter anderem der Cyber Resilience Act (CRA) und die NIS2 Richtlinie Abhilfe schaffen sollen. Erstmals existiert ein regulatorischer Rahmen, der Sicherheit nicht nur fordert, sondern für beide Enden der Supply Chain verbindlich macht: Der Hersteller muss belegen können, dass seine Software sicher entstanden ist. Der Betreiber muss überprüfen, ob diese Nachweise plausibel und vollständig sind.

Supply-Chain-Security im Fokus

Lehren aus dem npm-Supply-Chain-Angriff

Zwei Perspektiven, ein gemeinsames Ziel

Der CRA definiert Mindeststandards für die Entwicklung und Wartung von Software. Er verlangt, dass Sicherheit von Beginn an Teil des Entwicklungsprozesses ist. Dazu gehören nachvollziehbare Entwicklungs- und Build‑Prozesse, verpflichtende Sicherheitsmaßnahmen, ein dokumentierter Umgang mit Schwachstellen und vor allem Transparenz: Über eine Software Bill of Materials (SBOM) müssen Hersteller offenlegen, welche Komponenten sie verwenden. Updates müssen sicher ausgeliefert werden und damit signiert und eindeutig dem Hersteller zuzuordnen sein – ein Schutz gegen manipulierte oder eingeschleuste Artefakte.

NIS2 nimmt dagegen die Betreiber in die Pflicht. Unternehmen, die kritische Dienste anbieten, müssen sicherstellen, dass die eingesetzte Software vertrauenswürdig ist und dass Hersteller ihre Produkte nachweislich sicher bauen. Die Verantwortung endet nicht beim Softwarekauf: Betreiber müssen Herkunft, Integrität und Aktualität der eingesetzten Software prüfen, Risiken dokumentieren und regelmäßig bewerten.

Aus beiden Perspektiven entsteht ein durchgängiges Modell von Verantwortung.

Security-Insider Podcast – Folge 86

Backdoor in xz-Tools erschüttert die IT-Welt

Die Lieferkette als kritischer Angriffspunkt

Dass sich der Fokus der Regulierungen auf die Lieferkette verschiebt, ist die logische Konsequenz aus der Weiterentwicklung der Angriffsvektoren. Immer mehr erfolgreiche Angriffe nehmen ihren Anfang in der Entstehung einer Anwendung. Wenn böswillige Akteure eine Build‑Pipeline kompromittieren oder manipulierte Open‑Source‑Bibliotheken in ein Produkt schleusen, lässt sich der Schaden kaum noch begrenzen. Eine einzige Schwachstelle kann sich potenziert auf hunderte oder tausende nachgelagerte Systeme auswirken.

In Unternehmensnetzwerken und Produktionsumgebungen können operative Störungen bei kritischen Geschäftsprozessen auftreten sowie sensible Daten entwendet oder vernichtet werden. Ausfälle in kritischen Infrastrukturen können sogar erhebliche gesellschaftliche oder gesamtwirtschaftliche Folgen nach sich ziehen.

Daher definieren CRA und NIS2 eine gemeinsame Erwartung: Software muss nicht nur funktionieren, sie muss nachweislich sicher entstehen. Das verändert die Dynamik zwischen Herstellern und Betreibern grundlegend. Sicherheit ist nicht länger eine Frage des Vertrauens. Sie muss lückenlos überprüfbar sein – und überprüft werden.

Cyber-Risikomanagement in der Supply Chain

Eskalierende Bedrohungslandschaft für Lieferketten

Integrität und Provenance: Die neuen Eckpfeiler echter Software-Sicherheit

Zwei Konzepte rücken damit in den Mittelpunkt: Software-Integrität und Software-Provenance.

Integrität beschreibt die Frage, ob ein Softwareartefakt unverändert und echt ist. Digitale Signaturen, Hashes und nachprüfbare Build‑Prozesse ermöglichen es Betreibern, Updates kryptografisch zu validieren, bevor sie in produktive Systeme gelangen. Nur wenn die Quelle zweifelsfrei identifizierbar ist und potenzielle Manipulationen zuverlässig erkannt werden können, kann ein Update als vertrauenswürdig gelten.

Provenance geht einen Schritt darüber hinaus. Sie beschreibt den kompletten Entstehungsprozess eines Artefakts: Wo wurde es gebaut, mit welchen Komponenten, mit welchen Sicherheitsmechanismen? Stammt es aus einer reproduzierbaren, manipulationssicheren Pipeline? Standards wie SLSA oder signierte SBOMs liefern hier erstmals maschinenlesbare und fälschungssichere Nachweise.

Die Provenance-Daten sind der Schlüssel, anhand dessen Betreiber nachweisen können, dass sie ihrer Sorgfaltspflicht aus NIS2 nachkommen – und Hersteller die Vorgaben des CRA erfüllen.

Cyber Resilience Act macht Security ab 2027 zur Zulassungspflicht

So bereiten sich Hersteller jetzt auf den Cyber Resilience Act vor

Sicherheit unabhängig attestieren

In der Praxis ist es wirtschaftlich jedoch kaum zu bewerkstelligen, dass tausende Anwender eines Produkts den Hersteller jeweils selbst überprüfen. Entsprechend können zu diesem Zweck spezialisierte Software-Supply-Chain-Security-Plattformen wie etwa SignPaths DevSec360 zum Einsatz kommen. Ihr zentraler Vorteil besteht darin, dass sie solche Nachweise automatisiert und kryptografisch abgesichert erzeugen.

Ähnlich wie eine notarielle Beglaubigung, stellen diese einmalig sicher, dass der Entwicklungsprozess tatsächlich so ablief wie die Dokumentation dies beschreibt. Hersteller müssen so nicht länger auf Dokumente oder manuelle Auditberichte verweisen, sondern können die Einhaltung eines sicheren Software Development Lifecycle direkt im Build‑Prozess attestieren lassen. Signierte Provenance‑Daten, SBOMs oder Build‑Attestierungen bilden einen nicht manipulierbaren Nachweis der Entstehung.

Betreiber können diese Nachweise dann automatisiert prüfen und validieren. So lässt sich etwa vor jedem Deployment prüfen, ob die Signatur eines Artefakts gültig ist, ob die mitgelieferten Provenance‑Informationen ausreichend sind, und ob die SBOM mit dem tatsächlichen Inhalt des Artefakts übereinstimmt. Somit werden jene Nachweise validierbar, die vom Hersteller bereitgestellt werden müssen. Compliance ist damit nicht länger eine administrative Zusatzaufgabe, sondern integrierter Teil der technischen Qualitätssicherung.

Supply-Chain-Sicherheit

3 von 10 Cyberattacken zielen auf Zulieferer

Für alle nötig: Eine überprüfbare Ende-zu-Ende-Vertrauenskette

Nur wenn Hersteller ihre Software konsequent attestieren lassen und Betreiber diese Nachweise automatisiert prüfen, kann eine echte Ende-zu-Ende-Vertrauenskette entstehen. Jede Komponente, jedes Update und jeder Build‑Schritt müssen nachvollziehbar werden. Erst dann ist Sicherheit nicht länger nur ein Ergebnis guter Prozesse, sondern eine überprüfbare Eigenschaft eines Produkts.

Den zentralen Schlüssel hierzu bildet ein automatisierter, Zero-Trust-basierter und regulatorisch belastbarer Sicherheits-Layer, der die gesamte Software-Entwicklung und -Auslieferung lückenlos abdeckt.

CRA und NIS2 schaffen dafür die regulatorischen Grundlagen. Sie verpflichten Hersteller und Betreiber, Transparenz und Nachvollziehbarkeit in den Mittelpunkt zu stellen und ermöglichen damit erstmals, Softwarevertrauen durch objektive, maschinenlesbare Nachweise zu untermauern. Europa geht damit einen Schritt voran: weg von freiwilligen Standards, hin zu verbindlicher, überprüfbarer Software‑Sicherheit.

Über die Autoren:
Stefan Wenig ist Gründer und CEO von SignPath.
Florian Lukavsky ist Chief Innovation Officer von SignPath.

Strategien für eine sichere Software-Lieferkette

So funktionieren Supply-Chain-Attacks

Notepad++ lieferte monatelang Backdoors statt Updates

Notepad++-Super-GAU: Wie das Admin-Tool zur APT-Waffe wurde

(ID:50797177)