Richtlinie zur Softwareentwicklung: Secure Development Lifecycle

Warum Softwareentwicklung eine Sicherheitsrichtlinie braucht

Software ist überall. Ob dein Unternehmen eigene Anwendungen entwickelt, individuelle Anpassungen an Standardsoftware vornimmt oder externe Entwickler beauftragt: Irgendwo im Unternehmen entsteht Code, und dieser Code kann Schwachstellen enthalten.

Die Realität sieht in vielen Unternehmen so aus: Entwickler schreiben Code nach bestem Wissen, Sicherheit wird als Thema wahrgenommen, aber nicht systematisch adressiert. Penetrationstests finden statt, aber erst kurz vor dem Go-Live, wenn Änderungen teuer und zeitaufwändig sind. Drittanbieter-Bibliotheken werden eingebunden, ohne deren Sicherheitsstatus zu prüfen. Entwicklungsumgebungen haben Zugriff auf Produktivdaten, weil es bequemer ist.

Eine Richtlinie zur sicheren Softwareentwicklung setzt genau hier an. Sie definiert verbindliche Regeln für den gesamten Entwicklungslebenszyklus und stellt sicher, dass Sicherheit nicht dem Zufall, der individuellen Kompetenz einzelner Entwickler oder dem Zeitdruck vor einem Release überlassen bleibt.

Was die Normen fordern

ISO 27001

ISO 27001 Annex A enthält mehrere Controls, die direkt auf die Softwareentwicklung abzielen:

A.8.25 Secure Development Life Cycle: Regeln für die sichere Entwicklung von Software und Systemen müssen etabliert und angewendet werden. Das ist der Kern der Richtlinie.

A.8.26 Application Security Requirements: Sicherheitsanforderungen müssen bei der Entwicklung oder Beschaffung von Anwendungen identifiziert, spezifiziert und genehmigt werden.

A.8.27 Secure System Architecture and Engineering Principles: Grundsätze für sichere Systemarchitektur müssen dokumentiert und angewendet werden.

A.8.28 Secure Coding: Sichere Coding-Praktiken müssen auf die Softwareentwicklung angewendet werden. Das umfasst Coding Standards, Code Reviews und automatisierte Sicherheitsprüfungen.

Zusätzlich relevant: A.8.8 Management of Technical Vulnerabilities (Schwachstellenmanagement) und A.8.9 Configuration Management (sichere Konfiguration von Entwicklungsumgebungen).

NIS2

NIS2 Artikel 21 Absatz 2 Nr. 5 fordert „Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen, einschließlich Management und Offenlegung von Schwachstellen." Das betrifft nicht nur Softwareunternehmen, sondern jedes Unternehmen, das Software entwickelt oder individuell anpassen lässt.

Geltungsbereich der Richtlinie

Die Richtlinie muss klar definieren, wofür sie gilt. Typischerweise umfasst der Geltungsbereich:

• Eigenentwicklungen (Webanwendungen, interne Tools, APIs, Skripte)
• Individuelle Anpassungen an Standardsoftware (Customizing, Plugins, Erweiterungen)
• Beauftrage Entwicklung durch externe Dienstleister
• Konfiguration und Deployment von Software
• Entwicklung von Infrastruktur als Code (IaC, Terraform, Ansible)

Nicht im Geltungsbereich sind typischerweise reine Office-Makros und einfache Automatisierungen, es sei denn, sie verarbeiten sensible Daten. Die Richtlinie sollte eine Schwelle definieren, ab der eine Entwicklungsaktivität unter die Richtlinie fällt.

Security by Design: Sicherheit von Anfang an

Das Grundprinzip der Richtlinie ist Security by Design. Das bedeutet, dass Sicherheitsanforderungen nicht am Ende des Entwicklungsprozesses geprüft, sondern am Anfang definiert werden.

Anforderungsphase

Jedes Entwicklungsprojekt beginnt mit der Definition von Anforderungen, und Sicherheitsanforderungen gehören dazu. Die Richtlinie legt fest, dass für jedes Projekt eine Sicherheitsbewertung der Anforderungen stattfindet:

• Welche Daten verarbeitet die Anwendung, und wie sind sie klassifiziert?
• Welche Authentifizierungs- und Autorisierungsmechanismen werden benötigt?
• Welche Verschlüsselungsanforderungen bestehen (Transport, Speicherung)?
• Welche Compliance-Anforderungen gelten (DSGVO, branchenspezifische Vorgaben)?
• Welche Schnittstellen gibt es zu anderen Systemen, und wie werden sie abgesichert? Hinweise zur API-Sicherheit helfen bei der Absicherung externer Schnittstellen.

