05.05, 16:00–16:30 (Europe/Berlin), Gartensaal
Sprache: Deutsch
"Das regelt Security." "Das ist was für die Rechtsabteilung." So denken viele Entwickler über den Cyber Resilience Act. Falsch gedacht.
Ab Dezember 2027 schreibt der CRA Anforderungen vor, die direkt in deinem Code landen: Software-Stücklisten (SBOMs) müssen mit jeder Release ausgeliefert werden. Bekannte Schwachstellen dürfen nicht mehr im Backlog versauern. Default-Passwörter? Verboten. Unverschlüsselte Datenübertragung? Nicht mehr zulässig.
Das sind keine Compliance-Dokumente, die jemand anderes für dich schreibt. Das sind Änderungen an deiner CI/CD-Pipeline, deinen Dependencies und deiner Definition of Done.
In diesem Talk zeige ich, welche CRA-Anforderungen direkt bei dir als Entwickler ankommen:
- SBOM-Generierung als Build-Step
- Vulnerability Handling mit harten Fristen
- Security-Defaults, die du ab jetzt mitliefern musst
- Was das für deine Open-Source-Dependencies bedeutet
Kein Jura-Deutsch, sondern Klartext für alle, die Code schreiben.
Der Cyber Resilience Act (CRA) ist seit Dezember 2024 in Kraft, ab 2026 gelten Meldefristen für Schwachstellen und ab 2027 wird er voll wirksam. Die meisten Artikel und Talks zum Thema richten sich an Security-Teams, Produktmanager oder Juristen. Dabei enthält der CRA eine Reihe von Anforderungen, die direkt im Entwicklungsprozess umgesetzt werden müssen und zwar von Entwicklern selbst.
Dieser Talk schließt diese Lücke. Statt über Haftungsfragen und Bußgelder zu sprechen, konzentriere ich mich auf die technischen Anforderungen und ihre praktische Umsetzung:
SBOM-Pflicht: Der CRA verlangt eine maschinenlesbare Software-Stückliste. Ich zeige, wie man SBOMs mit Tools wie Syft oder Trivy generiert und in die CI/CD-Pipeline integriert, inklusive der Frage, welches Format (CycloneDX vs. SPDX) sinnvoll ist.
Vulnerability Handling: Aktiv ausgenutzte Schwachstellen müssen innerhalb von 24 Stunden an ENISA gemeldet werden. Das verändert, wie Teams mit CVEs umgehen. Vom Backlog-Eintrag zur echten Eskalation.
Secure by Default: Der CRA definiert konkrete Anforderungen an Auslieferungszustände: keine Default-Passwörter, sichere Konfiguration out-of-the-box, automatische Sicherheitsupdates wo möglich. Das betrifft Architekturentscheidungen, die früh im Sprint fallen.
Open-Source-Dependencies: Ein Großteil moderner Software besteht aus Open-Source-Komponenten. Ich erkläre, wie der CRA zwischen "Open Source Stewards" und kommerziellen Anbietern unterscheidet und was das für die eigene Dependency-Strategie bedeutet.
Zielgruppe: Entwickler, Tech Leads und Engineering Manager, die wissen wollen, welche CRA-Anforderungen in ihrem Team ankommen werden. Keine Vorkenntnisse zu EU-Regulierung nötig.
Takeaways: Die Teilnehmer verlassen den Talk mit einer konkreten Checkliste, was sich in ihrem Entwicklungsprozess ändern muss und genug Kontext, um das Thema im eigenen Team anzustoßen.
Waldemar ist Geschäftsführer der Think Ahead Technologies GmbH und baut mit seinem Team Kunnus – eine Plattform, die den Aufwand für CRA-Compliance um 70% reduzieren soll. Sein Background liegt in Software-Entwicklung und Platform Engineering, mit Stationen in Automotive, Handel, Unterhaltung, sowie im KRITIS-Umfeld. Trotz starker Kurzsichtigkeit hat er erstaunlich viel Weitblick, wenn es um Security-Regulierung geht, und klettert in der Boulderhalle Routen, die er nur halb sieht.