Klarrios Security-by-Design-Ansatz: Warum Compliance zuletzt kommt

Sichere Software zu bauen ähnelt der Elektroinstallation eines Hauses. Man kann es ordentlich erledigen, solange die Wände noch offen sind – der Elektriker geht die Pläne Seite an Seite mit dem Architekten durch –, oder man wartet, bis die Familie eingezogen ist, und reißt dann Gipskartonplatten ab, um einem Fehler nachzuspüren. Beide Ansätze führen am Ende zu funktionierendem Licht. Nur einer davon lässt einen ruhig schlafen, und nur einer davon bleibt im Budget. Klarrios neues Whitepaper ist im Grunde ein langer Beleg dafür, dass die Branche immer wieder die zweite Option wählt – und dann überrascht tut, wenn die Leitungen anfangen zu brennen.

Was passiert ist

Klarrio hat ein Whitepaper zu Security by Design in der cloud-nativen Softwareentwicklung veröffentlicht, und die zentrale These ist schärfer als das übliche Anbieter-Material. Wie Techzine Global berichtete, argumentiert das Unternehmen, dass regulatorische Compliance das Ergebnis solider Sicherheitspraktiken sein sollte – niemals deren primärer Antrieb. Tick-Box-Compliance, so die These, erzeuge ein falsches Sicherheitsgefühl, während die echten Risiken still in der Ecke sitzen.

Der Hintergrund ist düster. Die weltweiten jährlichen Kosten durch Cyberkriminalität sollen bis Ende 2025 die Marke von 1,2 Billionen US-Dollar überschreiten. KI-gestützte Angriffswerkzeuge senken die Einstiegshürde für böswillige Akteure, und das Werkzeug, für das man früher ein ganzes Team brauchte – Deepfakes für Phishing, automatisierte Hacking-Tools – ist mittlerweile für jeden mit einem Browser und schlechten Absichten frei verfügbar.

In dieses Chaos hinein schwappt eine Welle europäischer Regulierung. Die NIS2-Richtlinie und der EU Cyber Resilience Act verpflichten Organisationen zu proaktiven Sicherheitsmaßnahmen, und Klarrio ist der Meinung, dass die meisten Unternehmen in diesem Stapel versinken. Das Whitepaper schlägt ein anderes Modell vor: risikobasierte Sicherheit, bei der Prioritäten nach den Bedrohungen gesetzt werden, die für die tatsächlichen Aktivitäten einer Organisation am relevantesten sind – nicht nach dem Rahmenwerk-Kästchen, das gerade leer ist.

Als Beleg für diese Philosophie beschreibt Klarrio ein Security Framework mit drei Rollen – Blue, Red und Purple Teams – sowie ein Security-Champions-Programm, das Anfang 2025 gestartet wurde, um Sicherheit strukturell in die Entwicklungskultur zu verankern. Das zentrale wirtschaftliche Argument ist dasjenige, das jeden CFO aufhorchen lassen sollte: Sicherheit von Anfang an einzubauen erhöht die Entwicklungskosten um etwa zehn Prozent, während das nachträgliche Anflanschen zehn- bis fünfzehnmal so viel kosten kann.

Technische Anatomie

Schält man das Whitepaper von seiner Marketing-Schicht, erhält man einen stillen Breitseitenangriff auf die Lieferkette. Klarrio weist darauf hin, dass moderne Plattformen zu siebzig bis neunzig Prozent aus Open-Source-Komponenten bestehen – von Kubernetes bis zum gesamten CNCF-Ökosystem. Das ist kein Rundungsfehler. Das ist das Gebäude selbst.

Das Versprechen von Transparenz und Geschwindigkeit bei Open Source ist real und vielfach erprobt, aber die Kehrseite ist eine Angriffsfläche, die jedes Mal wächst, wenn jemand npm install ausführt oder ein frisches Helm-Chart zieht. Wer schon einmal einen Sonntagmorgen damit verbracht hat, eine transitive Abhängigkeits-CVE zu jagen, kennt das Muster: Die Schwachstelle steckt nicht im selbst geschriebenen Code, sondern im Code, dem man drei Ebenen tiefer vertraut hat. Klarrios Antwort darauf sind Auswahlkriterien, die greifen, bevor eine Komponente überhaupt für die Plattform in Frage kommt – der langweilige Teil der Supply-Chain-Sicherheit, den niemand für eine Keynote-Folie fotografiert.

