Sichere Softwareentwicklung

Was ist sichere Softwareentwicklung?

Der klassische Ansatz in vielen Unternehmen folgt einem vorhersehbaren Muster: Erst wird die Software entwickelt, dann, kurz vor dem Go-live, beauftragt jemand einen Penetrationstest. Die Ergebnisse offenbaren Schwachstellen, die sich tief in die Architektur eingebrannt haben. Jetzt wird es teuer: Nachbesserungen in einer fertigen Anwendung kosten ein Vielfaches dessen, was eine frühzeitige Berücksichtigung gekostet hätte. Ein Bericht des National Institute of Standards and Technology (NIST) beziffert den Faktor auf bis zu 30:1 zwischen einem Fehler, der in der Anforderungsphase gefunden wird, und einem, der erst nach der Auslieferung auftritt.

Sichere Softwareentwicklung kehrt dieses Muster um. Sicherheit wird nicht am Ende geprüft, sondern von Beginn an mitgedacht, als Architekturprinzip, als Bestandteil der Anforderungsanalyse und als Kriterium in jedem Code Review. Der englische Fachbegriff lautet Secure Software Development. In der Praxis verschmilzt er mit dem Konzept Security by Design, das denselben Grundgedanken auf die Systemarchitektur als Ganzes anwendet.

Die Abgrenzung zum reaktiven Sicherheitsansatz ist dabei kein akademisches Detail. Sie bestimmt, ob ein Unternehmen Schwachstellen systematisch vermeidet oder lediglich systematisch aufdeckt. Beides hat seinen Platz, aber nur der erste Ansatz senkt die Angriffsfläche nachhaltig. Organisatorisch gehört das in ein IT-Sicherheitsmanagement.

Der Secure Software Development Lifecycle (Secure SDLC)

Der Secure SDLC, auf Deutsch sicherer Softwareentwicklungs-Lebenszyklus, überlagert den klassischen Entwicklungszyklus mit sicherheitsspezifischen Aktivitäten in jeder Phase. Das Ziel ist kein separater Sicherheitsprozess, sondern die Integration in den bestehenden Workflow.

Anforderungsanalyse und Security Requirements

Bevor eine einzige Zeile Code entsteht, werden Sicherheitsanforderungen erhoben, genauso wie funktionale Anforderungen. Welche Daten verarbeitet die Software? Welche regulatorischen Vorgaben gelten? Welche Angriffsvektoren sind realistisch? Die Antworten fließen in ein Sicherheitskonzept ein, das während der gesamten Entwicklung als Referenz dient. Für DSGVO-konforme Softwareentwicklung gehören Privacy-Anforderungen zwingend in diese Phase.

Design und Threat Modeling

Beim Entwurf der Architektur identifiziert das Team potenzielle Bedrohungen. Methoden wie STRIDE oder PASTA helfen, Angriffsflächen systematisch zu analysieren: Wo fließen Daten über Vertrauensgrenzen hinweg? Wo gibt es privilegierte Zugänge? Wo könnte ein Angreifer Eingaben manipulieren? Die Ergebnisse bestimmen die Architekturentscheidungen, etwa die Wahl des Authentifizierungsverfahrens oder die Verschlüsselungsstrategie.

Implementierung und Programmierrichtlinien

Entwickler arbeiten nach definierten Coding-Standards, die bekannte Schwachstellenmuster vermeiden. Eingabevalidierung, parametrisierte Datenbankabfragen, sicherer Umgang mit Kryptografie, Vermeidung von hartcodierten Zugangsdaten, all diese Regeln sind dokumentiert und werden in Code Reviews überprüft.

Test und automatisierte Sicherheitsprüfung

Statische Analyse (SAST) untersucht den Quellcode auf bekannte Muster, noch bevor die Anwendung ausgeführt wird. Dynamische Analyse (DAST) testet die laufende Anwendung auf Schwachstellen. Dependency Scanning prüft, ob verwendete Bibliotheken bekannte Sicherheitslücken enthalten. Grundlage ist eine Software-Stückliste (SBOM), die der Cyber Resilience Act von Herstellern verlangt. Diese drei Werkzeuge ergänzen sich und lassen sich in die CI/CD-Pipeline integrieren, sodass jede Änderung automatisch geprüft wird.

Deployment und gehärtete Pipelines

Die Deployment-Umgebung ist Teil der Angriffsfläche. Gehärtete Build-Server, signierte Artefakte, Zugriffskontrollen für den Livebetrieb und getrennte Umgebungen für Entwicklung, Test und Betrieb sorgen dafür, dass auch der Weg vom Code zur laufenden Software abgesichert ist.

Betrieb und kontinuierliches Monitoring

Nach dem Go-live beginnt die Wartungsphase. Patch Management, Sicherheitsmonitoring und ein dokumentierter Incident-Response-Prozess stellen sicher, dass neue Schwachstellen schnell erkannt und behoben werden. Für Softwareentwicklung im KRITIS-Umfeld gelten hier besonders strenge Anforderungen, die konkreten Vorgaben leiten sich aus den IT-Grundschutz-Bausteinen ab.

