Secure SDLC in der Praxis eines Software‑Herstellers: was zuerst einführen?

Secure SDLC (manchmal sagen wir „DevSecOps“, „secure‑by‑design“) ist kein einzelnes Tool und kein „Security‑Projekt“. Es ist eine Art, Software zu entwickeln und zu betreiben, bei der Sicherheit in den täglichen Arbeitsfluss eingebaut ist: von Anforderungen und Design über Code und CI/CD‑Pipeline bis hin zur Behandlung von Schwachstellen nach dem Release.

Für einen Software‑Hersteller (SaaS, On‑Prem, Vendor, Embedded‑Software) ist eines entscheidend: Secure SDLC so einzuführen, dass es die Liefergeschwindigkeit nicht tötet, sondern stabilisiert. Am besten funktioniert ein schrittweiser Ansatz, der auf Standards und „kleinen, messbaren Schritten“ basiert.

In diesem Artikel stütze ich die Reihenfolge der Maßnahmen auf:

• NIST SSDF (SP 800‑218) als praktische Liste von „Was muss vorhanden sein?“-Bereichen, aufgeteilt in Vorbereitung der Organisation, Schutz von Artefakten, Entwicklung sicherer Software und Reaktion auf Schwachstellen.​
• Microsoft SDL als bewährten Satz von Praktiken (u. a. Anforderungen, Threat Modeling, Secure Coding, Verifizierung).​
• OWASP ASVS als Referenzpunkt für Sicherheitsanforderungen an Anwendungen (was testen / was implementieren).​
• SLSA und SBOM als Fundament zur Absicherung der Supply Chain, die in Kundenanforderungen und Regulierung immer wichtiger wird.
• Den europäischen Kontext: der Cyber Resilience Act (CRA) erhöht die Bedeutung von Sicherheitsprozessen bei Herstellern, u. a. im Bereich Schwachstellenbehandlung im Produktlebenszyklus.​

Warum ist die „Reihenfolge der Einführung“ wichtiger als die Tool‑Liste?

Viele Unternehmen starten mit SAST/DAST und hoffen, dass Scanner „Secure SDLC machen“. Der Effekt ist oft umgekehrt: die Zahl der Alerts steigt, die Moral sinkt und die echten Risiken (z. B. Supply Chain, fehlender Patch‑Prozess, fehlende Anforderungen) bleiben.

Eine sicherere Strategie lautet:

• zuerst die Spielregeln und den Verantwortungsfluss festlegen,
• dann die Qualitätssicherung automatisieren (Scans, Tests),
• und am Ende die Reife erhöhen (breites Threat Modeling, harte Release‑Gates, SLSA nach Stufen).

„Must‑Have“ Secure SDLC für Hersteller (7 Säulen)

Die folgenden Säulen machen bei Herstellern tatsächlich einen Unterschied:

• Anforderungen und Standard: was „sicher“ in Ihrem Produkt bedeutet (z. B. ASVS Level 1/2/3).​
• Sichere Pipeline und Artefakte: Kontrolle von Builds, Signaturen, Provenance (SLSA).​
• Dependency‑Management und SBOM: Sichtbarkeit der Komponenten und schnelle Reaktion auf CVEs.
• Sicheres Design (Threat Modeling): Erkennung von Fehlerklassen, bevor Code entsteht.​
• Secure Coding + Code Review: Standards, Checklisten, Schulungen (SDL).​
• Verifizierung (SAST/DAST/IAST + Security‑Tests): Automatisierung und manuelle Tests dort, wo nötig.
• Vulnerability Management & Disclosure: Prozess, SLAs für Fixes, Kommunikation mit Kunden (in der EU auch regulatorisch wichtig).

Was zuerst einführen? Priorisierung „maximaler Effekt / minimale Reibung“

Priorität 1: Schwachstellenprozess und „wer ist wofür verantwortlich“ (PSIRT + VDP)

Dies ist bei Software‑Herstellern meist die größte Lücke: eine Schwachstelle landet „irgendwo im Support“ und geht dann in Mails unter. Der CRA verlangt jedoch klare Verfahren zur Behandlung von Schwachstellenmeldungen und deren Behebung im gesamten Produktlebenszyklus.​

Was sich für den Einstieg lohnt:

