Sicherheit am Ende versus Sicherheit von Anfang an: Die Entscheidung, die das Lieferungsrisiko bestimmt

Zwei Teams. Ein Ziel. Sehr unterschiedliche Ergebnisse.

Team A entwickelt die Lösung isoliert und bezieht den Sicherheitsverantwortlichen erst ein, wenn die Entwicklung bereits weitgehend abgeschlossen ist, während Team B die Sicherheit bereits dann in die Gespräche einbindet, wenn die Lösung noch geformt wird und Architektur, Datenflüsse sowie Zugriffsmodelle definiert werden.

Oberflächlich betrachtet verfolgen beide Teams dasselbe Ziel: funktionierende Software zu liefern, die letztlich die Sicherheitsanforderungen erfüllt. In der Praxis hat der gewählte Weg jedoch einen direkten und messbaren Einfluss auf Kosten, Risiko und Lieferzeit.

Wenn Sicherheit erst am Ende kommt

Team A zeigt anfangs meist eine hohe Geschwindigkeit, weil Entscheidungen ohne Einschränkungen getroffen werden, die Architektur schnell festgelegt wird und Funktionen umgesetzt werden, ohne dass externe Validierung berücksichtigt werden muss. Diese wahrgenommene Geschwindigkeit ist jedoch nur vorübergehend, denn sobald das System einer formalen Sicherheitsprüfung unterzogen wird, treten Probleme zutage, die nicht oberflächlich, sondern strukturell in der Art des Systemdesigns verankert sind.

Authentifizierungsmodelle entsprechen möglicherweise nicht den geforderten Standards, Ansätze zur Datenverarbeitung können Compliance-Risiken verursachen, Zugriffskontrollen können unzureichend sein, und in vielen Fällen handelt es sich nicht um isolierte Fehler, sondern um Designprobleme, die Nacharbeit über mehrere Systemkomponenten hinweg erfordern, statt sich mit einfachen Korrekturen beheben zu lassen.

In diesem Stadium wird Sicherheit oft als Hindernis wahrgenommen, tatsächlich wirkt sie jedoch als korrigierende Kraft, die Lücken sichtbar macht, die früher entstanden sind, als Entscheidungen ohne vollständigen Kontext getroffen wurden. Die Folgen sind vorhersehbar: Verzögerungen, höhere Kosten, doppelte Arbeit und zunehmende Spannungen zwischen Entwicklungs- und Sicherheitsteams, je stärker der Lieferdruck steigt.

Wenn Sicherheit die Gestaltung prägt

Team B arbeitet nach einem grundsätzlich anderen Modell, indem Sicherheit in die Designphase integriert wird. Dadurch werden Bedrohungsmodellierung, Datenklassifizierung, Zugriffsgrenzen und Compliance-Aspekte gemeinsam mit den funktionalen Anforderungen behandelt statt erst nachträglich.

Dies verringert die Entwicklungsgeschwindigkeit nicht in einem relevanten Sinn, sondern verändert vielmehr die Natur der Entwicklung selbst, weil Entscheidungen mit einem vollständigen Verständnis der Rahmenbedingungen getroffen werden, Abwägungen explizit statt zufällig sind und Architekturentscheidungen von Beginn an sowohl mit betrieblichen als auch mit Sicherheitsanforderungen abgestimmt werden.

Dadurch wird die Lieferung berechenbarer, Nacharbeit deutlich reduziert, und das System, das in Produktion geht, ist nicht nur funktional, sondern auch widerstandsfähig, auditierbar und in der Lage, unter realen Bedingungen zu arbeiten, ohne unnötige organisatorische Risiken einzuführen.

Der Unterschied ist die Reife des Betriebsmodells

Der Unterschied zwischen beiden Ansätzen ist keine Frage der Prozesspräferenz, sondern der Reife des Betriebsmodells. Team A behandelt Sicherheit als abschließenden Prüfpunkt, der validiert, was bereits gebaut wurde, während Team B Sicherheit als Designpartner versteht, der mitgestaltet, was gebaut wird.

Nur eines dieser Modelle skaliert wirksam, wenn Systeme komplexer werden und Organisationen stärker von der Zuverlässigkeit und Integrität ihrer Software abhängen.

Wenn Ihre Organisation noch wie Team A arbeitet, lautet die Frage nicht, ob sich das auf die Lieferung auswirken wird, sondern wann.

Nehmen Sie Kontakt mit Libertas Software Research auf und erfahren Sie, wie wir Ihnen helfen können, zu einem Modell zu wechseln, das sicher, planbar und skalierbar liefert.