OWASP, Standards und gesetzliche Pflichten

Sichere Softwareentwicklung braucht einen Referenzrahmen. Die wichtigsten Frameworks adressieren unterschiedliche Aspekte. Mit dem Cyber Resilience Act kommt erstmals eine gesetzliche Pflicht für Hersteller hinzu, die Produkte mit digitalen Elementen auf dem EU-Markt anbieten.

OWASP Top 10 und OWASP SAMM

Die OWASP Top 10 sind die bekannteste Orientierungshilfe für Webanwendungen. Die Liste der zehn häufigsten Schwachstellen (in der Fassung von 2025 von Broken Access Control über Software Supply Chain Failures bis zu Mishandling of Exceptional Conditions) wird regelmäßig aktualisiert und dient als Mindeststandard für jede Webanwendung.

OWASP SAMM (Software Assurance Maturity Model) geht einen Schritt weiter. Es bewertet den Reifegrad der Sicherheitspraktiken einer Organisation über fünf Geschäftsfunktionen hinweg: Governance, Design, Implementierung, Verifikation und Operations. SAMM eignet sich für Unternehmen, die ihren Secure-SDLC-Reifegrad systematisch verbessern wollen.

NIST Secure Software Development Framework (SSDF)

Das SSDF des NIST (SP 800-218) bietet einen abstrakteren Rahmen, der sich an Organisationen jeder Größe richtet. Es definiert Praktiken in vier Gruppen: Vorbereitung, Softwareschutz, sichere Produktion und Reaktion auf Schwachstellen.

BSI-Empfehlungen

Die BSI-Empfehlungen bieten den deutschen Kontext. Das Bundesamt für Sicherheit in der Informationstechnik hat mit dem IT-Grundschutz einen Rahmen geschaffen, der sichere Softwareentwicklung als Baustein CON.8 enthält. Der IT-Grundschutz bildet zusammen mit ISO 27001 die Basis für viele Sicherheitskonzepte in Deutschland. Auf seinen Anforderungen baut die Technische Richtlinie BSI TR-03185 „Sicherer Software-Lebenszyklus” auf, nach der das BSI seit September 2026 Entwicklungsprozesse zertifiziert.

Sichere Softwareentwicklung als Zertifizierungspflicht

Für zertifizierte Organisationen macht die Norm ISO 27001:2022 sichere Softwareentwicklung verbindlich, im Audit wird sie also nachgewiesen und nicht nur empfohlen. Damit verschiebt sich die Frage von der Methode zum Beleg: Für die ISO 27001 in der Softwareentwicklung zählt, dass Regeln und Tests dokumentiert und im Entwicklungsalltag nachprüfbar sind.

Cyber Resilience Act

Mit dem Cyber Resilience Act (Verordnung (EU) 2024/2847) wird sichere Softwareentwicklung für Hersteller von Produkten mit digitalen Elementen zur Pflicht. Seit dem 11. September 2026 gelten die Meldepflichten für aktiv ausgenutzte Schwachstellen, ab dem 11. Dezember 2027 die übrigen Anforderungen. Die Anforderungen des Cyber Resilience Act an gekaufte Individualsoftware gehören deshalb schon in die Ausschreibung.

Worauf Auftraggeber achten sollten

Wer Software entwickeln lässt, delegiert nicht nur die Implementierung, sondern auch die Sicherheit. Die Wahl des Entwicklungspartners bestimmt, ob sichere Softwareentwicklung gelebte Praxis ist oder nur ein Versprechen im Angebot.

Zertifizierungen als Vertrauenssignal

Eine ISO 27001 Zertifizierung belegt, dass der Dienstleister ein funktionierendes Informationssicherheits-Managementsystem betreibt. Sie ersetzt keine eigene Prüfung, schafft aber eine belastbare Ausgangsbasis. Für öffentliche Ausschreibungen ist sie zunehmend ein Eignungskriterium.

Prüfprozesse und Abhängigkeiten

Hier lohnt die Nachfrage, wie Code Reviews organisiert sind: Werden Sicherheitsaspekte explizit geprüft? Werden automatisierte Tools eingesetzt?

Moderne Software basiert auf Dutzenden bis Hunderten externer Bibliotheken. Ein verantwortungsvoller Dienstleister hat einen Prozess für Dependency Scanning und zeitnahe Updates bei bekannten Schwachstellen.

Testabdeckung und Sicherheitstests

Automatisierte Tests, einschließlich Sicherheitstests, sollten Teil der CI/CD-Pipeline sein, nicht eine manuelle Aktivität vor dem Release. Bei Betreibern kritischer Infrastrukturen kommen die Anforderungen der Softwareentwicklung für KRITIS hinzu.

TenMedia ist nach ISO/IEC 27001 durch den TÜV SÜD zertifiziert und stimmt die Sicherheitsstrategie für sichere Softwareentwicklung je Projekt risikoorientiert mit dem Auftraggeber ab. Wie der Schutz gegen SQL-Injection, Cross-Site-Scripting und CSRF schon in der Konzeption entsteht, beschreibt die Leistung Cybersecurity für Individualsoftware.