Nachlese: Der Cyber Resilience Act aus Entwicklerperspektive mit Sebastian Tiemann
Am 15.10.2026 durften wir Sebastian Tiemann bei der rheinjug willkommen heißen. Sebastian arbeitet als Senior Software Engineer bei Open Elements, ist Gründungsmitglied des Fachkreises Digitale Souveränität des BVMW, Organisator der Java User Group Dortmund, Open-Source-Contributor und verfügt über mehr als fünfzehn Jahre professionelle Erfahrung in der IT. In seinem Vortrag “Cyber Resilience Act aus Entwicklerperspektive” berichtete er uns von den Gefahren, denen der Cyber Resilience Act (CRA) entgegenwirken soll, den Herausforderungen, vor die er Softwareentwickler:innen stellt, und den Werkzeugen, die ihnen bei der Bewältigung dieser Aufgaben helfen können. Nach einem entspannten Einstieg in den Abend bei Getränken, Sandwiches und lockeren Gesprächen begann der Vortrag.
Cyber Resilience Act
Zuerst vermittelte Sebastian uns ein Bild davon, was eigentlich hinter dem CRA steckt. Es handelt sich um eine bereits teilweise geltende EU-Verordnung, deren Ziel es ist, die Sicherheit von Softwareprodukten auf dem europäischen Markt zu verbessern. Es sollen ein einheitlicher Katalog und ein geregeltes Rahmenwerk geliefert werden, um die Lieferkettensicherheit von Produkten mit digitalen Elementen zu gewährleisten. Seit dem 11.09.2026 sind Hersteller verpflichtet, ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle den Behörden zu melden. Ab dem 11.12.2027 ist der CRA vollständig anzuwenden. Wichtig anzumerken ist, dass der CRA die Bedeutsamkeit von Open-Source-Software (OSS) anerkennt. Entwickler:innen von OSS, die nicht im Rahmen einer Geschäftstätigkeit bereitgestellt wird, sind von den Auflagen ausgenommen. Wer jedoch OSS beispielsweise in einem Freemium-Produkt nutzt, ist selbst nicht ausgenommen. Der CRA ermächtigt die Marktüberwachungsbehörden von EU-Mitgliedstaaten zu empfindlichen Sanktionen gegen Unternehmen, die gegen ihn verstoßen. Möglich sind Bußgelder von bis zu 15 Millionen € oder 2,5 % des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist. Mit der BSI Technical Guideline TR-03183 ist ein erster handfester Leitfaden auf dem Weg zur CRA-Compliance erschienen.
Supply Chain Attacks
Lieferkettenangriffe spielen eine zentrale Rolle im Kontext des CRA. Warum das so ist, veranschaulicht folgende Überlegung. Die meisten Softwareprodukte verwenden eine Vielzahl von Dependencies, um ihre Ziele zu erreichen. Schon ein “einfaches” Projekt, welches beispielsweise mit Spring Initializr erzeugt wird, bringt mehr als siebzig Dependencies mit. Oft haben diese Dependencies wiederum eigene Dependencies und so weiter. Ist nun in dieser Kette eine Stelle kompromittiert, dann muss auch das Projekt als kompromittiert betrachtet werden. So kann ein erfolgreicher Angriff auf eine kleine Menge von Komponenten in dieser Kette eine unverhältnismäßig große Menge von Nutzer:innen betreffen, wenn die angegriffenen Komponenten nur weit genug verbreitet sind.
Open Source vs. Proprietary
Obwohl man vermuten könnte, dass proprietäre Software deutlich seltener von solchen Angriffen betroffen ist als OSS, zeigen Statistiken, dass dies nicht der Fall ist. Tatsächlich liegen OSS und proprietäre Software als Ziele von Lieferkettenangriffen in etwa gleichauf. Die größte Angriffsfläche dabei sind Softwareentwickler:innen selbst. So gelangt häufig über Social Engineering Schadcode in die Software eines Anbieters und trifft dann deren Nutzer:innen.
Ein aktuelles Beispiel
In einem aktuellen Beispiel verwies Sebastian auf einen Vorfall in Frankreich, bei dem Hacker die Controller von Supermarktkühlschränken manipulierten und so für massive Kühlungsausfälle sorgten. Der Hersteller stellte den Verkauf der verbauten Controller ein und beendete direkt danach auch die Sicherheitsupdates. Der CRA hätte den Hersteller für mindestens fünf Jahre nach Verkauf der letzten Controller verpflichtet, weiter Sicherheitsupdates bereitzustellen. So könnten die Vorgaben des CRA dabei helfen, solchen Angriffen vorzubeugen.
Eine Kette von Exploits
Aber wo betreffen uns Lieferkettenangriffe als Softwareentwickler:innen im Alltag? Sebastian zeigte, wie selbst in einer stark vereinfachten Entwicklungspipeline bei jedem Schritt Angriffe nicht nur möglich, sondern auch bereits geschehen sind. So kann nicht autorisierter Code direkt in den Quellcode eingefügt werden (SolarWinds). Die IDE selbst kann manipuliert sein und beim Kompilieren Malware einbauen (Strawhorse, XcodeGhost). Die Build-Artefakte von verwendeten externen Tools können modifiziert werden (Codecov). Auch die Build-Werkzeuge selbst können kompromittiert sein (Jenkins, nrwl/nx). Selbst nach dem Build können modifizierte Pakete durch kompromittierte Maintainer-Accounts hochgeladen werden (npm “is”-Package). Wer Pakete von Hand installiert, kann Ziel von Typosquatting werden (npm-Typosquatting). Sogar die Update-Tools von Hardwareanbietern können manipuliert sein (ShadowHammer).
Risiken minimieren
Ist die Lage also aussichtslos? Nein, sagte Sebastian, denn auch wenn es schwierig ist, sich vor all diesen Angriffen zu schützen, können wir aufmerksam sein, früh reagieren und Werkzeuge verwenden, die unser Risiko minimieren.
SBOM
Ein Werkzeug dafür ist die Software Bill of Materials (SBOM). Dabei handelt es sich um eine maschinenlesbare Auflistung aller verwendeten Dependencies und Package-Lizenzen eines Produktes. Zwei verbreitete Formate sind SPDX und CycloneDX. Beide werden von hilfreichen Open-Source-Tools wie Dependency-Track und ORT unterstützt, die umfassende Funktionen für die Arbeit mit SBOMs liefern. So sollen SBOMs, in Kombination mit den genannten Tools, einen schnellen Überblick über eventuell vorhandene CVEs und Lizenzverstöße ermöglichen.
Reproducible Builds
Ein weiteres nützliches Werkzeug sind Reproducible Builds. Durch sie sollen manipulierte Releases leicht identifiziert werden können. Dabei wird das verwendete Release gegen eine unabhängig aus demselben Quellcode neu gebaute Version bitweise verglichen. Sind sie nicht gleich, dann wurde das eigene Release möglicherweise manipuliert. Allerdings stellen Reproducible Builds Maintainer auch vor einige Herausforderungen, da beispielsweise Zeitstempel des Builds zu verschiedenen Bitwerten führen können. Projekte wie Reproducible Central sollen diese Hürden reduzieren.
Fazit
Der CRA reagiert auf die gegenwärtige und wachsende Gefahr durch Lieferkettenangriffe auf Produkte mit digitalen Elementen und verpflichtet Hersteller dazu, Schutzmaßnahmen zu ergreifen. Mit einem Bewusstsein für diese Gefahren und Werkzeugen wie SBOMs und Reproducible Builds können wir die Risiken minimieren.
Wir bedanken uns bei Sebastian für seinen lehrreichen Vortrag und bei allen Teilnehmer:innen für die rege Beteiligung und Diskussion!