Einleitung

Webanwendungen sind das Einfallstor Nummer eins für Cyberangriffe. Doch oft scheitert die Sicherheit nicht an der Technik, sondern an unklaren Anforderungen bei der Vergabe. Das Bundesamt für Sicherheit in
der Informationstechnik (BSI) liefert mit seinem Leitfaden für Auftraggeber einen Werkzeugkasten, um IT-Sicherheit vom „Nice-to-have" zum harten Vertragskriterium zu machen.

Ein Fachartikel zur Umsetzung der BSI-Vorgaben für sichere Webanwendungen

Wenn das böse Erwachen zu spät kommt

Wer heute eine Webanwendung beauftragt, erlebt oft ein böses Erwachen kurz vor dem Go-live: Der Penetrationstest fördert kritische Lücken zutage, der Launch verschiebt sich, die Kosten explodieren. Die
Ursache liegt meist Monate zurück – in der Ausschreibungsphase, wo „Sicherheit nach Stand der Technik" als floskelhafter Einzeiler im Lastenheft verloren geht.

Um diesem Problem zu begegnen, hat das BSI 2013 den „Leitfaden zur Entwicklung sicherer Webanwendungen – Empfehlungen und Anforderungen an Auftraggeber" entwickelt. Er flankiert das Dokument für Auftragnehmer
und zielt darauf ab, den Secure Software Development Lifecycle (SSDL) vertraglich zu verankern. Das zentrale Anliegen: Sicherheit muss vom „Nice-to-have" zum harten, prüfbaren Vertragskriterium werden.

Shift Left: Sicherheit beginnt vor dem ersten Sprint

Die Kernbotschaft des BSI-Papiers ist der paradigmatische „Shift Left": Sicherheitsüberlegungen müssen an den absoluten Anfang des Beschaffungsprozesses wandern – noch bevor die erste Zeile der
Ausschreibung (etwa nach UfAB-Standard) geschrieben wird. Dieser Ansatz steht im Einklang mit modernen DevSecOps-Praktiken, wonach Sicherheit nicht nachträglich „eingebaut", sondern von Anfang an mitgedacht
werden muss.

Schutzbedarfsfeststellung: Die Pflicht vor der Kür

Der erste Schritt ist die Schutzbedarfsfeststellung. Der Auftraggeber muss definieren, welche Daten verarbeitet werden und wie schwerwiegend eine Verletzung der Vertraulichkeit, Integrität oder
Verfügbarkeit wäre. Das BSI unterscheidet hierbei zwischen drei Kategorien:

• Normal: Schadensauswirkungen begrenzt und überschaubar
• Hoch: Schadensauswirkungen beträchtlich
• Sehr hoch: Schadensauswirkungen existenziell bedrohlich

Diese Einstufung ist kein bürokratischer Selbstzweck, sondern der Hebel für die späteren Anforderungen: Ein Portal für Bürgerdaten erfordert zwingend härtere Maßnahmen (z. B. Zwei-Faktor-Authentifizierung,
HSM-Einsatz für Schlüsselverwaltung, verschlüsselte Datenübertragung) als eine reine Informationswebseite ohne Datenverarbeitung.

Schadensszenarien als Bewertungsgrundlage

Zur Bewertung schlägt das BSI konkrete Schadensszenarien vor, die mindestens betrachtet werden müssen:

1. Verstoß gegen Gesetze/Vorschriften/Verträge
- Normal: Verstöße mit geringfügigen Konsequenzen, geringfügige Vertragsverletzungen mit maximalen geringen Konventionalstrafen
- Hoch: Verstöße mit erheblichen Konsequenzen, Vertragsverletzungen mit hohen Konventionalstrafen
- Sehr hoch: Fundamentale Verstöße gegen Vorschriften und Gesetze, Vertragsverletzungen mit ruinösen Haftungsschäden

2. Beeinträchtigung des informationellen Selbstbestimmungsrechts
- Normal: Personenbezogene Daten, deren Verarbeitung den Betroffenen in seiner gesellschaftlichen Stellung oder wirtschaftlichen Verhältnissen beeinträchtigen kann
- Hoch: Personenbezogene Daten, deren Verarbeitung den Betroffenen erheblich beeinträchtigen kann
- Sehr hoch: Personenbezogene Daten, bei deren Verarbeitung eine Gefahr für Leib und Leben oder die persönliche Freiheit des Betroffenen gegeben ist

3. Beeinträchtigung der persönlichen Unversehrtheit
- Normal: Eine Beeinträchtigung erscheint nicht möglich
- Hoch: Eine Beeinträchtigung kann nicht absolut ausgeschlossen werden
- Sehr hoch: Gravierende Beeinträchtigungen sind möglich, Gefahr für Leib und Leben

4. Beeinträchtigung der Aufgabenerfüllung
- Normal: Die Beeinträchtigung wäre tolerabel, maximal tolerierbare Ausfallzeit >24 Stunden
- Hoch: Die Beeinträchtigung würde von einzelnen Betroffenen als nicht tolerabel eingeschätzt, maximal tolerierbare Ausfallzeit 1-24 Stunden
- Sehr hoch: Die Beeinträchtigung würde von allen Betroffenen als nicht tolerabel eingeschätzt, maximal tolerierbare Ausfallzeit <1 Stunde

5. Negative Innen- oder Außenwirkung
- Normal: Geringe bzw. nur interne Ansehens- oder Vertrauensbeeinträchtigung
- Hoch: Breite Ansehens- oder Vertrauensbeeinträchtigung
- Sehr hoch: Landesweite Ansehens- oder Vertrauensbeeinträchtigung, eventuell existenzgefährdend

6. Finanzielle Auswirkungen
- Normal: Der finanzielle Schaden bleibt tolerabel
- Hoch: Beachtliche finanzielle Verluste, jedoch nicht existenzbedrohend
- Sehr hoch: Existenzbedrohender finanzieller Schaden

Wichtig: Der Schutzbedarf einer Webanwendung ergibt sich durch den höchsten auftretenden Schutzbedarf eines Schadensszenarios.

