← Sichere Softwarebereitstellung
Secure Software Lifecycle und DevSecOps
Sicherheit vom Produktziel bis zur geregelten Außerbetriebnahme in den Lebenszyklus integrieren.
Ein Secure Software Lifecycle (SSLC, teils auch SSDLC genannt) verbindet Sicherheitsarbeit mit Planung, Entwicklung, Build, Deployment, Betrieb und Außerbetriebnahme. Die Abkürzungen werden in Organisationen unterschiedlich verwendet; gemeint ist jeweils ein Sicherheitsmodell über den Lebenszyklus. DevSecOps ist dessen betriebliche Umsetzung. NIST SSDF v1.1 bietet hierfür einen risikobasierten Orientierungsrahmen, keine Einheits-Checkliste oder Konformitätsgarantie.
Ausgangslage
Software entsteht selten in einem einzigen Team oder Tool. Eigener Code, Open-Source-Abhängigkeiten, Build-Systeme, Cloud-Dienste und Betriebsplattformen bilden eine Lieferkette. Wenn Sicherheitsentscheidungen erst vor dem Release geprüft werden, entstehen Wartezeiten, unklare Ausnahmen und schwer nachvollziehbare Risiken. Ebenso bleiben Schwachstellen im Feld ohne klare Rückkopplung häufig vom Entwicklungsprozess entkoppelt.
Ein SSLC schafft deshalb verbindliche Übergänge: Was muss vor einer Architekturentscheidung geklärt sein? Welche Nachweise gehören zu einem Release? Wer bewertet Risiken und Ausnahmen? Wie fließen Erkenntnisse aus Schwachstellen, Vorfällen und Änderungen in Produkt und Plattform zurück?
Fachliche Einordnung
NIST ordnet sein Secure Software Development Framework (SSDF) in vier Praxisgruppen: Organisation vorbereiten, Software vor Manipulation und unbefugtem Zugriff schützen, gut abgesicherte Software erzeugen sowie auf Schwachstellen reagieren. Die Praktiken sollen in vorhandene Entwicklungsmodelle integriert, risikobezogen angepasst und kontinuierlich verbessert werden.
Ein SSLC ist damit kein bestimmtes CI/CD-Produkt. Git-Repositories, Pipelines, Artefaktablagen, Cloud- oder Containerplattformen sind mögliche Umsetzungsvarianten. Entscheidend ist, dass Sicherheitsanforderungen, Änderungen, Freigaben und Belege über diese Varianten hinweg konsistent steuerbar bleiben.
Was Unternehmen konkret klären müssen
- Welche Produkte, Komponenten, Repositories, Build-Umgebungen und Lieferanten gehören in den Scope?
- Welche Sicherheitsanforderungen, Bedrohungen und Architekturentscheidungen müssen früh dokumentiert werden?
- Wer darf Code, Build-Definitionen, Secrets, Artefakte und Produktionsumgebungen ändern oder freigeben?
- Welche automatisierten und manuellen Kontrollen passen zum Risiko und wie werden Ausnahmen entschieden?
- Wie werden Schwachstellen, Sicherheitsereignisse und End-of-Life-Anforderungen in Planung und Betrieb zurückgeführt?
Typische Anti-Patterns
- Secrets liegen in Repositories oder ungeschützt in Pipeline-Variablen.
- Runner und Build-Umgebungen sind nicht ausreichend getrennt oder gehärtet.
- Artefakte können nach der Freigabe ersetzt werden (mutable artifacts).
- Ausnahmen bleiben ohne Owner, Ablaufdatum und erneute Bewertung bestehen.
- Die Herkunft eines Builds ist nicht bis zu Quellstand, Build-Definition und Abhängigkeiten nachvollziehbar.
- Für Komponenten und Produkte gibt es keinen End-of-Life-Prozess.
Von der Anforderung zur Umsetzung
Planung
Risiko: Sicherheitsanforderungen fehlen
Organisatorische Maßnahme: Security-Anforderungen, Ownership und Risikoentscheidungen
Technische Umsetzung: Backlog- und Architektur-Templates
Möglicher Nachweis: Anforderungs- und Entscheidungsprotokolle
Entwicklung
Risiko: Unsichere Änderungen oder Geheimnisse
Organisatorische Maßnahme: Review-Regeln, sichere Entwicklungsumgebung, Schulung
Technische Umsetzung: Branch-Schutz, Secret-Scanning, Code-Review
Möglicher Nachweis: Review- und Scan-Ergebnisse
Build und Deployment
Risiko: Manipulierte oder ungeprüfte Artefakte
Organisatorische Maßnahme: Freigabekriterien, Trennung von Rollen und Umgebungen
Technische Umsetzung: abgesicherte Pipelines, Artefaktablage, Signierung nach Bedarf
Möglicher Nachweis: Build-Provenienz, Release-Freigabe
Betrieb
Risiko: Schwachstellen bleiben unbehandelt
Organisatorische Maßnahme: Monitoring, Vulnerability- und Incident-Prozess
Technische Umsetzung: Inventar, Scans, Alarmierung, Patch-Workflow
Möglicher Nachweis: Tickets, SLAs, Betriebsberichte
Außerbetriebnahme
Risiko: Veraltete Komponenten bleiben erreichbar
Organisatorische Maßnahme: End-of-Life-Plan, Daten- und Schlüsselübergabe
Technische Umsetzung: Abschaltung, Archivierung oder Löschung nach Vorgabe
Möglicher Nachweis: Decommissioning-Protokoll
Vorgehen mit ADIUMENTO
Beratung oder Umsetzung zu einzelnen Bausteinen setzt das bestätigte Portfolio und einen konkreten Auftrag voraus. Diese Fachseite beschreibt kein eigenständiges DevSecOps-Angebot und keine Zertifizierung oder regulatorische Konformitätszusage.
Typische Arbeitsergebnisse
- SSLC-Zielbild mit Verantwortlichkeiten und Phasenübergängen;
- priorisierte DevSecOps-Roadmap für Prozesse, Plattform und Teams;
- Sicherheitsanforderungs-, Review- und Ausnahmeverfahren;
- Nachweisstruktur für Builds, Freigaben, Komponenten und Betrieb;
- Rückkopplung für Schwachstellen, Vorfälle und Außerbetriebnahme.
Grenzen und Abhängigkeiten
Automatisierung ersetzt weder Architekturentscheidungen noch qualifizierte Reviews in risikoreichen Bereichen. Die Wirksamkeit hängt von gepflegten Inventaren, gesicherten Entwicklungsumgebungen, der Qualität von Abhängigkeitsdaten und einem funktionierenden Schwachstellenmanagement ab. SBOM-Formate, Signierungsverfahren und konkrete Plattformkonfigurationen sind eigenständige Vertiefungen.
Weiterführende offizielle Quellen
- NIST SP 800-218 Secure Software Development Framework – NIST
- EU-Kommission: Cyberresilienzgesetz – EU-Kommission
- Microsoft Secure Future Initiative / SDL overview – Microsoft
Orientierung
Häufige Fragen
Ist DevSecOps nur CI/CD-Sicherheit?
Nein. CI/CD-Kontrollen sind ein wichtiger Baustein, aber DevSecOps beginnt bei Rollen, Anforderungen und Architektur und endet erst mit Betrieb, Schwachstellenbehandlung und Außerbetriebnahme. Eine Pipeline allein belegt keinen sicheren Lebenszyklus.
Wie starten Teams ohne vollständige Neuorganisation?
Mit einem klar abgegrenzten Produkt oder Lieferweg: Verantwortlichkeiten und aktuelle Kontrollpunkte erfassen, die größten Risiken priorisieren und wenige überprüfbare Verbesserungen in den bestehenden Ablauf integrieren. Danach können Verfahren und Automatisierung schrittweise skaliert werden.
Wo werden SBOM, Signierung und Betrieb vertieft?
SBOM und Dependency Management behandelt Transparenz und Steuerung von Abhängigkeiten; Code Signing und Microsoft Artifact Signing behandelt Integrität und Herkunft von Artefakten. Für Erkennung und Reaktion im Betrieb siehe Defender, App Control, Monitoring und Incident Response.
Nächster sinnvoller Schritt
Analysieren Sie einen konkreten Softwarelieferweg: Planung, Code, Build, Release und Betrieb. Falls das Vorhaben zum bestätigten Portfolio passt, können IT-Security & Compliance und Leistungen den passenden Einstieg geben.