Das Drei-Team-Modell ist der Ort, an dem das Thema Entwicklungskultur lebt. Das Blue Team entwirft und implementiert Abwehrmaßnahmen. Das Red Team identifiziert aktiv Schwachstellen – der interne Gegenspieler. Die Aufgabe des Purple Teams ist der Teil, an dem es in den meisten Organisationen scheitert: den Wissensaustausch zwischen Blue und Red zu moderieren, damit Erkenntnisse tatsächlich zu Fixes werden und nicht zu Jira-Tickets, die zu Archäologie veralten.

Das Security-Champions-Programm obendrauf ist der Versuch, die Verantwortung für Sicherheit aus einem zentralen Team heraus in die Produktteams zu verlagern. Das ist wichtig, weil die Entwickler, die Terraform und Controller-Manifeste schreiben, die Einzigen sind, die Sicherheitsentscheidungen in dem Tempo treffen können, das cloud-native Entwicklung verlangt. Ein zentrales Team, das jeden Merge absegnet, ist das Architekturmuster, das uns Sechs-Monats-Release-Zyklen beschert hat – und dahin will niemand zurück.

Der risikobasierte Ansatz ist der ehrlichste Teil des Frameworks. NIS2 und der Cyber Resilience Act sind in der Sprache der Verpflichtung verfasst, aber Bedrohungen lesen keine Richtlinien. Eine Zahlungsplattform und eine Content-Website sehen sich völlig unterschiedlichen Angreifern gegenüber, und so zu tun, als ob das nicht so wäre, ist der Weg, auf dem man am Ende gehärtete Login-Flows und eine weit offene Admin-API bekommt.

Wer die Rechnung zahlt

Die Teams, die durch Klarrios Argumentation am stärksten exponiert werden, sind jene, die die letzten achtzehn Monate damit verbracht haben, Compliance-Programme rund um NIS2 und den Cyber Resilience Act aufzubauen, als wären diese das Ziel und nicht die Untergrenze. Regulierte Branchen – Fintech, iGaming, Zahlungsverkehr, kritische-Infrastruktur-nahes SaaS – sind hierfür besonders anfällig. Wenn die Prüfer-Checkliste zur Engineering-Roadmap wird, optimiert man für das Audit und verliert das Bedrohungsmodell aus den Augen.

Open-Source-lastige Plattformen spüren den Druck am stärksten. Wenn der eigene Stack zu siebzig bis neunzig Prozent aus fremdem Code besteht, basiert die eigene Sicherheitslage im Wesentlichen auf einer Wette auf die Release-Disziplin anderer. Die meisten Engineering-Organisationen, die ich gesehen habe, behandeln die Auswahl von Abhängigkeiten als eine Entscheidung nach Entwicklerkomfort: Hat es eine schöne API, ist die Doku lesbar, hat es Sterne auf GitHub? Das Klarrio-Modell verlangt, dass man es als Risikoentscheidung behandelt – was bedeutet, dass jemand Ranghöheres Nein zu einer populären Bibliothek sagen muss, weil der Wartungsrhythmus des Maintainers fragwürdig ist. Das ist ein schwieriges Gespräch, und die meisten Teams haben niemanden, der es führen will.

Die nächsten neunzig Tage werden die Ernsthaften von den Performativen trennen. CTOs, die still darauf gehofft haben, NIS2 sei eine Papierübung, werden feststellen, dass ihre Vorstände dieselbe Presse gelesen haben wie ihre Prüfer. Wer eine B2B-Plattform für EU-Kunden betreibt, wird Security-by-Design-Sprache in Beschaffungsfragebögen zu sehen bekommen, und „Wir sind NIS2-konform" wird aufhören, eine akzeptable Antwort zu sein, wenn die Folgefrage lautet: „Zeigen Sie mir Ihr Bedrohungsmodell."

