Sichere Softwareentwicklung

Sichere Softwareentwicklung beschreibt einen Ansatz, bei dem Sicherheitsanforderungen von Anfang an in den Entwicklungsprozess integriert werden — nicht als nachträglicher Penetrationstest, sondern als fester Bestandteil jeder Phase. Vom Architekturentwurf über das Coding bis zum Deployment sorgen definierte Methoden dafür, dass Schwachstellen systematisch vermieden werden.
Blauer Hintergrund mit Zahlen. Einsen und Nullen. Im Vordergrund ein Vorhängeschloss als Symbol für sichere Softwareentwicklung.
© sarayut_sy

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. Studien des National Institute of Standards and Technology (NIST) beziffern den Faktor auf 30:1 zwischen einer Schwachstelle, die in der Anforderungsphase gefunden wird, und einer, die erst in der Produktion 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.

Der Secure Software Development Lifecycle (Secure SDLC)

Der Secure SDLC ü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. Im Architekturentwurf 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 Secure Coding Guidelines. Entwickler arbeiten nach definierten Coding-Standards, die bekannte Schwachstellenmuster vermeiden. Eingabevalidierung, parametrisierte Datenbankabfragen, sicherer Umgang mit Kryptografie, Vermeidung von hartcodierten Zugangsdaten — diese Regeln sind dokumentiert und werden in Code Reviews überprüft. Bei TenMedia orientieren wir uns dabei an den Annex-A-Controls der ISO 27001, die sichere Coding-Praktiken verbindlich machen.

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. 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 Produktionsumgebungen und die strikte Trennung von Entwicklungs-, Test- und Produktionsumgebungen 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 und andere Frameworks

Sichere Softwareentwicklung braucht einen Referenzrahmen. Die wichtigsten Frameworks adressieren unterschiedliche Aspekte.

OWASP Top 10 ist die bekannteste Orientierungshilfe für Webanwendungen. Die Liste der zehn häufigsten Schwachstellen — von Injection über Broken Access Control bis zu Server-Side Request Forgery — wird regelmäßig aktualisiert und dient als Mindeststandard für jede Webanwendung. Wer die OWASP Top 10 nicht kennt, sollte keine Software für das Internet entwickeln.

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) 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. In den USA ist SSDF für Zulieferer der Bundesbehörden verpflichtend.

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 enthält. Der IT-Grundschutz bildet zusammen mit ISO 27001 die Basis für viele Sicherheitskonzepte in Deutschland. Der Baustein DER.4 ergänzt diesen Rahmen um ein strukturiertes Notfallmanagement — ein IT-Notfallplan stellt sicher, dass auch bei schwerwiegenden Ausfällen der Wiederanlauf geordnet verläuft.

Sichere Softwareentwicklung und ISO 27001

Die Norm ISO 27001:2022 macht sichere Softwareentwicklung nicht nur empfehlenswert, sondern — für zertifizierte Organisationen — verbindlich. Die relevanten Controls finden sich in Annex A, Kategorie 8 (Technologische Controls).

Control 8.25 (Secure Development Lifecycle) verlangt, dass Sicherheitsregeln für die Softwareentwicklung definiert und angewendet werden. Control 8.28 (Secure Coding) konkretisiert dies auf Code-Ebene: sichere Programmierpraktiken, Vermeidung bekannter Schwachstellenmuster, Nutzung von Sicherheitsbibliotheken. Control 8.26 (Application Security Requirements) fordert die Erhebung von Sicherheitsanforderungen bei jeder neuen Anwendung. Wer ISO 27001 zertifiziert ist, muss nachweisen, dass diese Controls im Entwicklungsalltag gelebt werden — nicht nur auf dem Papier.

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.

Code-Review-Prozesse. Fragen Sie, wie Code Reviews organisiert sind: Gibt es ein Vier-Augen-Prinzip? Werden Sicherheitsaspekte explizit geprüft? Werden automatisierte Tools eingesetzt?

Umgang mit Abhängigkeiten. 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.

Weiterführende Informationen

Hinweis: Dieser Beitrag dient der allgemeinen Information und stellt keine Rechtsberatung dar. Für verbindliche Auskünfte zu regulatorischen Anforderungen empfehlen wir die Konsultation einer spezialisierten Rechtsberatung.