Eignung und Leistung: Die Spreu vom Weizen trennen

Der Leitfaden orientiert sich an den Vorgaben des Bundesministeriums des Innern („Unterlage für Ausschreibung und Bewertung von IT-Leistungen", kurz UfAB) und rät dazu, Sicherheit bereits bei der Auswahl
der Bewerber als K.o.-Kriterium zu nutzen. Hierbei wird zwischen Eignungskriterien und Leistungskriterien unterschieden.

Eignungskriterien: Der Anbieter muss können

Hier geht es um die generelle Befähigung des Auftragnehmers. Auftraggeber sollten Qualifikationsprofile der konkret eingesetzten Mitarbeiter fordern – nicht nur der Entwickler, sondern auch der
Projektleiter, QA-Manager und Security-Verantwortlichen.

Geforderte Nachweise:

• Zertifizierungen:

  • CSSLP (Certified Secure Software Lifecycle Professional)
  • Offensive Security Zertifikate (OSCP, OSWE, OSCE)
  • GIAC-Zertifizierungen (GSEC, GWAPT)
  • ISO 27001 Lead Implementer/Auditor

• Referenzen: Wurden bereits Projekte mit vergleichbarem Schutzbedarf erfolgreich (und nachweislich sicher) umgesetzt? Hier sollten konkrete Projektnamen, Ansprechpartner und der erreichte
  Sicherheitslevel dokumentiert werden.

• Ausbildung: Universitäre oder Fachhochschul-Ausbildung in IT-Sicherheit, Informatik mit Schwerpunkt Sicherheit oder vergleichbare Weiterbildungen

• Berufserfahrung: Nachweisbare Erfahrung in der sicheren Softwareentwicklung, nicht nur allgemeine Programmiererfahrung

Leistungskriterien: Der Prozess muss stimmen

Ein potenzieller Auftragnehmer muss darlegen, wie er Sicherheit in allen Phasen der Entwicklung garantiert. Ein bloßes „Wir machen das schon sicher" reicht nicht; gefordert ist der Nachweis eines
gelebten SSDL. Der Anbieter muss beschreiben, wie er Sicherheitsvorgaben (z. B. BSI IT-Grundschutz, OWASP ASVS, NIST SP 800-53) methodisch in den Entwicklungsprozess integriert.

Zu bewertende Aspekte:

• Wie werden Sicherheitsanforderungen erhoben?
• Welche Design-Prinzipien werden beim Softwareentwurf berücksichtigt?
• Existieren Secure Coding Guidelines? Auf welchen Standards basieren diese? Werden sie regelmäßig aktualisiert?
• Wie werden APIs und Frameworks ausgewählt und verwaltet?
• Welche Testverfahren kommen zum Einsatz?
• Wie wird mit Schwachstellen in Drittkomponenten umgegangen?

Das Reifegradmodell

Das BSI schlägt ein Reifegradmodell mit fünf Stufen vor, das es ermöglicht, den Entwicklungsprozess objektiv zu bewerten:

0. Nicht vorhanden
- Aktivitäten wurden nicht umgesetzt (0 % der verpflichtenden Aktivitäten)

1. Ad-Hoc (Informell)
- Aktivitäten wurden teilweise umgesetzt (>0 % bis <50 %)
- Sicherheit wird fallweise berücksichtigt, aber nicht systematisch

2. Partiell
- Aktivitäten wurden großteils umgesetzt (≥50 % bis <100 %)
- Sicherheit ist etabliert, aber nicht durchgängig

3. Vollständig (erforderliches Niveau)
- Alle verpflichtenden Aktivitäten wurden umgesetzt (100 %)
- Dies ist das empfohlene Mindestniveau für professionelle Projekte

4. Best in Class
- Alle verpflichtenden UND zusätzliche optionale Aktivitäten wurden umgesetzt
- Der Auftragnehmer geht über die Mindestanforderungen hinaus und kann sich damit von Mitbewerbern abheben

Empfehlung: Während des Entwicklungsprozesses muss der Auftragnehmer mindestens den Reifegrad „Vollständig" erfüllen, damit ein Mindestsicherheitsniveau der Webanwendung sichergestellt ist.

Der Secure Development Lifecycle im Detail

Der BSI-Leitfaden gliedert den Entwicklungsprozess in fünf Phasen, für die jeweils konkrete „Quality Gates" definiert werden. Diese Meilensteine dürfen nur bei Erfüllung definierter Sicherheitskriterien
passiert werden.

Phase 1: Initiale Planung & Vergabephase

Ziel: Sicherheit als integralen Bestandteil des Projekts verankern

Kernaktivitäten:

• Analyse der Anforderungen: Gemeinsame Überprüfung der vom Auftraggeber spezifizierten Sicherheitsanforderungen auf Vollständigkeit
• Erstellung eines Sicherheitsprojektplans: Basierend auf dem ermittelten Schutzbedarf werden alle sicherheitsrelevanten Schritte geplant
• Definition eines Ansprechpartners für Sicherheit: Benennung einer verantwortlichen Person (Security Champion)
• Durchführung eines Security Kickoffs: Vor Start der Implementierung findet ein Meeting statt, in dem alle sicherheitsrelevanten Aspekte besprochen werden
• Auswahl von Secure Coding Guidelines: Festlegung, welche Standards (z. B. OWASP Secure Coding Practices, CERT Coding Standards) verwendet werden

Quality Gate:

• Spezifikationsdokument liegt vor und deckt alle Anforderungen ab (funktionale, nicht-funktionale, Sicherheits-, Dokumentationsanforderungen)
• Alle gesetzlichen Vorgaben werden eingehalten (DSGVO, IT-Sicherheitsgesetz, branchenspezifische Regelungen)
• Entsprechende Coding Guidelines sind ausgewählt und dokumentiert
• Security-Kickoff wurde durchgeführt und dokumentiert
• Ansprechpartner für Sicherheit ist benannt

Phase 2: Konzeption & Planung

Ziel: Sicherheitsarchitektur entwickeln und Bedrohungen systematisch identifizieren

Dies ist die wichtigste Phase für die Sicherheit, da hier die Grundlagen gelegt werden. Fehler in dieser Phase sind später nur mit erheblichem Aufwand zu beheben.

2.1 Datenflussanalyse

Mit einem Datenflussdiagramm (Data Flow Diagram, DFD) wird der Datenfluss innerhalb der Software dargestellt. Dabei werden dokumentiert:

• Datenflüsse zwischen Benutzern und Systemen
• Passive Ressourcen (wo werden Daten gespeichert)
• Wie Daten klassifiziert werden (öffentlich, intern, vertraulich, streng vertraulich)
• Wie Daten verarbeitet werden (gespeichert, übertragen, angezeigt, gelöscht)

In der Folge können im Datenflussdiagramm Trust Boundaries (Vertrauensgrenzen) eingezeichnet werden – Übergänge zwischen Komponenten, die sich nicht blind vertrauen können. Für jede Schnittstelle und
jeden Übergang können dann Angriffe identifiziert werden.

2.2 Rollen- und Berechtigungskonzept

Durch ein Rollen- und Berechtigungskonzept wird dargestellt, welche Benutzer bzw. Benutzergruppen mit welchen Rechten auf Assets und Funktionen zugreifen dürfen. Die Darstellung erfolgt üblicherweise in einer
Access Control Matrix.

Beispiel:

Benutzerrolle	Asset 1 (Kundendaten)	Asset 2 (Logs)	Asset 3 (Konfiguration)
Projektmanager	RW	-	RW
Entwickler	R	RWX	-
Tester	-	R	R
Administrator	-	RWX	RWX

Legende: R = Lesen, W = Schreiben, X = Ausführen

2.3 Abuse Cases

Abuse Cases beschreiben das Verhalten des Systems bei Missbrauch bzw. Angriffen. Sie sind das Gegenstück zu Use Cases und helfen, nicht-funktionale Sicherheitsanforderungen abzuleiten.

Beispiel:
- Abuse Case: „Jeder Benutzer eines Systems kann auf alle Einstellungen zugreifen"
- Abgeleitete Anforderung: „Einführung eines rollenbasierten Berechtigungssystems mit Zugriffskontrolle auf Einstellungen"

Wichtig bei der Erstellung ist die Fokussierung auf Bereiche mit dem größten Angriffspotential, da niemals alle möglichen Abuse Cases abgedeckt werden können.

2.4 Bedrohungsmodellierung (Threat Modeling)

Die Bedrohungsmodellierung ist eines der zentralen Konzepte der sicheren Softwareentwicklung. Sie stellt die einzige Aktivität dar, mit der sicherheitsrelevante Designfehler systematisch erkannt und
adressiert werden können. Auf Basis dieser Bedrohungsmodellierung können Gegenmaßnahmen und Testanforderungen abgeleitet werden.

Wichtig: Die Bedrohungsmodellierung sollte gemeinsam von Auftragnehmer und Auftraggeber durchgeführt werden. Nur durch die Zusammenarbeit beider Parteien kann sichergestellt werden, dass alle
sicherheitsrelevanten Anforderungen im Konzept berücksichtigt werden.

Die Phasen der Bedrohungsmodellierung:

1. Assets und Benutzer identifizieren
- Alle schützenswerten Objekte identifizieren (Daten, Image, Geschäftsprozesse)
- Involvierte Akteure identifizieren und deren erlaubte Operationen festlegen

2. Architektur erstellen
- High-Level-Architektur der Software erstellen
- Datenfluss- und Datenhaltungs-Diagramme integrieren
- Vertrauensgrenzen (Trust Boundaries) einzeichnen
- Zugangspunkte definieren

Beispiel für Zugangspunkte:

ID	Name	Beschreibung	Benutzer mit Zugang
1	HTTPS Port	Alle Seiten nur über SSL/TLS	Anonyme, authentifizierte und nicht-authentifizierte Benutzer
1.1	Start-Seite	Einstiegsseite für alle Besucher	Anonyme, authentifizierte und nicht-authentifizierte Benutzer
1.2	Login-Seite	Authentifizierung erforderlich	Anonyme, authentifizierte und nicht-authentifizierte Benutzer
1.2.1	Login-Funktion	Vergleich mit Datenbank	Authentifizierte und nicht-authentifizierte Benutzer
1.3	Such-Seite	Zugriff auf Suchfunktion	Authentifizierte Benutzer
1.4	Administrator-Seite	Portal-Administration	Authentifizierte Benutzer mit Administrator-Berechtigungen

3. Bedrohungen identifizieren
- Sich in die Lage eines Angreifers versetzen
- Angriffsvektoren systematisch identifizieren
- Verwendung von Angriffsmustern (z. B. STRIDE-Modell)

Das STRIDE-Modell klassifiziert Bedrohungen nach Schutzzielen:

Bedrohung	Schutzziel	Beispiel
Spoofing	Authentifizierung	Angreifer gibt sich als legitimer Benutzer aus
Tampering	Integrität	Manipulation von Daten in der Übertragung oder Speicherung
Repudiation	Nicht-Abstreitbarkeit	Benutzer kann durchgeführte Aktionen abstreiten
Information Disclosure	Vertraulichkeit	Unbefugter Zugriff auf sensible Informationen
Denial of Service	Verfügbarkeit	System wird durch Überlastung nicht verfügbar
Elevation of Privilege	Autorisierung	Benutzer erlangt höhere Berechtigungen als vorgesehen

4. Bedrohungen dokumentieren
- Alle identifizierten Bedrohungen strukturiert dokumentieren
- Ermöglicht spätere Nachvollziehbarkeit und Testplanung

5. Bedrohungen bewerten
- Priorisierung nach Risiko (Eintrittswahrscheinlichkeit × Schadenshöhe)
- Ressourcen auf kritischste Bedrohungen konzentrieren

6. Gegenmaßnahmen definieren
- Entsprechend der Priorisierung Maßnahmen ermitteln
- Neue Sicherheitsanforderungen in Architektur integrieren
- Hilfsmittel: OWASP „STRIDE Threat & Mitigation Techniques List"

Iterativer Prozess: Die Bedrohungsanalyse wird iterativ durchgeführt, bis die verbliebenen Bedrohungen akzeptabel sind.

2.5 Sicherheitsarchitektur

In der Sicherheitsarchitektur werden alle für die Anwendung notwendigen Komponenten und Sicherheitsmaßnahmen zusammengefasst und dokumentiert. Dies umfasst:

• Alle Akteure, Assets und Komponenten
• Datenflüsse und Trust Boundaries
• Anwendung von Security Design Principles (z. B. Minimalprinzip, Separation of Concerns, Defense in Depth)
• Sicherheitsanforderungen und deren technische Umsetzung

2.6 Sicherheitstestplanung

Bereits vor Beginn der Implementierung muss ein Testkonzept erstellt werden, das festlegt:

• Welche Bestandteile der Software werden getestet?
• Zu welchem Entwicklungszeitpunkt?
• In welchem Detailgrad?
• Wer ist für die Durchführung verantwortlich?
• Wann finden Security Pushes statt?

Ein Security Push ist eine Phase, in der keine neue Funktionalität entwickelt wird, sondern ausschließlich die Sicherheit der Software verbessert wird.

Quality Gate Phase 2:

• Liste der verwendeten Design-Guidelines und Good Practices
• Objektmodell mit Datentypen, Datenklassifizierungen und Datenflüssen
• Abuse Cases dokumentiert
• Vollständige Bedrohungsmodellierung:
  • Liste mit Zugangspunkten zur Applikation
  • Bedrohungsmodell mit Trust Boundaries
  • Liste identifizierter und bewerteter Bedrohungen
  • Liste mit begründeten Gegenmaßnahmen
• Alle Sicherheitsanforderungen dokumentiert
• Detaillierte Testplanung vorhanden
• Planung von Quality Gates und Security Pushes
• Software Security Metriken definiert
• Sicherheitsarchitektur vollständig dokumentiert
• Design-Prinzipien werden angewendet (Separation of Concerns, Minimalprinzip etc.)

Phase 3: Implementierung

Ziel: Sichere Umsetzung der konzipierten Architektur

3.1 Security APIs

Bei sicherheitskritischen Funktionen (z. B. Kryptographie, Authentifizierung, Eingabevalidierung) sollte unbedingt auf Eigenentwicklungen verzichtet werden. Stattdessen sollten nur ausgiebig getestete,
etablierte APIs verwendet werden.

Best Practice:
- Führung eigener Repositories mit erlaubten Frameworks
- Regelmäßige Prüfung und Aktualisierung dieser Listen
- Prozess für das Reagieren auf Schwachstellen in erlaubten Frameworks

3.2 Sicherer Umgang mit Sourcecode

Sicherheit betrifft nicht nur Daten und Funktionen, sondern auch den Quellcode selbst. Die Schutzziele Vertraulichkeit, Integrität und Verfügbarkeit müssen auch für den Sourcecode bewertet werden:

• Vertraulichkeit: Wer darf den Code einsehen? (Zugriffskontrolle auf Repository)
• Integrität: Wie wird sichergestellt, dass Code nicht manipuliert wird? (Signierte Commits, Code Reviews)
• Verfügbarkeit: Wie wird die Verfügbarkeit des Codes sichergestellt? (Backups, verteilte Repositories)

3.3 Secure Coding Standards

Secure Coding Standards legen Vorgaben für Entwickler fest, um ein Mindestmaß an Sicherheit zu schaffen. Die Standards sollten:

• Allgemeine Grundlagen enthalten (technologieunabhängig)
• Technologiespezifische Vorgaben für verwendete Sprachen und Frameworks umfassen
• Folgende Aspekte abdecken:
  • Einheitlicher Programmierstil
  • Input Validation & Output Encoding
  • Sichere Fehlerbehandlung (generische Fehlermeldungen für Nutzer, detaillierte Logs intern)
  • Logging-Konzept (manipulationssicher, außerhalb der Anwendung)
  • Sichere Authentifizierung und Session-Management
  • Sichere Kryptographie-Verwendung
  • Sichere Datenbankzugriffe (Prepared Statements)

Quality Gate Phase 3:

• Liste mit verwendeten Frameworks vorhanden und wird gewartet
• Beschreibung und Begründung eingesetzter APIs
• Keine eigenentwickelten sicherheitskritischen Funktionen (oder Begründung)
• Maßnahmen zum Schutz des Source Codes getroffen
• Quality Gates und Security Pushes werden eingehalten
• Festgelegte Sicherheitsanforderungen werden erfüllt
• Quellcode ist ausreichend dokumentiert (besonders sicherheitskritische Abschnitte)
• Allgemeine und sprachspezifische Secure Coding Standards werden verwendet

Phase 4: Testen

Ziel: Systematische Überprüfung der Sicherheit auf allen Ebenen

Das Testen ist eine der aufwändigsten, aber wichtigsten Phasen. Als Allgemeinkriterium gilt: Das Testen darf nicht vom Entwicklerteam erfolgen, sondern erfordert unabhängige Tester. Nur so ist
Objektivität gewährleistet.

In Abhängigkeit vom ermittelten Schutzbedarf sind unterschiedliche Testverfahren durchzuführen. Die Tests können entweder direkt durch den Auftragnehmer oder durch externe Sicherheitsexperten durchgeführt
werden.

4.1 Security Test Cases

Security Test Cases überprüfen die spezifizierten funktionalen und nicht-funktionalen Sicherheitsanforderungen. Ein Test Case besteht aus mehreren Testschritten, die sequenziell abgearbeitet werden.

Struktur eines Security Test Case:

Element	Beschreibung
Test Case ID	Eindeutige Identifikation (z. B. TC12)
Beschreibung	Was wird getestet? (z. B. „Authentifizierung erforderlich")
Priorität	Hoch/Mittel/Niedrig
Testschritte	Einzelne Schritte mit erwarteten Resultaten
Erfolgskriterium	Wann gilt der Test als bestanden?

Wichtig: Für jeden Testschritt sollten Positiv- und Negativtests erstellt werden:
- Positivtest: Verhalten mit gültigen Eingaben
- Negativtest: Verhalten mit ungültigen Eingaben

Quality Gate:
- Security Test Cases werden von Entwicklern erstellt
- Eindeutige IDs vergeben
- Priorisierung vorgenommen
- Allgemein verständliche Beschreibungen vorhanden
- Erwartete Resultate sind angemessen
- Positiv- und Negativtests durchgeführt
- Ergebnisse dokumentiert
- Gegenmaßnahmen für Abweichungen definiert und priorisiert
- Nach Umsetzung werden Tests wiederholt

4.2 Security Unit Tests

Security Unit Tests überprüfen Softwareeinheiten (Units wie Funktionen, Methoden, Klassen) auf korrekte Funktionalität. Ein Unit Test ist Code, der anderen Code aufruft und das Ergebnis auf Richtigkeit
prüft.

Vorteile:
- Frühe Fehlererkennung
- Automatisierbare Durchführung
- Kontinuierliche Integration möglich (CI/CD)
- Regression Testing

Quality Gate:
- Unit Tests werden von Entwicklern definiert und dokumentiert
- Eindeutige IDs vergeben
- Priorisierung vorgenommen
- Automatisierte Abarbeitung
- Ergebnisse dokumentiert
- Gegenmaßnahmen für Fehler definiert

4.3 Design Review

Überprüfung der Umsetzung der in Phase 2 definierten Sicherheitsarchitektur.

Prüfpunkte:
- Security Design Principles eingehalten?
- Alle Akteure identifiziert und dokumentiert?
- Alle externen Schnittstellen identifiziert?
- Angriffsfläche vollständig identifiziert?
- Minimalprinzip bei Berechtigungen angewendet?
- Authentifizierung nach Stand der Technik?
- Eingabe-/Ausgabevalidierung vorhanden?
- Vertrauliche Informationen bei Verarbeitung, Speicherung und Übermittlung geschützt?
- Kryptographie verwendet und Protokolle zeitgemäß?
- Audit und Logging integriert?
- Fehlerbehandlung sicher gestaltet?
- Design-Entscheidungen dokumentiert?

4.4 Code Review

Manuelle Überprüfung des Programmcodes, insbesondere sicherheitskritischer Abschnitte. Ein Code Review kann auch ohne vollständigen Code für einzelne Module durchgeführt werden.

Wichtig: Die Reviewer dürfen den Code nicht selbst entwickelt haben (Vier-Augen-Prinzip).

Empfohlene Metriken:
- Analysegeschwindigkeit: z. B. 250 LoC pro Stunde (abhängig von Komplexität)
- Gefundene Fehler/Fehlerklassen pro Zeiteinheit
- Codeabdeckung in Prozent
- Zeit für Fehlerbehebung nach Fehlerklasse
- Fehler bei erneuter Überprüfung (alte vs. neue Fehler)

Quality Gate:
- Anwendungsbereich definiert (kritische Komponenten)
- Ergebnisse dokumentiert
- Gegenmaßnahmen definiert und priorisiert
- Behobene Fehler werden im nächsten Review überprüft

4.5 Statische Code Scanner (SAST)

Automatisierte Analyse des Quellcodes ohne Ausführung. Der Einsatz mehrerer Tools kann die Erkennungsrate erhöhen und False-Positives reduzieren.

Vorteile:
- Schnelle Durchführung
- Auch ohne Sicherheitskenntnisse nutzbar (für Testdurchführung)
- Viele typische Fehler werden vor manuellem Review gefunden
- Integration in CI/CD-Pipeline möglich

Nachteil: Manuelle Verifikation der Ergebnisse ist zwingend erforderlich.

Auswahlkriterien für Tools:
- Kompatibilität mit eingesetztem Technologiestack
- Unterstützung möglichst vieler verwendeter Technologien und Frameworks
- Qualität der Fehlerklassifizierung
- Integration in Entwicklungsumgebung

Quality Gate:
- Eingesetzte Tools dokumentiert
- Ergebnisse nach Aussortierung von False-Positives dokumentiert
- Fehler manuell verifiziert
- Gegenmaßnahmen definiert und priorisiert

4.6 Web Security Scanner (DAST)

Automatisierte Black-Box-Tests der laufenden Anwendung. Scanner arbeiten ohne Kenntnis des Quellcodes und identifizieren einfache Schwachstellen (Low Hanging Fruits).

Auswahlkriterien:
- Unterstützte Protokolle (HTTP/1.1, HTTP/2, SSL/TLS, SOCKS Proxy)
- Authentifizierungsmethoden (Basic, Form-based, SSO, Zertifikate)
- Session Management (Token-Arten, Session-Handling)
- Crawler-Funktionalität
- Parser-Fähigkeiten (HTML, JavaScript, XML, verschiedene Encodings)
- Berichterstattung (Detailgrad, Exportformate)

Quality Gate:
- Eingesetzte Tools dokumentiert
- Ergebnisse nach False-Positive-Filterung dokumentiert
- Fehler manuell verifiziert
- Gegenmaßnahmen definiert und priorisiert

4.7 Fuzz Testing

Eingabe unerwarteter Werte zur Fehlerprovokation. Ziel ist es, Eingabewerte zu finden, die z. B. Buffer Overflows oder Abstürze auslösen.

Ansatz: Da vollständiges Fuzzing unmöglich ist, werden gezielt kritische Werte getestet:
- Bereichsgrenzen numerischer Variablen
- Sonderzeichen und Escape-Sequenzen
- Überlange Eingaben
- Unerwartete Datentypen

Quality Gate:
- Anwendungsbereich definiert
- Fehlerauslösende Eingaben mit Ergebnis dokumentiert
- Fehler manuell verifiziert
- Gegenmaßnahmen definiert und priorisiert

4.8 Penetrationstests

Angriffe auf die Webanwendung aus Sicht eines Angreifers. Penetrationstests sind die umfassendste Form des Sicherheitstests und sollten von externen Spezialisten durchgeführt werden.

Das BSI-Dokument „Durchführungskonzept für Penetrationstests" behandelt dieses Thema ausführlich.

Quality Gate:
- Penetrationstests werden durchgeführt
- Tests folgen dokumentiertem Prozess
- Klassifizierung nach Informationsbasis und Aggressivität
- Anwendungsbereich umfasst technische Systeme, Personal und organisatorische Infrastruktur
- Ergebnisse dokumentiert
- Gegenmaßnahmen definiert
- Umsetzungsplan vorhanden

4.9 Final Security Review (FSR)

Letzter Sicherheitstest auf die fertiggestellte Anwendung. Erst nach positivem Abschluss erfolgt die Freigabe.

Quality Gate:
- FSR wird durchgeführt
- Nicht erfüllte Anforderungen evaluiert, bewertet und dokumentiert
- Umsetzungsplan für offene Anforderungen vorhanden
- Freigabe erfolgt NUR nach positivem Abschluss (keine offenen kritischen Anforderungen)

Allgemeine Anforderungen Testphase:

• Test-, Entwicklungs- und Produktivumgebung sind getrennt
• Testteam ≠ Entwicklerteam
• Geplante Tests werden durchgeführt
• Ergebnisberichte vorhanden
• Behobene Fehler dokumentiert
• Finaler Security Check vor Auslieferung
• Dokumentation qualitativ hochwertig und ausführlich

Phase 5: Auslieferung & Betrieb

Ziel: Sichere Installation, Betrieb und Wartung gewährleisten

5.1 Sicherheitsdokumentation

Neben Projekt- und Code-Dokumentation muss eine eigene Sicherheitsdokumentation erstellt werden:

1. Sichere Installation
- Alle sicherheitsrelevanten Einstellungen mit Defaultwerten
- Schritt-für-Schritt-Anleitung
- Abhängigkeiten und Voraussetzungen
- Härtungsmaßnahmen

2. Sicherer Betrieb
- Berechtigungsmanagement
- Verarbeitung von Informationen
- Sicherheitsarchitektur und Bedrohungsmodell
- Anforderungen an Betriebsumgebung
- Fehlermeldungen und Lösungen
- Backup und Restore (Disaster Recovery)
- Interpretation von Log-Dateien
- Incident Response Meldewege

3. Sichere Updates
- Wie werden Updates bereitgestellt?
- Wie werden Updates installiert?
- Mögliche Sicherheitsprobleme bei Updates

4. Incident Handling
- Bewertung von Schwachstellen
- Kommunikationskanäle
- Möglichkeiten zur Behebung durch Hersteller

Zusätzlich bei kritischen Anwendungen: Source Code Escrow (Hinterlegung des Quellcodes bei Treuhänder für Insolvenzfall)

5.2 Security Change Management

Prozess für sicheres Change Management, der zwischen Auftraggeber und Auftragnehmer abgestimmt wird und folgende Punkte beinhaltet:

• Klassifizierung von Änderungen (nach Sicherheitsrelevanz)
• Umsetzung von Änderungen (Vier-Augen-Prinzip, Testing)
• Überprüfung von Änderungen (Validation)

Quality Gate Phase 5:

• Sicherheitsdokumentation vorhanden mit allen vier Bereichen
• Security Change Management Prozess erstellt mit Klassifizierung, Umsetzung und Überprüfung

Supply Chain Security: Das Risiko Drittcode

Moderne Webanwendungen bestehen oft zu 80 Prozent aus Frameworks und Bibliotheken. Für Auftraggeber ist dies ein blindes Risiko, wie die Vorfälle rund um Log4Shell (2021), Heartbleed (2014) oder die
zahlreichen npm-Schwachstellen zeigen.

Anforderungen an Drittcode-Management

Der Leitfaden legt daher besonderen Wert auf das Management von Drittanbieter-Code. Auftraggeber müssen vertraglich festlegen:

1. Software Bill of Materials (SBOM)
- Vollständiges Inventar aller genutzten Fremdkomponenten
- Inklusive transitiver Abhängigkeiten
- Mit Versionsnummern und Lizenzen
- Maschinenlesbar (z. B. SPDX, CycloneDX Format)

2. Aktualität
- Zum Zeitpunkt der Abnahme dürfen keine Komponenten mit bekannten Sicherheitslücken (CVEs mit CVSS ≥ 7.0) verbaut sein
- Regelmäßige Überprüfung während der Entwicklung
- Automatisiertes Monitoring (z. B. via OWASP Dependency-Check, Snyk, GitHub Dependabot)

3. Update-Strategie
- Klare Regelung, wer nach Go-live für Monitoring und Patching verantwortlich ist
- SLA für kritische Sicherheitsupdates (z. B. innerhalb von 48h)
- Prozess für Emergency Patches
- Backward-Compatibility-Tests

4. Quellen
- Code darf nur aus vertrauenswürdigen Quellen bezogen werden (offizielle Repositories wie Maven Central, npm Registry, PyPI)
- Keine unverifizierten GitHub-Forks oder private Repositories
- Verwendung von Package-Signing wo möglich
- Proxy-Repositories für zusätzliche Kontrolle

5. Lizenzkonformität
- Überprüfung der Lizenzen aller Komponenten
- Sicherstellung der Kompatibilität mit Projektlizenz
- Dokumentation für Compliance

Infrastruktur und Testdaten: Keine Echtdaten im Labor

Ein oft unterschätztes Kapitel im BSI-Papier betrifft die Entwicklungsumgebung des Auftragnehmers. Sicherheit endet nicht beim Code, sie betrifft auch die Werkbank, auf der er entsteht.

Trennung der Umgebungen

Entwicklung, Test und Produktion müssen netzwerktechnisch und logisch strikt separiert sein:

• Separate Netzwerksegmente (VLANs, Firewalls)
• Separate Datenbanken
• Separate Zugangsdaten
• Separate Deployment-Pipelines
• Administratorenzugriffe auf Produktion stark reglementiert (Vier-Augen-Prinzip, Logging)

Umgang mit Testdaten

Ein Kardinalfehler ist die Nutzung von Produktionsdaten zu Testzwecken. Im Lastenheft muss stehen:

• Tests erfolgen ausschließlich mit synthetischen oder anonymisierten Daten
• Werden Echtdaten benötigt (z. B. zur komplexen Fehlersuche):
  • Gesonderte Freigabe erforderlich
  • Strenge Löschfristen
  • Umfassende Protokollierung
  • Verschlüsselte Speicherung
• Keine personenbezogenen Daten außerhalb der EU (DSGVO Art. 44 ff.)

Sichere Konfiguration

• Standardpasswörter werden immer geändert
• Entwicklungstools haben keine Zugriffe auf Produktionssysteme
• Secrets (API-Keys, Passwörter) werden niemals im Code oder Repository gespeichert
• Verwendung von Secrets Management (HashiCorp Vault, AWS Secrets Manager)

Die Abnahme: Das schärfste Schwert

Die Abnahme ist der kritischste Punkt im Projektverlauf. Hier entscheidet sich, ob die Software in Betrieb gehen darf oder nicht.

Klassifizierung von Sicherheitsmängeln

Der Leitfaden empfiehlt eine klare Klassifizierung analog zu funktionalen Fehlern:

Kritisch / Hoch
- Die Sicherheit ist unmittelbar bedroht
- Beispiele:
- SQL-Injection möglich
- Umgehung der Authentifizierung
- Unverschlüsselte Übertragung sensibler Daten
- Remote Code Execution
- Privilege Escalation
- Konsequenz: KEINE Abnahme, KEIN Go-live
- Behebung ist zwingend erforderlich

Mittel
- Sicherheit eingeschränkt, aber schwer ausnutzbar
- Durch Workarounds mitigierbar
- Beispiele:
- Schwache Passwortrichtlinien
- Fehlende Rate-Limiting
- Informationslecks in Fehlermeldungen
- Session-Fixation möglich
- Konsequenz: Bedingte Abnahme mit fester Frist zur Nachbesserung
- Temporäre kompensierende Maßnahmen (z. B. WAF-Regeln)

Niedrig
- Verstöße gegen Best Practices
- Keine direkte Exploit-Gefahr
- Beispiele:
- Fehlende Security-Header (aber kompensiert durch andere Maßnahmen)
- Veraltete, aber nicht verwundbare Library-Version
- Unvollständige Logging
- Konsequenz: Akzeptabel, sollte aber in Wartungsphase behoben werden

Abnahmeprozess

Wichtig: Der Auftraggeber muss sich vertraglich vorbehalten:

1. Final Security Review (FSR) durch externe Spezialisten
2. Penetrationstest vor Go-live
3. Recht auf Verweigerung der Abnahme bei kritischen Mängeln
4. Nachbesserungsfristen mit Vertragsstrafen
5. Eskalationsmechanismen bei Nichteinhaltung

Erst wenn der FSR/Pentest positiv ausfällt, gilt das Werk als abnahmebereit.

---

Langfristige Sicherheit: Betrieb und Ende des Lebenszyklus

Plattformhärtung

Nach Auslieferung muss die sichere Konfiguration gewährleistet sein:

• Härtung des Webservers (Apache, nginx, IIS)
• Härtung der Laufzeitumgebung (JVM, PHP, Node.js)
• Deaktivierung unnötiger Dienste und Features
• Sichere TLS-Konfiguration (TLS 1.2+, starke Cipher Suites)
• Security Header (CSP, HSTS, X-Frame-Options, etc.)

Web Application Firewall (WAF)

Eine WAF sollte als zusätzliche Schutzschicht (Defense in Depth) betrachtet werden, nicht als Ersatz für sichere Entwicklung:

• Schutz vor gängigen Angriffen (OWASP Top 10)
• Virtual Patching bei bekannten Schwachstellen
• Rate Limiting und DDoS-Schutz
• Logging und Monitoring

Fernwartung

Bei kritischen Anwendungen sollte ein Fernwartungskonzept existieren:

• Sichere Zugangswege (VPN, Bastion Hosts)
• Starke Authentifizierung (MFA mandatory)
• Umfassendes Logging aller Fernzugriffe
• Zeitlich begrenzte Zugriffe
• Vier-Augen-Prinzip bei kritischen Änderungen

Ende des Lebenszyklus

Wird der Betrieb einer Webanwendung eingestellt, sind abschließende Anforderungen zu erfüllen:

• Regelungen zum Verbleib von Daten: Löschpflichten und -fristen gemäß DSGVO und anderen Vorschriften
• Hardware-Entsorgung: Sichere Löschung oder physische Zerstörung von Datenträgern
• Widerruf/Sperrung von Zertifikaten: PKI-Zertifikate müssen widerrufen werden
• Deaktivierung von Accounts: Alle Benutzerkonten und API-Keys deaktivieren
• Dokumentation: Archivierung relevanter Dokumente für gesetzliche Aufbewahrungsfristen

Praktische Umsetzung: Checklisten und Tools

Der BSI-Leitfaden enthält in Kapitel 5.3 umfangreiche Checklisten, mit denen Auftraggeber den Reifegrad potenzieller Auftragnehmer bewerten können. Die Listen:

• Decken alle fünf Phasen des SDLC ab
• Unterscheiden nach Schutzbedarf (Normal/Hoch/Sehr Hoch)
• Enthalten über 150 konkrete Prüfpunkte
• Sind als Excel/PDF-Vorlage verwendbar

Beispiel-Checkliste (Auszug Phase 4 - Testen):

ID	Anforderung	Normal	Hoch	Sehr Hoch	Erfüllt	Dok.	Anmerkung
4.1	Security Test Cases werden erstellt	X	X	X	☐	☐
4.2	Security Unit Tests vorhanden	-	-	X	☐	☐
4.3	Code Review durchgeführt	-	X	X	☐	☐
4.4	Statische Code Scanner eingesetzt	X	X	X	☐	☐
4.5	Web Security Scanner eingesetzt	X	X	X	☐	☐
4.6	Fuzz Testing durchgeführt	-	X	X	☐	☐
4.7	Penetrationstest durchgeführt	-	X	X	☐	☐
4.8	Final Security Review durchgeführt	X	X	X	☐	☐

Fazit: Qualität kostet – Unsicherheit kostet mehr

Die Umsetzung des BSI-Leitfadens bedeutet für Auftraggeber initial mehr Aufwand:

• Das Lastenheft wird umfangreicher
• Die Anforderungen an den Dienstleister steigen
• Vermutlich steigt auch der Tagessatz
• Mehr Prüfungen und Reviews sind erforderlich
• Längere Projektlaufzeiten sind einzuplanen

Doch diese Investition rechnet sich:

Kosten unsicherer Software

• Nachträgliche Behebung: Fehler, die in der Produktionsphase gefunden werden, sind 30-100x teurer zu beheben als in der Designphase (Quelle: IBM System Science Institute)
• Datenpannen: DSGVO-Bußgelder bis zu 20 Mio. € oder 4% des weltweiten Jahresumsatzes
• Reputationsverlust: Schwer quantifizierbar, aber oft der größte Schaden
• Geschäftsunterbrechung: Downtime kostet je nach Branche 5.600 € bis 540.000 € pro Stunde
• Incident Response: Forensik, Wiederherstellung, Kommunikation – schnell 6-7-stellige Summen

Return on Investment (ROI)

Wer Sicherheit als funktionales Qualitätsmerkmal begreift und vertraglich fixiert:

• Vermeidet teure „Feuerwehreinsätze" nach dem Launch
• Reduziert Haftungsrisiken
• Erfüllt Compliance-Anforderungen (DSGVO, NIS2, KRITIS)
• Schützt Reputation und Vertrauen
• Ermöglicht schnellere Time-to-Market (weniger Nacharbeit)
• Senkt langfristige Betriebskosten

Aktualität des Leitfadens

Der Leitfaden aus dem Jahr 2013 hat nichts an Aktualität verloren – im Gegenteil:

• DSGVO (2018): Datenschutz ist Pflicht, nicht Kür
• NIS2-Richtlinie (2023): Verschärfte Sicherheitsanforderungen für kritische Infrastrukturen
• Cyber Resilience Act (geplant): EU-weite Produkthaftung für unsichere Software
• Supply Chain Attacks: SolarWinds, Kaseya, Log4Shell zeigen die Relevanz von Drittcode-Management
• Ransomware: Angriffe auf Webanwendungen als Einfallstor

Die Prinzipien des BSI-Leitfadens sind zeitlos: Shift Left, Defense in Depth, Secure by Design.

Handlungsempfehlungen für Auftraggeber

1. Schutzbedarfsfeststellung durchführen (vor Ausschreibung)
- Systematisch, nicht ad-hoc
- Dokumentiert und nachvollziehbar
- Mit allen Stakeholdern abgestimmt

2. Sicherheit in Ausschreibung verankern
- Konkrete Anforderungen, keine Floskeln
- Eignungskriterien definieren (Zertifikate, Referenzen)
- Leistungskriterien festlegen (SSDL-Nachweis)
- Reifegradmodell nutzen

3. Quality Gates vertraglich fixieren
- Für jede Phase definieren
- Mit Abnahmekriterien verknüpfen
- Nachbesserungsfristen festlegen

4. Unabhängige Prüfungen einplanen
- Budget für externe Security Reviews
- Penetrationstests vor Go-live
- Regelmäßige Re-Assessments im Betrieb

5. Langfristig denken
- Nicht nur Entwicklung, auch Betrieb absichern
- Update- und Patch-Management regeln
- Incident-Response-Plan erstellen
- Ende des Lebenszyklus einplanen

Infobox: Ressourcen und weiterführende Informationen

BSI-Publikationen:
- Leitfaden zur Entwicklung sicherer Webanwendungen (Auftragnehmer): bsi.bund.de
- Leitfaden zur Entwicklung sicherer Webanwendungen (Auftraggeber): bsi.bund.de
- Durchführungskonzept für Penetrationstests: bsi.bund.de
- BSI IT-Grundschutz: bsi.bund.de/grundschutz

Standards und Frameworks:
- OWASP ASVS (Application Security Verification Standard): owasp.org/asvs
- OWASP SAMM (Software Assurance Maturity Model): owaspsamm.org
- NIST SP 800-53 (Security Controls): nist.gov
- ISO/IEC 27034 (Application Security): iso.org

Tools:
- OWASP Dependency-Check (SBOM/Vulnerability Scanning)
- SonarQube (SAST)
- OWASP ZAP (DAST)
- Snyk, GitHub Dependabot (Supply Chain Security)

Sicherheit ist kein Produkt, das man kauft, sondern ein Prozess, den man beauftragt – und kontrolliert.

In Zeiten von DSGVO, NIS2 und zunehmender Cyberkriminalität ist der BSI-Leitfaden für Auftraggeber relevanter denn je. Er bietet einen strukturierten, praxiserprobten Ansatz, um IT-Sicherheit vom Lastenheft
bis zur Abnahme durchzusetzen. Wer heute in Sicherheit investiert, spart morgen nicht nur Geld – sondern bewahrt Vertrauen, Reputation und möglicherweise die Existenz seines Unternehmens.

Dieser Artikel basiert auf dem BSI-Leitfaden „Entwicklung sicherer Webanwendungen – Empfehlungen und Anforderungen an Auftraggeber aus der öffentlichen Verwaltung" (2013).

Rechtlicher Hinweis:
Die in diesem Artikel dargestellten Empfehlungen dienen der Information und ersetzen keine Rechtsberatung. Für spezifische Projekte sollten Auftraggeber rechtliche und technische Fachberatung hinzuziehen.