Sicherheitslücken werden heute schneller gefunden und schneller ausgenutzt als je zuvor – und gerade im Zeitalter von AI-Coding, Vibe-Coding und Copilot-gestützter Softwareentwicklung reicht es nicht mehr, Security als nachgelagertes Thema zu behandeln. Genau darum ging es in unserer Never-Code-Alone-Session mit Florian Bader, Solution-Architekt und Mitgründer von Lunaris Digital Solutions. Wenn ihr euch mit sicherer Softwareentwicklung, DevSecOps oder dem Cyber Resilience Act beschäftigt, lohnt sich das Video für euch gleich mehrfach – wir fassen die wichtigsten Learnings hier zusammen.
Was bedeutet Security by Design eigentlich?
Security by Design heißt nicht, dass ihr eine Software bauen müsst, die zu hundert Prozent unangreifbar ist. Es bedeutet, Sicherheit von Anfang an mitzudenken und über den gesamten Softwareentwicklungsprozess hinweg zu berücksichtigen – von den Anforderungen über Design und Architektur, durch die Entwicklung, das Testing bis in den Betrieb und den Support. Genau dieser Zyklus zieht sich durch das gesamte Video, und genau deshalb ist er als Leitfaden für eure eigene Softwareentwicklung so wertvoll.
Ein zentraler Punkt: Viele Anforderungen aus Regularien wie dem Cyber Resilience Act der EU sind im Kern nichts anderes als Security by Design. Wer heute schon Prozesse für sichere Softwareentwicklung etabliert hat, deckt damit einen Großteil dieser regulatorischen Anforderungen automatisch ab. Das nimmt vielen Teams die Angst vor Compliance – ihr müsst nicht bei null anfangen, sondern nur konsequent weiterdenken, was ihr eigentlich schon tun solltet.
OWASP Top Ten und Berechtigungskonzepte als Startpunkt
Bevor es an die Tools geht, lohnt sich ein Blick auf die OWASP Top Ten – die bekannteste Liste der häufigsten Angriffsvektoren in der Webentwicklung, von Broken Access Control bis zu Problemen mit CORS-Headern. Besonders spannend ist die Diskussion um Berechtigungskonzepte: Viele Proof-of-Concept-Anwendungen starten mit einem Admin-Zugang und landen dann, oft schneller als geplant, direkt in Production. Empfohlen wird stattdessen ein Role-Based-Access-Control-Ansatz mit granularen, klar abgeleiteten Rollen – ein Konzept, das sich gerade für Teams lohnt, die schnell wachsende Anwendungen betreuen.
Threat Modeling: Angriffsvektoren sichtbar machen
Ein Highlight der Session ist die Live-Demo des Microsoft Threat Modeling Tools. Florian zeigt, wie sich Datenflüsse zwischen Frontend, Backend und Datenbank modellieren lassen und wie das Tool anhand des STRIDE-Katalogs automatisch potenzielle Angriffsvektoren vorschlägt – von Elevation of Privilege bis Tampering. Besonders praxisnah: die Diskussion, wann ein Risiko wirklich „not applicable“ ist und wann eine vermeintliche Absicherung wie ein VPN oder eine Firewall trügerische Sicherheit vorgaukelt. Wer noch keine Architektur- oder Datenflussdokumentation hat, bekommt hier gleich den nächsten Denkanstoß mit: Ohne diese Basis können weder Menschen noch KI-Agenten sinnvoll auf eure Systeme aufsetzen.
Statische Code-Analyse, Secret Scanning und SBOM
Im Entwicklungsteil geht es richtig technisch: Florian zeigt live in Visual Studio Code, wie eine simple SQL-Injection-Schwachstelle durch statische Code-Analyse in .NET aufgedeckt wird – ein Klassiker, der sich mit Tools wie SonarQube, ESLint-Security-Rules oder CodeQL von GitHub über verschiedene Programmiersprachen hinweg automatisieren lässt.
Danach folgt ein Blick auf hardcodierte Passwörter und Secrets im Code – ein Fehler, der überraschend häufig passiert, auch bei erfahrenen Teams. Die Lösung: Gitleaks, verpackt in einem Docker-Container, der den gesamten Code automatisiert nach Mustern durchsucht, die wie Passwörter oder API-Keys aussehen, und sich direkt in die CI/CD-Pipeline integrieren lässt.
Ein weiterer wichtiger Baustein ist das Thema Software Bill of Materials, kurz SBOM. Mit Tools wie Dependency-Track von der OWASP Foundation lassen sich alle direkten und transitiven Abhängigkeiten eurer Software erfassen und regelmäßig gegen offizielle Vulnerability-Datenbanken prüfen. Gerade im Kontext des Cyber Resilience Act wird das zur Pflicht – wer Software über Jahre supportet, muss auch Jahre später noch nachweisen können, welche Komponenten verbaut sind und wie mit neu entdeckten Schwachstellen umgegangen wird.
Testing, Security-Header und der Blick von außen
Zum Abschluss zeigt Florian, wie sich Security auch im Testing verankern lässt: mit dynamischen Scans über OWASP ZAP, die eine Webanwendung von außen angreifen und dabei fehlende Security-Header wie Content Security Policy oder X-Frame-Options aufdecken. Diese Header entscheiden mit darüber, ob eure Anwendung anfällig für Cross-Site Scripting oder Clickjacking ist. Ergänzend empfiehlt er, gezielte Tests zu schreiben, die nicht nur den Happy Path, sondern auch typische Angriffsmuster wie SQL-Injection oder Script-Injection prüfen.
Warum sich das Anschauen lohnt
Was das Video besonders macht, ist der Praxisbezug: Statt abstrakter Buzzwords bekommt ihr eine konkrete Tour durch kostenlose und leicht zugängliche Tools, die sich in bestehende Softwareentwicklungsprozesse integrieren lassen – ohne dass ihr gleich ein großes Security-Budget braucht. Gleichzeitig werden auch die unbequemen Fragen nicht ausgespart: Haftung von Geschäftsführern, Meldepflichten nach dem Cyber Resilience Act und der Umgang mit einer erdrückend langen Liste an Findings, wenn ein Scanner zum ersten Mal über eine gewachsene Codebase läuft.
Der wichtigste Rat aus der Session lässt sich so zusammenfassen: Nicht alles auf einmal einführen, sondern klein anfangen, low hanging fruits ernten und Security Schritt für Schritt zu einem festen, automatisierten Bestandteil eures Entwicklungsprozesses machen. Wer heute damit beginnt, ist nicht nur besser auf kommende Regularien wie den Cyber Resilience Act oder NIS2 vorbereitet, sondern schafft sich auch eine solide, sichere Basis, auf der sich langfristig verlässlich weiterentwickeln lässt.
Unser Fazit für euch
Egal ob ihr gerade erst über Threat Modeling nachdenkt, eure erste SBOM erzeugen wollt oder Secret Scanning in eure Pipeline einbauen möchtet – dieses Video liefert euch einen kompakten, technisch fundierten Einstieg in Security by Design, direkt aus der Praxis von zwei Entwicklern, die täglich mit genau diesen Themen arbeiten.
Wenn ihr Unterstützung bei der Einführung von Security-Tooling, sicherer Softwarearchitektur oder der Vorbereitung auf regulatorische Anforderungen wie den Cyber Resilience Act braucht, nehmt gerne Kontakt mit uns auf – wir helfen euch dabei, Security nicht als lästige Pflicht, sondern als festen, automatisierten Bestandteil eurer Softwareentwicklung zu etablieren.
