Security

Azure macht es leicht, neue Dienste bereitzustellen und Anwendungen schnell weiterzuentwickeln. Genau diese Geschwindigkeit kann Sicherheitslücken begünstigen, wenn Berechtigungen zu weit gefasst sind, Secrets provisorisch abgelegt werden oder Logging und Netzwerkregeln auf später verschoben werden. Der Artikel zeigt, wie sich Security by Design in Azure verankern lässt: mit Threat Modeling, einer tragfähigen Tenant- und Subscription-Struktur, klaren Identitäten, Infrastructure as Code, Azure Policy und wirksamer Überwachung nach dem Go-live. Sicherheit wird so nicht zum Kontrollpunkt kurz vor dem Go-live, sondern zu einem Zusammenspiel aus sicheren Standards, klaren Verantwortlichkeiten und überprüfbaren Leitplanken, das Architektur, Entwicklung und Betrieb begleitet. Sie wollen den gesamten Artikel lesen? Dann melden Sie sich gerne bei uns.

Der Cyber Resilience Act macht Produktsicherheit zur dauerhaften Aufgabe für Hersteller digitaler Produkte. Für Entwicklungsteams werden bewährte Praktiken wie sichere Entwicklung, strukturierte Risikoanalysen und Threat Modeling verbindlicher. Auch Schwachstellenmanagement, eine Software Bill of Materials (SBOM), Updatefähigkeit, Incident Response und technische Nachweise gehören damit zum Entwicklungsalltag. In seinem Beitrag in der Windows Developer, Ausgabe 10.2026, ordnet Lars Roith die Anforderungen aus Sicht der Produktentwicklung ein. Er zeigt, warum die Umsetzung über Bußgelder und Konformitätsbewertung hinausgeht und wie Sicherheit über Entwicklung, Veröffentlichung und Wartung nachvollziehbar verankert werden kann. Sie wollen den gesamten Artikel lesen? Dann melden Sie sich gerne bei uns.

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.

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.