Wissen

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.

Dokumentation veraltet, wird nicht geschrieben oder liegt verstreut in verschiedenen Systemen. Documentation as Code ist ein Ansatz, der Dokumentation nah am Code versioniert und wartbar macht. Dieser Vortrag zeigt, wie du Dokumentation strukturierst, Markdown-Dateien aufbaust und Schaubilder mit Mermaid oder PlantUML generierst. Wir klären, für welche Zielgruppen du schreibst, wo du die Dokumentation hostest und wie du sie in den Entwicklungsprozess integrierst. Best Practices und konkrete Guidelines helfen dir, Dokumentation zur Selbstverständlichkeit zu machen.

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.

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.

Beim Agentic Coding Summit diskutiert Felix Burkhard gemeinsam mit Matthias Liebeck, wie sich der Verbrauch von GitHub Copilot in realen Entwicklungsaufgaben reduzieren lässt, ohne die Lieferfähigkeit aus dem Blick zu verlieren. Drei Läufe derselben Aufgabe mit identischem Modell und gleicher Reasoning-Stufe zeigen, dass nicht nur der sichtbare Prompt zählt. Instruktionen, Suchläufe, Tool-Antworten, Dateiinhalte und wiederholter Kontext prägen den Verbrauch einer Session. Die Gegenüberstellung beginnt mit einem normalen Ausgangslauf und führt über bewusst knappere Instruktionen und Antworten zu einer besser aufbereiteten Kontextsicht. Der Verbrauch sinkt dabei von 780 auf 544 und schließlich auf 280 Credits. Der Vortrag ordnet die Messwerte ein und zeigt zugleich, warum geringerer Verbrauch nicht automatisch bessere Ergebnisse bedeutet. Die Aufzeichnung richtet sich an Entwicklerinnen und Entwickler, die GitHub Copilot als Teil ihres Entwicklungsprozesses einsetzen und den Ablauf messbar verbessern wollen. Die Hintergründe und Messwerte beschreibt Felix Burkhard auch in unserem Blogartikel AI-Token-Optimierung mit GitHub Copilot.

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.