Wissen

Der Cyber Resilience Act wirkt auf den ersten Blick wie ein Thema für Compliance und Regulierung. In unserem Artikel in der dotnetpro 3/26 zeigen wir aber, warum der CRA kein reines Compliance-Thema ist, sondern ein ehrlicher Reifegradtest für Softwareentwicklung und Produktverantwortung. Spannend wird der CRA dort, wo Teams nicht mehr nur über gute Praxis sprechen, sondern sie im Alltag belastbar zeigen müssen. Es geht nicht zuerst um neue juristische Begriffe, sondern um sehr praktische Fragen: Wie tragfähig sind Architekturentscheidungen, wie sauber funktionieren Updates, wie gut kennt man die eigenen Abhängigkeiten und wie verlässlich wird mit Schwachstellen umgegangen? Genau deshalb lesen wir den CRA weniger als reinen Regeltext und mehr als Spiegel für die eigene Entwicklungsrealität. Wenn du die Diskussion dazu intern anstoßen willst, findest du im Artikel eine kompakte Grundlage.

Generative KI ist kein Hype mehr, sie ist Realität. Doch wie bringst du sie erfolgreich in dein Produkt? Unser Artikel zeigt dir den praktischen Weg von der ersten Idee bis zur produktiven Lösung. Du lernst, wie sich GenAI-Integration von klassischer Softwareentwicklung unterscheidet, welche Anwendungsmuster wirklich funktionieren und worauf es bei technischen Grundlagen und Architektur-Entscheidungen ankommt. Außerdem erfährst du, was bei Datenqualität und Entwicklungsprozessen entscheidend ist. Keine Theorie, sondern praxiserprobte Erkenntnisse für Entwickler und Produktverantwortliche, die GenAI strategisch und nachhaltig einsetzen wollen. Sie wollen den gesamten Artikel lesen? Dann melden Sie sich gerne bei uns.

Der Cyber Resilience Act (CRA) wird oft als weiteres regulatorisches Pflichtprogramm wahrgenommen. In der Praxis wirkt er jedoch wie ein Gradmesser: Er legt schonungslos offen, wie reif oder rückständig Softwareentwicklungsprozesse in Unternehmen tatsächlich sind. Im Fokus steht die Frage, ob Organisation, Architektur und Prozesse überhaupt in der Lage sind, sichere Software über Jahre hinweg verlässlich zu liefern. Der Vortrag zeigt, warum der CRA weniger neue technische Anforderungen einführt, sondern bestehende Defizite sichtbar macht. Fehlende Security-by-Design-Prinzipien, unklare Verantwortlichkeiten, manuelle Release-Prozesse, fehlende Transparenz über Abhängigkeiten oder eine Update-Strategie, die auf Hoffnung basiert, werden unter regulatorischem Druck schnell zum Geschäftsrisiko. Anhand typischer Entwicklungsrealitäten wird erläutert, wie sich CRA-Anforderungen konkret auf Architekturentscheidungen, CI/CD-Pipelines, Toolchains und die Zusammenarbeit zwischen Entwicklung, Produktmanagement und Organisation auswirken. Der Talk richtet sich an Entwickler, Tech Leads und Engineering-Verantwortliche, die verstehen wollen, warum der CRA kein juristisches Detailproblem ist, sondern ein strukturelles Signal dafür, ob moderne Softwareentwicklung im Unternehmen wirklich angekommen ist.

APIs sind das Rückgrat moderner Anwendungen, doch die Wahl des richtigen Stils kann entscheidend für Performance, Wartbarkeit und Skalierbarkeit sein. In dieser Session Die API-Landschaft ist vielfältig: REST, GraphQL, OData, gRPC, WebSockets, Server-Sent Events und mehr. Dieser Vortrag zeigt live, welche Vor- und Nachteile die einzelnen Ansätze mitbringen und wann sich welcher Stil eignet. Du erfährst, ob es sinnvoll ist, mehrere parallel bereitzustellen und wie sich gemeinsame Logik über verschiedene Schnittstellen hinweg nutzen lässt. Anhand praktischer Beispiele mit ASP.NET Core siehst du die Konzepte in Aktion. Am Ende weißt du, welche API-Strategie zu deinem Projekt passt und wie du flexibel zwischen den Optionen wechseln kannst.

Bewerten Sie in ca. 30 Minuten Ihren Softwareentwicklungsprozess nach den Anforderungen des EU Cyber Resilience Act. Die Einschätzung identifiziert Lücken in Prozessen, Verantwortlichkeiten und Umsetzungsständen und liefert priorisierte, praxisnahe Maßnahmenempfehlungen. Sie richtet sich an Produktverantwortliche, Entwicklungsteams und Compliance‑Verantwortliche und dient als Grundlage für Risikoanalysen, Audit‑Vorbereitung und Maßnahmenplanung.

In dieser einstündigen Never Code Alone Session mit Roland Golla zeigt Florian Bader, was Entwicklungsteams über Security by Design wissen sollten. Im Mittelpunkt stehen die Phasen Planung, Design, Entwicklung und Testing und die Frage, wie Sicherheit in jeder davon wirksam mitgedacht werden kann. Die Session liefert konkrete Orientierung für Teams, die Sicherheitsanforderungen frühzeitig verankern und im Entwicklungsalltag umsetzen wollen. Sie betrachtet Risiko- und Threat-Analysen als Grundlage für sichere Architekturentscheidungen und zeigt, wie Analyzer, Secrets-Scanner und Dependency-Checks Risiken bereits während der Entwicklung sichtbar machen. Auch API-Sicherheitstests und die Zusammenarbeit von Entwicklung, Architektur und Qualitätssicherung kommen zur Sprache. So entsteht ein praxisnaher Überblick über Maßnahmen, mit denen Teams typische Sicherheitslücken früh erkennen und vermeiden können. Das GitHub-Repository mit den passenden praktischen Beispielen gibt es hier.

In dieser viereinhalbstündigen My Coding Zone Session mit Gregor Biswanger diskutiert Florian Bader Security by Design über den gesamten Software-Lebenszyklus hinweg. Von Planung und Design über Entwicklung und Testing bis zu Betrieb und Wartung geht es darum, Sicherheit als festen Bestandteil der täglichen Arbeit zu etablieren. Die ausführliche Diskussion reicht von Risiko- und Threat-Analysen über sichere Architekturentscheidungen bis zum Einsatz von Analyzern, Secrets-Scannern und Dependency-Checks. Außerdem werden API-Sicherheitstests, Security Monitoring und der Betrieb mit Microsoft Defender for Cloud als konkrete Bausteine einer durchgängigen Sicherheitsstrategie eingeordnet. Fragen aus dem Publikum greifen konkrete Herausforderungen aus der Praxis auf und verbinden sie mit umsetzbaren Ansätzen für Entwicklungsteams. Die Session bietet Raum für Einordnung, Austausch und Antworten zu den Sicherheitsfragen, die Teams in ihren Projekten bewegen. Das GitHub-Repository mit den passenden praktischen Beispielen gibt es hier.