Sicherer Softwarelebenszyklus

Sichere Entwicklung

Sichere Entwicklung berücksichtigt Sicherheit über den gesamten Lebenszyklus der Software. Sie beginnt bei der Planung und läuft über Design, Code und Release bis in den Betrieb. Ein letzter Scan reicht nicht.

Das Ziel ist einfach: Probleme finden, solange Änderungen noch leicht sind. Und nach dem Release weiterlernen.

Sicherheit ist ein Regelkreis, keine Ziellinie

Jedes Release beruht auf Entscheidungen. Was darf die Software tun? Welche Daten darf sie verarbeiten? Wer darf sensible Aktionen ausführen? Wie erkennt und behebt das Team spätere Probleme? Sichere Entwicklung macht diese Fragen sichtbar.

Das Secure Software Development Framework von NIST bündelt die Arbeit in vier Ergebnisse. Die Organisation bereitet sich vor. Sie schützt Software und Entwicklungsumgebung. Sie erzeugt gut abgesicherte Releases und reagiert auf Schwachstellen. Das Framework ergänzt eine vorhandene Entwicklungsmethode. Es ersetzt sie nicht. Ein Zweierteam und ein regulierter Konzern können dieselben Grundideen in unterschiedlicher Tiefe anwenden.

OWASP SAMM betrachtet Sicherheit ebenfalls als laufende Aufgabe in Governance, Design, Implementierung, Prüfung und Betrieb. Ein später Test repariert keine unklare Anforderung. Und ein guter Entwurf schützt kein System, das niemand überwacht oder aktualisiert.

Die bessere Frage ist nicht: 'Hat Security das freigegeben?' Sondern: 'Welches Risiko senken wir, welche Nachweise haben wir und wer trägt die Entscheidung?'

Ein praktikabler Lebenszyklus für sichere Entwicklung

Die Schritte überlappen sich und wiederholen sich. Eine kleine Änderung dauert vielleicht nur Stunden. Ein kritisches System braucht formale Reviews. Die grundlegenden Entscheidungen bleiben gleich.

01 · Planen
Beschreibe das gewünschte Verhalten, sensible Daten, Nutzer und mögliche Missbrauchsfälle. Formuliere wichtige Risiken als Anforderungen, die sich später prüfen lassen.
02 · Entwerfen
Zeichne Datenflüsse und Vertrauensgrenzen und überleg dann, was schiefgehen könnte. Wähle sichere Voreinstellungen, geringe Berechtigungen und einfache Wiederherstellungswege, bevor die Implementierung Architekturänderungen teuer macht.
03 · Umsetzen
Nutze gepflegte Frameworks und etablierte Kontrollen für Identität, Autorisierung, Eingaben, Secrets und Kryptografie. Halte Änderungen überschaubar und erfinde keine eigenen Sicherheitsmechanismen ohne guten Grund.
04 · Reviewen
Ein Review betrachtet Anforderungen, Entwurfsannahmen, Code, Tests und Konfiguration gemeinsam. Werkzeuge können die Aufmerksamkeit lenken. Geschäftsregeln und den konkreten Kontext muss weiterhin ein Mensch bewerten.
05 · Verifizieren
Teste die Sicherheitsanforderungen. Ergänze statische Analyse, Prüfungen von Abhängigkeiten und Secrets sowie gezielte manuelle Tests. Ein grünes Tool allein ist noch kein Ergebnis.
06 · Bauen und ausliefern
Schütze Repositories, Build-Worker, Zugangsdaten und Artefakte. Halte fest, aus welchem Quellcode und welchen Abhängigkeiten das Release entstand. Erzwinge Reviews und Regeln, und liefere mit sicherer Konfiguration und einem getesteten Rollback aus.
07 · Betreiben
Überwache relevante Sicherheitsereignisse, ohne Secrets zu loggen. Pflege Abhängigkeiten und biete einen Meldeweg für Probleme. Die Verantwortung endet nicht mit dem Release.
08 · Lernen und verbessern
Nutze Schwachstellen, Vorfälle, Beinahefehler und störende Alarme als Rückmeldung. Behebe zuerst den konkreten Defekt. Verbessere danach die zugrunde liegende Anforderung, den Test oder die Voreinstellung. Passe auch die Praxis an, die eine Wiederholung ermöglicht hat.

