Nicht mit Secure by Design gestartet? Warum es sich trotzdem lohnt, jetzt anzufangen

Die meisten Softwareprojekte starten ohne Security, die fest in die Architektur eingebaut ist. Die Timelines sind eng, das erste Release hat Priorität, und Security-Anforderungen kommen entweder zu spät oder gar nicht. Wenn sich jemand ernsthaft mit der Security-Architektur beschäftigt,steht das Fundament schon längst.

Und wenn diese Erkenntnis kommt, lautet die häufigste Schlussfolgerung: „Jetzt ist es zu spät. Wir müssten von vorne anfangen.”

Diese Schlussfolgerung ist falsch. Nicht weil die Herausforderung nicht real wäre; Security nachträglich einzubauen ist tatsächlich schwieriger als sie von Anfang an mitzudenken. Aber Secure by Design war nie als Alles-oder-nichts-Ansatz gedacht. Es ist ein Set von Prinzipien, die in jeder Phase eines Projekts Mehrwert schaffen.

Die entscheidende Frage ist daher nicht, ob ein Projekt mit Secure by Design gestartet ist, sondern ob das Team bereit ist, jetzt damit anzufangen.

Warum die meisten Projekte nicht sicher starten

Das Muster ist struktureller Natur. Projekte lassen Security nicht links liegen, weil jemand eine schlechte Entscheidung getroffen hat. Sie lassen sie links liegen, weil die Art, wie die meisten Projekte aufgestellt sind, es fast unvermeidlich macht.

In den frühen Phasen gewinnt Geschwindigkeit jedes Argument. Architekturentscheidungen werden unter Zeitdruck getroffen, mit dem ersten Release als primärem Ziel. Security-Anforderungen – wenn sie überhaupt existieren – wurden noch nicht in technische Spezifikationen übersetzt. Sie stehen nicht auf dem Sprint Board. Und die Menschen, die Architekturentscheidungen treffen, und die Menschen, die für Security verantwortlich sind, sitzen oft nicht in denselben Meetings.

Und wenn Security-Anforderungen dann doch aufkommen, kommen sie in einem Format, das nicht zum Projekt-Workflow passt – als Compliance-Checklisten, die für Auditor*Innen geschrieben wurden, nicht für Entwickler*Innen. Dazu kommt:

• Project Manager sehen Security als etwas, das dem Security-Team gehört
• Entwickler*Innen wurden eingestellt, um Features zu liefern, nicht um Security-Architekturen zu entwerfen
• Kleinere Teams haben oft kein dediziertes Security-Budget oder entsprechende Expertise
• Security wird zu etwas, das „später angegangen wird” – nach dem MVP, nach dem ersten Kunden, nach der nächsten Finanzierungsrunde

All das ist kein Versagen von Einzelpersonen. Es ist das Ergebnis von Strukturen und Anreizen, die Delivery konsequent über Security stellen.

Die versteckten Kosten des Wartens

Je länger sich Security-Schulden anhäufen, desto mehr kosten sie. Auch an Stellen, die Project Manager direkt spüren.

Nacharbeiten, die den Zeitplan sprengen

Ein Team, das zwei Wochen vor dem Launch steht, erhält einen Penetration-Test-Bericht, der vor dem Go-live erforderlich ist. Unter den Findings: eine strukturelle Schwäche im API-Authentication-Layer. Kein einfacher Code-Fix, sondern eine Änderung der Service-Architektur. Das Release verschiebt sich um sechs Wochen. Das Szenario mag zwar fiktiv sein, das Muster aber ist Routine.

Veracodes State of Software Security 2024 belegt dieses Muster mit einer Zahl: Teams, die frühzeitig remedieren, reduzieren kritische Security-Schulden um bis zu 75 %. Für Project Manager, die Geschwindigkeit und Budget im Blick haben, ist die Richtung klar: Später zu handeln kostet mehr.

Ungeplante Risiken, die die Lieferung destabilisieren

Ohne frühzeitige Bedrohungsanalyse tauchen Security-Risiken zum denkbar ungünstigsten Zeitpunkt auf, etwa kurz vor einem Release oder während eines Audits. Laut der Synopsys Global State of DevSecOps 2023-Umfrage unter über 1.000 IT-Fachleuten berichteten mehr als 80 % der Organisationen, dass ein kritisches Security-Problem ihren DevOps-Lieferzeitplan im Vorjahr beeinträchtigt hat. Für Project Manager bedeutet jeder dieser Vorfälle ungeplante Nacharbeiten, Stakeholder-Kommunikation und einen Zeitplan, der nicht mehr hält.

Technische Schulden, die still eskalieren

Ein fehlendes Input-Validation-Pattern, das im ersten Sprint zwei Stunden Aufwand bedeutet hätte, wird zwölf Monate später zu einem serviceweiten Refactoring. Der IBM Cost of a Data Breach Report 2025 beziffert die globalen durchschnittlichen Kosten eines Breaches mit 4,44 Millionen USD. „Wir können uns jetzt keine Investition in Security leisten” klingt pragmatisch bis man es mit den Kosten vergleicht, die entstehen, wenn man nicht investiert.