• Öffentliche Adresse für Meldungen (z. B. security@ihredomain) und eine einfache Vulnerability Disclosure Policy (VDP), damit klar ist, wie gemeldet wird und was ein Researcher erwarten kann.​
• Triage‑Prozess: Einstufung der Kritikalität, des Impacts und betroffener Versionen, damit Prioritäten konsistent sind und nicht „nach Gefühl“.​
• SLAs für Reaktion und Fix, z. B. Critical – 7 Tage, High – 30 Tage (an Ihr Geschäft und Risiko angepasst).
• Geordneter Prozess für die Auslieferung von Patches und die Veröffentlichung von Security Advisories, damit Kunden wissen, was zu tun ist.

Warum ist das Punkt Nummer 1? Weil auch der beste Secure SDLC nichts nützt, wenn Sie nicht schnell und vorhersehbar auf reale Schwachstellen reagieren können, die Ihr Produkt bereits heute betreffen.

Priorität 2: Zugangshygiene und CI/CD‑Pipeline (Supply‑Chain‑„Quick Wins“)

Supply‑Chain‑Angriffe gehören heute zu den größten Risiken. SLSA ist hier eine praktische „Checkliste“.​

Was Sie sofort einführen können (ohne Architekturumbau):

• MFA überall (Repo, CI, Cloud), keine geteilten Konten,
• Least Privilege für CI‑Tokens,
• Secrets im Secrets Manager, Token‑Rotation,
• Branch‑Schutz (erforderliches Review, Status Checks),
• Builds nur auf kontrollierten Runnern, Version‑Pinning für Actions/Skripte,
• Artefakt‑Registry + Kontrolle darüber, was in Produktion geht.

Der Effekt: geringeres Risiko, dass jemand die Pipeline übernimmt und im Rahmen eines Supply‑Chain‑Angriffs einen bösartigen Build in Produktion bringt.

Priorität 3: Dependency Management + SBOM (Sichtbarkeit = Reaktionsgeschwindigkeit)

SBOM ist eine formale Liste der Komponenten Ihrer Software. Die NTIA definiert minimale SBOM‑Elemente, CISA pflegt Materialien und Updates zu SBOM. Wenn Sie nicht wissen, was in Ihren Dependencies steckt, können Sie einem Kunden die Frage „Sind Sie von X betroffen?“ nicht beantworten.

Was sich für den Einstieg lohnt:

• automatisches Dependency‑Scanning (SCA) in CI,
• SBOM‑Generierung (z. B. CycloneDX oder SPDX) als Build‑Artefakt,
• Prozess „neue CVE“: Identifikation betroffener Versionen → Entscheidung → Patch → Advisory.

Das ist ein enormer Vertrauens‑Boost bei B2B‑Kunden – Sie zeigen, dass Sie Sicherheit und Schwachstellenbehandlung als Teil des Produkts und nicht als „Nebenkosten“ betrachten.

Priorität 4: „Security Requirements“ als Qualitätsstandard (ASVS / SDL)

In der Praxis funktioniert Secure SDLC, wenn Dev weiß, was erfüllt sein muss, und QA/CI dies prüfen kann.
OWASP ASVS liefert eine fertige Anforderungenliste für Web‑Anwendungen (und Services), Microsoft SDL zeigt, wie Security‑Praktiken in den Entwicklungszyklus integriert werden.​

Leichter Einstieg:

• ASVS‑Level wählen (oft Start: Level 1 als Baseline),
• daraus 10–20 „schmerzhafteste“ Anforderungen ziehen (Auth, Sessions, Logging, Validierung),
• daraus eine Definition‑of‑Done‑Checkliste für Features machen.​

Priorität 5: Threat Modeling an kritischen Punkten (nicht überall gleichzeitig)

Threat Modeling ist der Kern von SDL und ein starkes Werkzeug, um Designfehler früh zu reduzieren.​

In der Praxis eines Herstellers:

• starten Sie mit 2–3 User Journeys mit höchstem Risiko: Login, Passwort‑Reset, Zahlungen, API‑Integrationen,
• führen Sie kurze Sessions (60–90 Minuten) durch: Akteure, Assets, Vertrauensgrenzen, Missbrauchsszenarien,
• Ergebnis soll eine „Liste von Entscheidungen und Schutzmaßnahmen“ sein, kein Dokument um des Dokuments willen.

Einführungs‑Roadmap: 30 / 90 / 180 Tage (realistisch)

Erste 30 Tage: Fundamente, die das Risiko sofort senken

• PSIRT/VDP + einfacher Schwachstellenprozess (Triage, SLA, Advisory).
• MFA, Repo‑ und CI‑Schutz, Ordnung bei Secrets.
• Dependency‑Scanning + grundlegende SBOM als Build‑Artefakt.
• Minimaler Anforderungsstandard (z. B. ASVS Level 1 als „Baseline“).