Die Ergebnisse werden als Sicherheitsanforderungen dokumentiert und fließen in die Spezifikation ein. Bei Projekten mit hohem Schutzbedarf empfiehlt die Richtlinie ein Threat Modeling, das systematisch potenzielle Bedrohungen identifiziert und Gegenmaßnahmen definiert.

Architektur und Design

Die Richtlinie definiert Architekturprinzipien, die bei der Systementwicklung eingehalten werden müssen:

Least Privilege: Jede Komponente, jeder Dienst und jeder Benutzer erhält nur die minimal notwendigen Berechtigungen.

Defense in Depth: Sicherheit wird in mehreren Schichten implementiert, nicht auf eine einzelne Maßnahme verlassen.

Fail Secure: Im Fehlerfall fällt das System in einen sicheren Zustand, nicht in einen offenen.

Separation of Concerns: Sicherheitskritische Funktionen (Authentifizierung, Autorisierung, Kryptografie) werden als eigenständige Module implementiert, nicht über die Anwendung verstreut.

Minimale Angriffsfläche: Nur die notwendigen Funktionen, Ports und Schnittstellen werden exponiert. Alles andere bleibt geschlossen.

Secure Coding Guidelines

Die Richtlinie verweist auf oder enthält Secure Coding Guidelines, die für alle Entwickler verbindlich sind. Diese Guidelines orientieren sich an etablierten Standards wie den OWASP Top 10, dem OWASP Application Security Verification Standard (ASVS) und den CWE Top 25.

Zentrale Secure Coding Regeln

Input-Validierung: Alle externen Eingaben werden validiert, gefiltert und bereinigt. Vertraue keiner Eingabe, die von außen kommt, egal ob sie von einem Benutzerformular, einer API, einer Datei oder einer Datenbank stammt.

Output-Encoding: Alle Ausgaben werden kontextgerecht kodiert, um Injection-Angriffe (XSS, SQL-Injection, Command-Injection) zu verhindern.

Authentifizierung und Session-Management: Verwende bewährte Authentifizierungsbibliotheken, keine Eigenentwicklungen. Sessions müssen serverseitig verwaltet, Tokens kryptografisch sicher generiert und Session-Fixation verhindert werden.

Autorisierung: Berechtigungsprüfungen erfolgen serverseitig bei jedem Zugriff, nicht nur im Frontend. IDOR-Schwachstellen (Insecure Direct Object Reference) werden durch konsistente Autorisierungsprüfungen verhindert.

Kryptografie: Verwende ausschließlich etablierte, aktuelle Algorithmen und Bibliotheken. Keine eigenen kryptografischen Verfahren implementieren. Schlüssel werden sicher erzeugt, gespeichert und rotiert.

Fehlerbehandlung und Logging: Fehlermeldungen an Benutzer enthalten keine technischen Details, die einem Angreifer nützlich sein könnten (Stack-Traces, Datenbankabfragen, interne Pfade). Sicherheitsrelevante Ereignisse werden geloggt: fehlgeschlagene Authentifizierungen, Autorisierungsverletzungen, Eingabevalidierungsfehler.

Secrets Management: Zugangsdaten, API-Keys, Zertifikate und andere Geheimnisse gehören nicht in den Quellcode, nicht in Konfigurationsdateien im Repository und nicht in Container-Images. Die Richtlinie verweist auf einen Secrets Manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault o.ä.).

Sicherheit in der CI/CD-Pipeline

Moderne Softwareentwicklung nutzt automatisierte Build- und Deployment-Pipelines (CI/CD). Die Richtlinie muss definieren, welche Sicherheitsprüfungen in diese Pipeline integriert werden.

Static Application Security Testing (SAST)

SAST-Tools analysieren den Quellcode auf bekannte Schwachstellenmuster, ohne die Anwendung auszuführen. Sie finden SQL-Injections, XSS-Anfälligkeiten, unsichere Kryptografie und ähnliche Probleme direkt im Code.

Die Richtlinie legt fest, dass SAST-Scans bei jedem Build oder Pull Request automatisch ausgeführt werden. Kritische Findings blockieren den Build und müssen vor dem Merge behoben werden.

Software Composition Analysis (SCA)

SCA-Tools prüfen die eingesetzten Drittanbieter-Bibliotheken und Frameworks auf bekannte Schwachstellen (CVEs). Angesichts der Tatsache, dass moderne Anwendungen zu 70-90 Prozent aus Drittanbieter-Code bestehen, ist das unverzichtbar.

Die Richtlinie legt fest, dass SCA-Scans regelmäßig und automatisiert durchgeführt werden, dass Bibliotheken mit bekannten kritischen Schwachstellen nicht in die Produktion gelangen dürfen und dass ein Prozess für die zeitnahe Aktualisierung betroffener Abhängigkeiten existiert.