Wo klare Entscheidungen besonders wichtig sind

Einige Entscheidungen brauchen klare Verantwortliche. Frameworks und Scanner können sie dem Team nicht abnehmen.

Identität und Zugriff

Leg fest, wer was in welchem Bereich tun darf. Benenne auch die geltenden Bedingungen. Authentisierung stellt die Identität fest. Autorisierung muss sensible Aktionen und Objekte trotzdem einzeln schützen.

Eingaben und Abläufe

Validiere nicht vertrauenswürdige Daten an der Servergrenze und teste, wie sich gültige Aktionen kombinieren oder umordnen lassen. Fehler in der Geschäftslogik sehen für generische Werkzeuge oft unauffällig aus.

Secrets und Kryptografie

Halte Zugangsdaten aus Quellcode und Logs heraus, begrenze Zugriffe und rotiere sie kontrolliert. Nutze etablierte Bibliotheken und verwaltete Bausteine statt eigener Algorithmen.

Abhängigkeiten und Builds

Kenne die Komponenten und Build-Schritte eines Releases. Spiele Updates zeitnah ein, prüfe die Kompatibilität und halte einen Rollback bereit.

Konfiguration und Deployment

Mach die sicherste praktikable Konfiguration zum Standard. Trenne Umgebungen und begrenze Produktionszugriffe. Prüfe außerdem die Automatisierung. Sie muss die beabsichtigten Regeln umsetzen und darf nicht nur Dateien verschieben.

Logging und Reaktion

Entscheide, welche Ereignisse Missbrauch oder versagende Kontrollen sichtbar machen. Lege die Aufbewahrungsdauer der Nachweise und die Empfänger von Signalen fest. Plane auch die Eindämmung und Korrektur einer verwundbaren Version. Die Kommunikation gehört ebenfalls dazu.

Beispiel: Export von Kundendaten

Ein kleines SaaS-Team baut einen CSV-Export für Kundendaten. Nur aktuelle Administratoren dürfen Daten ihres eigenen Mandanten exportieren. Jeder Export muss nachvollziehbar sein, große Exporte brauchen Grenzen und temporäre Dateien dürfen nicht liegen bleiben.

Im Entwurf zeichnet das Team Browser, API, Datenbank, temporären Speicher und Downloadpfad ein. Es betrachtet gestohlene Sitzungen und veränderte Mandanten-IDs. Auch Formel-Injection, wiederholte Exporte und unerlaubte Felder spielen eine Rolle. Die Datenbankabfrage wird an den authentisierten Mandanten gebunden. Die erlaubten Spalten stehen auf einer Positivliste. Das System streamt die Datei und protokolliert den Export. Die Nutzdaten landen nicht im Log.

Die Implementierung nutzt die vorhandene Autorisierungsfunktion und eine gepflegte CSV-Bibliothek. Das Review gleicht den Code mit den Anforderungen ab. Die Tests prüfen einen normalen Export und einen Nutzer ohne Adminrolle. Sie decken auch fremde Mandanten-IDs, entzogene Rollen, gefährliche Zellpräfixe, Größenlimits und Logging ab. Prüfungen von Abhängigkeiten und Secrets liefern zusätzliche Hinweise. Sie ersetzen diese fachlichen Tests nicht.

Nach dem Release beobachtet das Team Exportvolumen und Fehler. Taucht später ein neuer Sonderfall auf, korrigiert es den Code und ergänzt einen Regressionstest.

Häufige Fehler und echte Abwägungen

