In den vergangenen Jahren mussten sich IT-Sicherheitsverantwortliche und ihre Teams zunehmend mit Cyberrisiken auseinandersetzen, die mit den Software-Lieferketten ihrer Anbieter und Partner in Zusammenhang stehen. Immer häufiger machen Cyberkriminelle Schwachstellen in Entwicklungspipelines, Open-Source-Komponenten und Drittanbieter-Integrationen zu einem integralen Bestandteil ihrer Angriffsvektoren. Laut einer Bitkom-Umfrage vom vergangenen Jahr wussten 2024 13 Prozent der befragten IT-Entscheider, von mindestens einem Lieferketten-Zulieferer ihres Unternehmens zu berichten, der in den vergangenen 12 Monaten mindestens einmal Opfer eines Cybersicherheitsvorfalls geworden war. Weitere 13 Prozent vermuteten es, 21 Prozent konnten es nicht ausschließen.
Um dem wachsenden Software-Lieferketten-Risiko zu begegnen, wurden in Europa in den vergangenen Jahren zahlreiche Gesetzesinitiativen auf den Weg gebracht und verabschiedet. Erinnert sei hier nur an NIS2 und DORA. Erst unlängst, am 11. Dezember, kam nun eine weitere gesetzliche Regelung hinzu: der Cyber-Resilience-Act (CRA). Er gilt für sämtliche Software, Firmware und verbundenen Geräte, die in der EU verkauft oder verwendet werden sollen. Hersteller werden in ihm in die Pflicht genommen, für die erforderliche Sicherheit ihrer Hard- und Softwareprodukte zu sorgen – und dies transparent. Käufern soll es so ermöglicht werden, fundiertere Kaufentscheidungen zu treffen, das Thema Sicherheit stärker in ihre Überlegungen mit einzubeziehen.
Erste Anforderungen des CRA müssen Anbieter schon ab dem 11. September 2026 erfüllen, das Groß ab dem 11. Dezember 2027. In Punkto Lieferkettensicherheit macht der CRA Vorgaben hinsichtlich der Risikobewertung und des Risikomanagements, der Sicherheitsmaßnahmen während der Produktentwicklung, der Sicherheit der Standardeinstellungen der Produkte sowie der Software Bill of Materials (SBOM) und der Konformitätsbewertung.
Da es naturgemäß einige Zeit dauern wird, die internen Prozesse an die neuen Compliance-Vorgaben anzupassen, die entsprechenden Reporting-Strukturen einzurichten, kann IT-Entscheidern und Sicherheitsteams nur geraten werden, hier möglichst frühzeitig – am besten schon jetzt – zu beginnen. Vor allem auf drei Punkte sollten sie sich dabei konzentrieren: die Absicherung der gesamten DevOps-Toolchain, die Sicherstellung der Softwareauthentizität und die Etablierung von Maßnahmen zur Erhöhung der Transparenz.
1. Sicherheit in den gesamten Entwicklungszyklus einbetten – Die DevOps-Toolchain muss mit robusten kryptografischen Schutzmechanismen ausgestattet werden.
2. Software-Authentizität sicherstellen – Alle Softwarekomponenten müssen während des gesamten Entwicklungszyklus authentifiziert und verifiziert werden. Die Identitäten von Entwicklern, Anwendungen und Infrastrukturkomponenten müssen überprüfbar sein.
3. Transparenz und Rückverfolgbarkeit verbessern – Um einen vollständigen Einblick in und Überblick über die Herkunft von Software zu erhalten, muss auf Metadaten, wie die Software Bill of Materials (SBOMs), zugegriffen werden.
Umsetzen lässt sich all dies am effektivsten – und effizientesten – mit einer modernen Code Signing-Lösung. Denn diese lassen sich problemlos in CI/CD-Tools integrieren – ohne IT-Workflows und Build-Prozesse zu erschweren oder gar zu unterbrechen. Code kann so während seines gesamten Entwicklungszyklus effektiv überwacht und vor unbefugten Änderungen und Malware geschützt werden – und dies in Echtzeit. Darüber hinaus lässt sich die Durchsetzung von Sicherheitsrichtlinien so weitgehend automatisieren, was den eigenen Sicherheitsteams viel Arbeit abnimmt. Ausgestattet mit einem solchen Tool sollte es jedem Unternehmen möglich sein, die Risiken der eigenen Software-Lieferketten bis zur CRA-Deadline am 11. Dezember 2027 in den Blick und in den Griff zu bekommen.
#Keyfactor