Dynamic Application Security Testing (DAST)

DAST-Tools testen die laufende Anwendung von außen, wie ein Angreifer es tun würde. Sie finden Schwachstellen, die SAST nicht erkennen kann, z.B. Konfigurationsfehler, fehlende Security-Header oder Authentifizierungsprobleme.

Die Richtlinie empfiehlt DAST-Scans in der Staging-Umgebung vor jedem Release und definiert, wie mit den Ergebnissen umzugehen ist.

Penetrationstests

Für Anwendungen mit hohem Schutzbedarf fordert die Richtlinie zusätzlich manuelle Penetrationstests durch qualifizierte Tester. Die Häufigkeit richtet sich nach dem Risikoprofil: jährlich für geschäftskritische Anwendungen, bei jedem Major Release oder bei wesentlichen architekturellen Änderungen.

Entwicklungsumgebungen absichern

Die Richtlinie adressiert auch die Sicherheit der Entwicklungsumgebungen selbst:

Trennung der Umgebungen: Entwicklung, Test, Staging und Produktion sind strikt voneinander getrennt. Entwickler haben keinen direkten Zugriff auf Produktivsysteme.

Keine Produktivdaten in Entwicklungsumgebungen: Wenn Tests realistische Daten erfordern, werden anonymisierte oder synthetische Testdaten verwendet. Personenbezogene oder vertrauliche Produktivdaten haben in Entwicklungs- und Testumgebungen nichts zu suchen.

Zugangskontrolle: Zugang zu Repositories, Build-Servern und Deployment-Tools ist nach dem Least-Privilege-Prinzip geregelt. Nur wer am Projekt arbeitet, hat Zugang zum Repository.

Branch Protection: Die Richtlinie fordert Branch-Protection-Regeln für den Hauptbranch: Keine direkten Commits, nur Merges nach Code Review und erfolgreichen automatisierten Tests.

Code Reviews und Peer Reviews

Automatisierte Tools finden viele, aber nicht alle Schwachstellen. Code Reviews durch andere Entwickler sind eine unverzichtbare Ergänzung.

Die Richtlinie legt fest, dass jede Code-Änderung vor dem Merge in den Hauptbranch von mindestens einer weiteren Person reviewed wird. Für sicherheitskritische Module (Authentifizierung, Autorisierung, Kryptografie, Zahlungsabwicklung) empfiehlt die Richtlinie ein Review durch eine Person mit Sicherheitsexpertise.

Code Reviews sollen nicht nur die Funktionalität prüfen, sondern explizit auch Sicherheitsaspekte berücksichtigen. Eine Checkliste im Anhang der Richtlinie kann helfen:

• Werden alle Eingaben validiert?
• Erfolgen Berechtigungsprüfungen an allen relevanten Stellen?
• Sind Fehlermeldungen sicher (keine sensitiven Informationen)?
• Werden Geheimnisse korrekt behandelt?
• Sind die verwendeten Bibliotheken aktuell?
• Werden Logs korrekt geschrieben (keine sensitiven Daten loggen)?

Dependency Management

Drittanbieter-Bibliotheken sind der blinde Fleck vieler Entwicklungsorganisationen. Die Log4Shell-Schwachstelle (CVE-2021-44228) hat schmerzhaft gezeigt, was passiert, wenn eine weit verbreitete Bibliothek eine kritische Lücke enthält. Ein separater Artikel beschreibt, wie du Dependency Scanning systematisch aufbaust.

Die Richtlinie definiert folgende Anforderungen:

Inventar: Alle eingesetzten Drittanbieter-Bibliotheken werden in einem Software Bill of Materials (SBOM) dokumentiert. Tools wie Syft, CycloneDX oder SPDX automatisieren die Erstellung.

Regelmäßige Prüfung: Automatisierte SCA-Scans prüfen die Abhängigkeiten kontinuierlich auf bekannte Schwachstellen.

Update-Prozess: Die Richtlinie definiert Fristen für Sicherheitsupdates von Abhängigkeiten: kritische Schwachstellen innerhalb von 48 Stunden, hohe innerhalb von 14 Tagen, mittlere im nächsten regulären Release-Zyklus.

Freigabeliste: Für sicherheitskritische Anwendungen kann die Richtlinie eine Freigabeliste für Bibliotheken und Frameworks definieren. Nur geprüfte und freigegebene Abhängigkeiten dürfen eingesetzt werden.

Lizenzkonformität: Nebenbei löst ein sauberes Dependency Management auch das Thema Lizenzkonformität mit, das bei der Nutzung von Open-Source-Komponenten ebenfalls relevant ist.

Deployment und Release-Management

Die Richtlinie regelt auch den Übergang von der Entwicklung in die Produktion:

