Sichere Softwareentwicklung

Sichere Softwareentwicklung integriert Sicherheit in jede Phase der Softwareerstellung – von der Bedrohungsmodellierung und dem sicheren Design über Codierungsstandards, Tests und Überprüfung – sodass Schwachstellen verhindert und nicht erst nach der Veröffentlichung behoben werden.

Definition

Sichere Softwareentwicklung ist die Disziplin, Sicherheitsaktivitäten und -kontrollen während des gesamten Softwareentwicklungslebenszyklus zu integrieren, um die Anzahl und Schwere von Schwachstellen in ausgelieferter Software zu reduzieren.

Scope

Dieses Thema behandelt die Praktiken und Prozesse, die sichere Software hervorbringen: Bedrohungsmodellierung, sichere Designprinzipien, sichere Codierungsstandards, statische und dynamische Analyse, Fuzzing, Sicherheitstests, Code-Reviews sowie den sicheren Entwicklungslebenszyklus und DevSecOps. Es befasst sich mit der Sicherheit von Lieferketten und Abhängigkeiten. Ausgenommen sind die offensive Untersuchung von Exploits und die Analyse von Malware nach der Veröffentlichung, die in verwandten Themen behandelt werden.

Core questions

• Wie wird Sicherheit von Anfang an in Software integriert, anstatt sie nachträglich hinzuzufügen?
• Was ist Bedrohungsmodellierung und wie leitet sie sicheres Design an?
• Wie finden statische Analyse, dynamische Analyse und Fuzzing Schwachstellen vor der Veröffentlichung?
• Wie werden sichere Entwicklungsaktivitäten in moderne CI/CD-Pipelines (DevSecOps) eingebettet?
• Wie werden Risiken durch Abhängigkeiten von Drittanbietern und die Software-Lieferkette gemanagt?

Key concepts

• Bedrohungsmodellierung
• sichere Designprinzipien
• sichere Codierungsstandards
• statische Anwendungssicherheitsprüfung (SAST)
• dynamische Analyse (DAST)
• Fuzzing
• Code-Review
• sicherer Entwicklungslebenszyklus
• Sicherheit der Lieferkette

Key theories

Sicherheitsentwicklungslebenszyklus

Ein strukturierter Prozess integriert Sicherheitstore in jede Entwicklungsphase – Anforderungen, Design (Bedrohungsmodellierung), Implementierung (sichere Codierung, Analyse), Verifizierung (Tests, Fuzzing) und Freigabe – und reduziert messbar die Anzahl der ausgelieferten Schwachstellen.

Shift-Left und automatisierte Absicherung

Das frühzeitige Auffinden und Beheben von Fehlern ('Shift-Left') ist weitaus kostengünstiger als nach der Bereitstellung; automatisierte statische/dynamische Analyse und Fuzzing, die in die kontinuierliche Integration eingebettet sind, bieten skalierbare, wiederholbare Absicherung.

Mechanisms

Die sichere Entwicklung beginnt mit der Bedrohungsmodellierung (z. B. STRIDE), um potenzielle Probleme zu identifizieren, was ein Design informiert, das das Prinzip des geringsten Privilegs und der Verteidigung in der Tiefe anwendet. Während der Implementierung kennzeichnen sichere Codierungsstandards und statische Analyse riskante Muster, während dynamische Analyse und Fuzzing das laufende Programm mit fehlerhaften Eingaben testen, um Abstürze und Speicherfehler aufzudecken. Code-Reviews und Sicherheitstests gehen der Veröffentlichung voraus, und in DevSecOps laufen diese Prüfungen automatisch in der Build-Pipeline ab, wobei Abhängigkeitsscans und signierte Builds die Lieferkette schützen.

Clinical relevance

Sichere Entwicklung bestimmt die grundlegende Sicherheit nahezu aller Software, die Menschen nutzen. Die Einführung des SDL durch Microsoft nach 2002 reduzierte die Schwachstellen in seinen Produkten erheblich, kontinuierliches Fuzzing (Googles OSS-Fuzz) findet Tausende von Fehlern in weit verbreitetem Open-Source-Code, und Lieferkettenpraktiken wurden nach Angriffen wie SolarWinds und Log4Shell dringend. Diese Praktiken prägen regulatorische Erwartungen und Beschaffungsanforderungen.

Evidence & guidelines

Zu den Frameworks gehören das Microsoft SDL, OWASP SAMM und ASVS, BSIMM (eine Messung realer Programme) und das Secure Software Development Framework (SSDF, SP 800-218) des NIST. Die US-amerikanische Exekutivanweisung verlangt nun eine SSDF-Bestätigung für staatliche Softwarelieferanten, und SBOM-Standards (Software Bill of Materials) unterstützen die Transparenz der Lieferkette.

History

Die sichere Entwicklung entstand aus der Erkenntnis Ende der 1990er und Anfang der 2000er Jahre, dass das Patchen ausgelieferter Software nicht skalierbar war. Microsofts Initiative „Trustworthy Computing“ von 2002 führte zum Security Development Lifecycle, und McGraws „Software Security“ (2006) kodifizierte das „building security in“. In den 2010er Jahren wurden diese Praktiken in agile und DevOps-Workflows (DevSecOps) integriert und nach größeren Vorfällen in der Lieferkette auf Abhängigkeiten und die Build-Integrität ausgeweitet.

Key figures

• Gary McGraw
• Michael Howard
• Steve Lipner
• Ross Anderson

Seminal works

• howard2006
• mcgraw2006
• anderson2020

Frequently asked questions

Was ist Bedrohungsmodellierung?

Bedrohungsmodellierung ist eine strukturierte Analyse, die während des Designs durchgeführt wird, um zu ermitteln, was ein Angreifer angreifen könnte und wie. Teams erstellen Systemdiagramme, listen Bedrohungen auf (oft mit einer Checkliste wie STRIDE) und entscheiden über Gegenmaßnahmen, bevor Code geschrieben wird, sodass Sicherheit in die Architektur integriert wird.

Warum reicht ein Sicherheitsscanner nicht aus?

Automatisierte Scanner erkennen viele bekannte Muster, übersehen jedoch Designfehler, Geschäftslogikfehler und neuartige Probleme und erzeugen Fehlalarme. Effektive Programme kombinieren automatisierte Analyse mit Bedrohungsmodellierung, manueller Überprüfung und Tests über den gesamten Lebenszyklus hinweg.