KPIs nach 30 Tagen: Reaktionszeit auf eine Schwachstellenmeldung, % Projekte mit Dependency‑Scan und SBOM, % Pipelines mit MFA/Schutz.

90 Tage: Automatisierung von Qualität und Security‑Gates „ohne Drama“

• SAST in CI + Triage‑Regeln (was blockiert, was in den Backlog geht).
• DAST für wichtigste Endpunkte / Staging‑Umgebung.
• Threat Modeling für die Top‑2–3 kritischen Pfade.
• Secure‑Coding‑Standard (Checkliste) und verpflichtendes Review für Security‑Bereiche (Auth, Berechtigungen).
• Erste SLSA‑Elemente: Build‑ und Provenance‑Kontrolle dort, wo möglich.​

KPIs nach 90 Tagen: Trend kritischer Schwachstellen, Scan‑Abdeckung, Behebungszeit (MTTR) für High/Critical.

180 Tage: Reifegrad des Herstellers (Compliance‑ready + Prozessskalierung)

• SLSA nach Stufen (steigende Anforderungen an Builds und Artefakte).​
• SBOM + Update‑Prozess + Integration mit Vulnerability‑Intel (schnelle Antworten an Kunden).
• Programm zur Reduktion von „Schwachstellenklassen“ (z. B. Injection, SSRF, Auth‑Bypass) – im Sinne des von CISA propagierten Secure‑by‑Design‑Ansatzes für Hersteller.​
• Regelmäßige Penetrationstests / Red Teaming für kritische Module.
• „Security Champions“ in Produktteams (um Praktiken zu skalieren).

Wie das einführen, ohne dass Dev Secure SDLC hasst?

Regel 1: nicht alles „blockiert den Release“

Definieren Sie eine Policy:

• was blockiert (z. B. kritische Schwachstelle in Dependencies eines Internet‑Facing‑Components),
• was einen Plan erfordert (High),
• was im Backlog sein kann (Medium/Low).

Ohne das wird Secure SDLC zur „Alert‑Fabrik“.​

Regel 2: Triage ist wichtiger als die Anzahl der Tools

NIST SSDF behandelt dies ausdrücklich als organisatorische Praxis: Organisation vorbereiten, Software schützen, gut gesicherte Software produzieren, auf Schwachstellen reagieren. In Tools kann man untergehen, aber guter Triage‑Prozess und sinnvolle SLAs machen den Unterschied – das ist die „Mechanik“, die die Schwachstellenbehandlung tatsächlich funktionsfähig macht.​

Regel 3: Security Requirements müssen „testbar“ sein

ASVS hilft, weil seine Anforderungen direkt auf konkrete Tests und Security‑Kontrollen abgebildet werden können, sodass sie nicht „auf dem Papier“ bleiben, sondern in die Praxis übersetzt werden.​

Minimaler Satz an „Policies / Dokumenten“, die wirklich Sinn haben

• Secure‑SDLC‑Policy (1–2 Seiten): Scope, Verantwortlichkeiten, Gates.
• VDP / Richtlinie zur Schwachstellenmeldung + Kontakt.
• Dependency‑Standard: wer neue Libraries freigibt, wie auf CVEs reagiert wird.
• Secure‑Coding‑Checkliste (kurz, praxisnah).
• Release‑Security‑Checkliste (SBOM, Scans, Signaturen, Rollback‑Plan).

Häufigste Fehler von Herstellern (und Gegenmittel)

• Start mit DAST in Produktion → beginnen Sie mit Pipeline, SBOM und Schwachstellenprozess (weniger Chaos).
• Kein Schwachstellen‑Owner → richten Sie ein PSIRT ein (auch 2 Personen reichen) und definieren Sie SLAs.
• „Wir schalten SAST ein und schauen“ → ohne Triage und Blocking‑Regeln bringen Sie die Entwicklung zum Stillstand.
• SBOM als PDF einmal im Quartal → SBOM muss Build‑Artefakt sein (wiederholbar und aktuell).

Beste Reihenfolge der Einführung

• Vulnerability‑Handling (PSIRT + VDP + SLA),
• Zugangshygiene + Absicherung von CI/CD,
• SCA + SBOM + CVE‑Reaktionsprozess,
• Anforderungsstandard (ASVS als Baseline) + DoD,
• Threat Modeling für kritische Pfade (SDL),
• SAST/DAST mit Triage‑Regeln und sinnvollen Gates,
• SLSA nach Stufen + Härtung der Supply Chain.