Automatisiertes Deployment: Deployments erfolgen über die CI/CD-Pipeline, nicht manuell. Manuelle Eingriffe auf Produktivsystemen sind nur im dokumentierten Notfall zulässig.

Release-Freigabe: Vor jedem Release in die Produktivumgebung erfolgt eine Freigabe, die bestätigt, dass alle definierten Sicherheitsprüfungen bestanden wurden: SAST, SCA, DAST (wenn anwendbar), Code Review, Funktionstests.

Rollback-Fähigkeit: Jedes Deployment muss rückgängig gemacht werden können. Die Richtlinie fordert, dass Rollback-Verfahren dokumentiert und getestet sind.

Change Management: Änderungen an Produktivsystemen werden im Rahmen des Change-Management-Prozesses dokumentiert und nachvollziehbar.

Externe Entwicklung

Wenn externe Dienstleister Software im Auftrag entwickeln, gelten die gleichen Sicherheitsanforderungen. Eine Lieferanten-Sicherheitsrichtlinie bildet den übergeordneten Rahmen für alle Anforderungen an Dritte. Die Richtlinie legt fest:

• Externe Entwickler werden auf die Secure Coding Guidelines verpflichtet.
• Der Code externer Entwickler unterliegt den gleichen Review- und Testanforderungen.
• Vor der Übernahme in die Produktivumgebung wird der Code intern geprüft (Sicherheitsaudit).
• Vertragliche Regelungen stellen sicher, dass Sicherheitsanforderungen eingehalten und Schwachstellen zeitnah behoben werden.
• Die Rechte am Quellcode und die Pflicht zur Schwachstellenbehebung sind vertraglich geregelt.

Beispielgliederung

1. Zweck und Geltungsbereich
2. Begriffe und Definitionen - SDLC, SAST, DAST, SCA, SBOM
3. Normative Grundlagen - ISO 27001 A.8.25-A.8.28, NIS2 Art. 21 Nr. 5, OWASP
4. Grundsätze - Security by Design, Least Privilege, Defense in Depth
5. Sicherheitsanforderungen in der Planungsphase - Threat Modeling, Datenklassifizierung
6. Architektur- und Designprinzipien
7. Secure Coding Guidelines - Eingabevalidierung, Output-Encoding, Kryptografie, Secrets
8. Code Reviews - Ablauf, Checkliste, Sicherheitsreview
9. Automatisierte Sicherheitsprüfungen - SAST, SCA, DAST in der CI/CD-Pipeline
10. Dependency Management - SBOM, Update-Fristen, Freigabeliste
11. Entwicklungsumgebungen - Trennung, Zugangskontrolle, Testdaten
12. Deployment und Release - Automatisierung, Freigabe, Rollback
13. Penetrationstests - Häufigkeit, Umfang, Nachbehandlung
14. Externe Entwicklung - Anforderungen, Verträge, Codeübernahme
15. Verantwortlichkeiten
16. Schulung und Awareness - Entwicklerschulungen, Frequenz
17. Ausnahmen und Risikoakzeptanz
18. Überprüfung und Aktualisierung
19. Inkrafttreten und Freigabe

Von der Richtlinie zur Entwicklungskultur

Eine Secure-Development-Richtlinie kann nur wirken, wenn sie von den Entwicklern verstanden und akzeptiert wird. Sicherheit darf nicht als bürokratisches Hindernis wahrgenommen werden, das die Entwicklung ausbremst, sondern als Qualitätsmerkmal, das professionelle Softwareentwicklung auszeichnet.

Regelmäßige Schulungen zu sicherer Entwicklung, Austausch über aktuelle Schwachstellen und ein Security-Champion-Programm (ein Entwickler pro Team, der als Sicherheitsansprechpartner fungiert) helfen, Sicherheit als Teil der Entwicklungskultur zu verankern.

ISMS Lite bildet den kompletten Richtlinien-Lifecycle ab: Du erstellst die Secure-Development-Richtlinie (bei Bedarf mit KI-Unterstützung), versionierst jede Änderung, holst die Kenntnisnahme der Entwickler ein und lässt die Geschäftsführung per Unterschrift freigeben. So hast du jederzeit den Nachweis, dass dein Unternehmen sichere Softwareentwicklung nicht nur proklamiert, sondern dokumentiert und verbindlich geregelt hat.

Weiterführende Artikel

• Schwachstellenmanagement aufbauen: Prozess, Tools und Praxis
• Patch-Management im Mittelstand: Systematisch statt reaktiv
• Change-Management im ISMS: Änderungen sicher steuern
• Klassifizierungsrichtlinie: Vertraulich, Intern, Öffentlich
• Richtlinien-Lifecycle: Von der Erstellung bis zur Außerkraftsetzung