Security-Arbeit kann zum Ritual werden, ohne brauchbare Nachweise zu liefern. Abwägungen sollten deshalb sichtbar und überprüfbar bleiben.

Den Scanner mit dem Prozess verwechseln

Automatisierte Prüfungen finden wiederholbare Muster. Sie definieren weder das Vertrauensmodell des Produkts noch verstehen sie Besitzregeln oder entscheiden, ob sich ein fachlicher Ablauf missbrauchen lässt.

Alles nach links verschieben

Frühe Rückmeldung ist meist günstiger umzusetzen, doch manche Hinweise entstehen erst im laufenden System. Monitoring, Schwachstellenannahme, Patching und Lernen aus Vorfällen lassen sich nicht durch Entwurfsarbeit ersetzen.

Ein Framework eins zu eins kopieren

SSDF, SAMM und ASVS liefern Struktur und Abdeckung, keine universelle Aufgabenliste. Kleine Teams sollten Kontrollen nach Architektur und Risiko wählen, Auslassungen dokumentieren und den Prozess ausbauen, sobald neue Erkenntnisse es nötig machen.

Severity-Scores entscheiden lassen

Ein allgemeiner technischer Wert kennt weder die Bedeutung der Daten noch die Erreichbarkeit einer Kontrolle oder die Folgen für Kunden. Priorisierung braucht Systemkontext und eine klar verantwortliche Person.

Patches ohne Änderungskontrolle

Ein aufgeschobenes Sicherheitsupdate verlängert die Exposition. Eine blinde Installation kann dagegen die Produktion stören. Gute Abhängigkeitspflege verbindet Inventar, zeitnahe Bewertung, Kompatibilitätstests, gestufte Auslieferung und Rollback.

Sicherheit einer Fachperson zuweisen

Spezialisten liefern Tiefe und unabhängige Prüfung. Entwickler, Produktverantwortliche, Betrieb und Führung kontrollieren jedoch unterschiedliche Entscheidungen. Verantwortung lässt sich nicht an einem einzelnen Gate abgeben.

Grenzen, Verantwortung und Verhältnismäßigkeit

Kein Framework, Werkzeug oder Zertifikat beweist, dass Software sicher ist. Nachweise gelten für eine bestimmte Version, Konfiguration, Umgebung und Annahme. Mit jeder Änderung verlieren sie an Aussagekraft.

Der Aufwand sollte zum Risiko passen. Ein kleines internes Werkzeug braucht weniger Formalität als sicherheitskritische Software. Klare Zuständigkeiten für Zugriff, Daten, Änderungen und Vorfälle braucht es trotzdem.

Automatisierung soll gute Entscheidungen leichter wiederholbar machen. Menschen legen Anforderungen fest, genehmigen Ausnahmen, akzeptieren Restrisiken und reagieren, wenn sich das System anders verhält als geplant.

Für jede wesentliche Sicherheitsentscheidung eine verantwortliche Person benennen
Annahmen und Nachweise festhalten, nicht nur Freigaben
Ausnahmen eng, befristet und sichtbar machen
Rückmeldungen aus dem Betrieb mit der Entwicklung verbinden
Kontrollen bei veränderter Technik oder Auswirkung neu bewerten

Das Wichtigste in Kürze

01Baue Sicherheit in die Entwicklungsmethode ein, die du bereits nutzt.
02Formuliere wichtige Risiken vor dem Coding als klare Anforderungen.
03Kombiniere Design-Reviews, Werkzeuge, gezielte Tests und Rückmeldungen aus dem Betrieb.
04Schütze den Buildpfad genauso sorgfältig wie den Anwendungscode.
05Passe Kontrollen an das Risiko an und dokumentiere jede wichtige Ausnahme.
06Nutze Schwachstellen und Vorfälle, um das nächste Release zu verbessern.

Quellen und weiterführende Literatur

Eine kompakte Auswahl an Primärquellen, Standards und öffentlich zugänglicher technischer Orientierung, auf die sich dieser Artikel stützt.