Die Auslieferungsphase bündelt alle Sicherheitsprüfungen, bevor Software in Produktion geht. Dokumentiere jede Aktivität im Ticket-System (z. B. SEC-RELEASE-<nr>) und verlinke auf die Nachweise.

Abschlusscheckliste #

1. Code-Review abschließen und Findings bereinigen #

   • Maßnahmen: Review-Protokoll aktualisieren, offene Punkte im Issue-Tracker schließen.
   • Sicherheitsfreigabe: Security Champion oder autorisierte Reviewer bestätigen im Merge Request (z. B. Label security-approved, Kommentar mit Risk-Assessment-Link oder verpflichtendes Review). Bei SVN ohne Merge-Requests: nutzt ein Freigabeprotokoll wie docs/approvals/<release>.md, siehe SVN Freigabeprotokoll.
   • Nachweis: Abgenommener Merge Request oder unterschriebenes SVN-Freigabeprotokoll mit Link zum Ticket.

   Ohne finalen Code-Review fehlt der Nachweis für Annex A.8.28.

2. Sicherheitsnachweise bündeln und vorlegen #

   • Mindestumfang: aktueller SAST-Report, Dependency-/Lizenzscan (SCA) und Policiescan vom Release-Branch. DAST oder Pentest-Report, wenn in den letzten 12 Monaten durchgeführt.
   • Maßnahmen: Berichte aus CI/CD sammeln, Ergebnis im Freigabeticket dokumentieren, Security Champion bestätigt, dass alle HIGH/Critical Findings behoben oder per Corrective Action Log adressiert sind.
   • Nachweis: Freigabe-Kommentar/Label im CI/CD-System oder Freigabe-Mail mit Links zu den Reports (scan-reports/<datum>/). Formale Unterschriften sind nicht nötig, solange die Freigabe nachvollziehbar versioniert ist.

   Annex A.8.29 verlangt dokumentierte Sicherheitstests vor Release.

3. Schwachstellen bewerten oder Ausnahme genehmigen #

   • Maßnahmen: Risiko-Bewertung aktualisieren, Ausnahmen schriftlich genehmigen lassen.
   • Nachweis: Eintrag im Risiko-Register oder GRC-Freigabe.

   Akzeptierte Risiken benötigen dokumentierte Kompensationen und Review-Datum.

4. Build-Artefakte reproduzierbar erstellen und verifizieren #

   • Maßnahmen: Release mittels CI/CD bauen, Prüfsumme (sha256sum) erzeugen und im Ticket oder Tag dokumentieren.
   • Nachweis: Release-Log mit Checksummen und Speicherort.

   Ohne reproduzierbaren Build ist die Lieferkette nicht auditierbar.

5. Konfigurations- & Infrastrukturänderungen testen und dokumentieren #

   • Maßnahmen: Änderungen testen, Freigabe erteilen, Runbooks aktualisieren.
   • Nachweis: Change-Request oder Runbook-Eintrag.

   Infrastrukturänderungen ohne Documentation gefährden den Betrieb.

6. Rollback-Konzept aktualisieren #

   • Maßnahmen: Stellt sicher, dass ein aktuelles Rollback-Drill-Runbook vorliegt. Ein geplanter Drill pro Jahr liefert den stärksten Nachweis; wenn keiner durchgeführt wird, dokumentiert die Begründung im Ticket und aktualisiert die Wiederherstellungsanweisungen.
   • Nachweis: Link zum Runbook und ggf. Drill-Protokoll.

   Annex A.5.30 (ICT Readiness) verlangt dokumentierte Wiederherstellungsverfahren. Ein Drill ist nicht zwingend pro Release, stärkt aber den Audit-Nachweis erheblich.

7. Monitoring-Regeln prüfen #

   • Maßnahmen: Verifiziert, dass bestehende Monitoring-Regeln (Health-Checks, Fehlerquoten, Security-Alerts) den Release bestehen.
   • Neue Services? Legt mindestens eine Verfügbarkeits- und eine Fehlerrate-Regel an und testet sie in Staging.
   • Nachweis: Screenshot/Log aus Monitoring-Tool oder Ticket-Kommentar.

   Annex A.8.16 fordert Ereignisüberwachung. Dokumentiert im Projekt-Repo, wenn Monitoring mangels Zugriff nicht möglich ist und welche kompensierenden Kontrollen greifen.

8. Benutzer-, Admin- und Support-Dokumentation aktualisieren #

   • Maßnahmen: Dokumente aktualisieren, Änderungsdatum protokollieren.
   • Nachweis: Freigabe durch fachliche Owner.

   Dokumentationserneuerung unterstützt Annex A.7 (Security Awareness) und Service-Readiness.

9. Sensible Daten aus Logs, Dumps und temporären Verzeichnissen entfernen #

   • Maßnahmen: Pipeline um Löschschritte ergänzen, manuelle Prüfungen durchführen.
   • Nachweis: Bereinigungsprotokoll oder Ticketkommentar.

   Produktionsdaten im Release-Paket verstoßen gegen Datenschutzanforderungen.