Die andere Gruppe, die schlecht vorbereitet ist: Organisationen, die geplant haben, Sicherheit nachzurüsten. Die Mathematik von zehn Prozent im Voraus gegenüber dem Zehn- bis Fünfzehnfachen danach ist nicht subtil. Wer eine Plattform im Produktivbetrieb hat, die ohne eine ernsthafte Bedrohungsmodellierungsphase gebaut wurde, dem läuft die Rechnung bereits auf. Der Umschlag ist nur noch nicht geöffnet.

Leitfaden für Engineering-Teams

Beginnen Sie mit einem ehrlichen Abhängigkeits-Audit. Nicht ein Snyk-Report, sondern ein echtes Gespräch darüber, welche Ihrer siebzig bis neunzig Prozent Open-Source-Komponenten einen echten Maintainer, einen echten Sicherheits-Disclosure-Prozess und einen echten Release-Rhythmus haben. Klarrios Ansatz mit Auswahlkriterien ist das richtige Muster: Komponenten beim Eingang prüfen, nicht erst beim Incident.

Etablieren Sie eine Purple-Team-Funktion, auch wenn Sie sich kein eigenes Red Team leisten können. Die Rolle, die wirklich etwas bewegt, ist die des Übersetzers – die Person, deren Aufgabe es ist sicherzustellen, dass Penetrationstest-Erkenntnisse zu Engineering-Arbeit werden. Ohne diese Rolle wird der Red-Team-Output zu einem PDF, das niemand liest.

Wählen Sie ein Security-Champions-Modell und statten Sie es ordentlich aus. Ein Ingenieur pro Squad, mit fest zugeteilter Zeit – keine Freiwilligenrotation, die unter dem Sprint-Druck zusammenbricht. Der Punkt ist, Sicherheit zu einer Eigenschaft der Art und Weise zu machen, wie das Team Code schreibt, und nicht zu einem Gate, das es passieren muss.

Bauen Sie die Compliance-Erzählung von innen nach außen um. Ordnen Sie Ihre NIS2- und Cyber-Resilience-Act-Pflichten Ihrem tatsächlichen Bedrohungsmodell zu – nicht umgekehrt. Wenn das Bedrohungsmodell Kontrollen hervorbringt, die die Regulierung ebenfalls verlangt, erhalten Sie Compliance gratis. Wenn Sie bei der Regulierung anfangen, erhalten Sie einen Ordner.

Und rechnen Sie es vor Ihrem Vorstand durch. Zehn Prozent während der Entwicklung gegenüber dem Zehn- bis Fünfzehnfachen danach ist die einzige nützlichste Zahl im Whitepaper. Packen Sie sie auf eine Folie.

Wichtigste Erkenntnisse

• Klarrios Kernargument: Compliance ist ein Nebeneffekt guter Sicherheit, kein Ziel. Tick-Box-NIS2- und Cyber-Resilience-Act-Programme erzeugen ein falsches Sicherheitsgefühl.
• Die Wirtschaftlichkeit ist eindeutig: In das Design eingebettete Sicherheit kostet während der Entwicklung etwa zehn Prozent mehr, während das Nachrüsten das Zehn- bis Fünfzehnfache kosten kann.
• Moderne Plattformen bestehen zu siebzig bis neunzig Prozent aus Open Source – von Kubernetes bis zum CNCF-Ökosystem. Das ist Ihre echte Angriffsfläche, und die meisten Teams prüfen sie nicht.
• Das Blue/Red/Purple-Team-Modell funktioniert nur, wenn die Purple-Funktion die Schleife zwischen dem Finden von Schwachstellen und dem Ausliefern von Fixes wirklich schließt.
• Das Security-Champions-Programm, das Klarrio Anfang 2025 gestartet hat, ist das kulturelle Muster, das es wert ist, kopiert zu werden: Verantwortung in die Produktteams verlagern, statt sie bei einem zentralen Team aufzustauen.

Zurück zum halb verdrahteten Haus. Die Branche hat ein Jahrzehnt damit verbracht, so zu tun, als könnte man zuerst einziehen und den Elektriker dann um das Mobiliar herumarbeiten lassen. Klarrios Whitepaper ist eine Erinnerung daran, dass die Kosten dieser Wahl nicht theoretisch sind – sie sind ein Multiplikator, und die Regulierungsbehörden beginnen gerade, die Zähler abzulesen.