Der Mythos von „Es ist zu spät” für Secure by Design

Die häufigste Reaktion auf angesammelte Security-Schulden ist nicht „Anfangen zu reparieren”. Es ist: „Wir stecken zu tief drin, um jetzt noch den Kurs zu ändern.”

Diese Logik würde in keinem anderen Bereich der Software-Qualität akzeptiert werden. Kein Team hat je gesagt: „Wir haben nicht von Anfang an Testfälle geschrieben, also hat es keinen Sinn, sie jetzt einzuführen.” Niemand argumentiert, dass die Einführung von CI/CD mitten im Projekt verschwendete Mühe ist, weil die ersten sechs Monate ohne es gelaufen sind. Auf Security trifft dasselbe Prinzip zu, angewandt auf eine andere Risikokategorie.

Was sich hinter „Es ist zu spät” oft verbirgt, ist etwas anderes:

• „Es ist zu teuer.”
• „Ich weiß nicht, wo ich anfangen soll.”
• „Es ist nicht meine Verantwortung.”

Das sind legitime Bedenken mit praktischen Antworten. Aber das „Zu spät”-Framing begräbt sie unter einem Gefühl von Unausweichlichkeit, das Handeln verhindert.

Ja, Security nachträglich einzubauen ist schwieriger als sie von Anfang an mitzudenken. Aber nichts zu tun und zu hoffen, dass das nächste Audit nichts Kritisches zutage fördert, ist in jedem Szenario, das wir kennen, teurer. Der pragmatische Weg ist inkrementell: die Hochrisiko-Bereiche identifizieren, sie Schritt für Schritt adressieren und Security-Denken in die Arbeitsweise des Teams einbauen.

Wie Project Manager Secure by Design einführen können

Project Manager müssen keine Security-Expert*Innen werden. Aber sie können die Bedingungen schaffen, unter denen Security zur Selbstverständlichkeit in der Arbeitsweise ihres Teams wird.

Threat Modeling als Planungstool einführen

Ein fokussierter Threat-Modeling-Workshop zu den kritischsten Komponenten passt in einen einzelnen Sprint-Planning-Zyklus. Die Rolle der Project Manager ist nicht, die technische Analyse zu leiten, sondern sie zu ermöglichen: die Zeit blockieren, die richtigen Personen zusammenbringen und sicherstellen, dass der Output in Planungsentscheidungen einfließt.

Security-Kriterien in die Definition of Done aufnehmen

Wenn Security Teil davon wird, was „fertig” bedeutet, hört sie auf, ein separater Workstream zu sein, und wird zur Routine. Beispiele:

• Keine offenen kritischen oder High-Severity-Findings am Ende eines Sprints
• Input Validation für neue Endpoints implementiert
• Security-relevante Änderungen vor dem Merge reviewt
• Bestehende Pentest-Findings in Backlog-Items übersetzen

Viele Organisationen haben Pentest-Berichte mit Findings, die nie in Entwicklungsaufgaben übersetzt wurden. Project Manager können als Übersetzer*In fungieren: Findings triagieren, sie Komponenten zuordnen und sie in das Sprint-Planning einfließen lassen. Wo interne Expertise für die Priorisierung fehlt, kann ein externer Partner helfen, der strukturierte Findings mit architektonischem Kontext verknüpft, um diese in umsetzbare Backlog Items zu übersetzen.

Einen Security Champion im Team etablieren

Keine neue Stelle ausschreiben, sondern jemanden, der bereits im Team ist, zur ersten Anlaufstelle für Security-Fragen machen. Project Manager identifizieren ein willliges Teammitglied und reserviert Sprint-Kapazität. Externe Security-Partner können diesen Prozess durch Coaching beschleunigen, sodass die Kompetenz im Team aufgebaut wird und nicht an eine externe Beraterin oder einen externen Berater gebunden bleibt.

Inkrementelles Security-Refactoring einplanen

10 bis 15 Prozent der Sprint-Kapazität für Security-Verbesserungen reservieren, genauso wie Teams Zeit für technische Schulden einplanen. Die Boy-Scout-Regel gilt hier auch: Den Code bei jedem Mal sicherer hinterlassen als vorgefunden, einen Feature-Zyklus nach dem anderen. Ein Security Assessment kann identifizieren, wo dieser Aufwand den größten Return bringt, damit das Refactoring gezielt erfolgt und nicht verstreut.

Anfangen, nicht perfektionieren

Secure by Design ist kein Label, das ein Projekt zu Beginn verdient oder für immer verpasst. Es ist eine Richtung.

Threat Modeling schafft auch im achten Monat noch Mehrwert. Ein einzelnes Pentest-Finding, richtig in ein Backlog-Item übersetzt, kann genau die Art von architektonischen Nacharbeiten verhindern, die ein Release zum Entgleisen bringen. Die Frage, die es wert ist, im nächsten Sprint Planning zu stellen, lautet nicht: „Sind wir Secure by Design?” Sondern: „Was können wir in diesem Sprint tun, um näher daran zu kommen?”

Eine Maßnahme aus diesem Artikel auswählen. Sie auf die Agenda setzen. Der erste Schritt muss nicht groß sein, aber er muss stattfinden.