- Security ist ein Prüfschritt am Ende, deshalb wird jede größere Änderung zur Verhandlung.
- Die Pipeline läuft, aber niemand kann sagen, welches Image aus welchem Commit deployt wurde und ob es geprüft ist.
- Eine Policy-Plattform existiert, und die Teams umgehen sie, weil sie mehr bremst als schützt.
- Secrets werden in jedem Repository anders behandelt, und eine dieser Varianten ist eine Tabelle.
Leistung
Secure Delivery und DevSecOps
Ich verlagere die Sicherheitsprüfungen in den Delivery-Pfad, damit eine normale Änderung ohne Meeting durchläuft und eine ungewöhnliche laut scheitert.
Wann Teams anrufen
Die Situation, zu der das passt
Security-Arbeit kommt meistens als Termin oder als Auditfeststellung.
Vorgehen
Drei Phasen, überlappend
Die erste Phase ist Lesen. Ein großer Teil der Verzögerung entsteht durch Reparaturen, die niemand gebraucht hätte.
-
01
Den echten Pfad aufnehmen
Ich verfolge, was zwischen Commit und laufendem System passiert: welche Pipeline baut, wer was freigibt, wo Secrets eintreten und welche Prüfungen wann greifen. Meistens zeigt das zwei oder drei Engstellen.
-
02
Prüfungen nach vorn verlagern
Policy wird Code mit Tests, Admission Control setzt durch, was zählt, und Supply-Chain-Prüfungen laufen dort, wo das Artefakt entsteht. Ziel ist, dass eine normale Änderung ohne Unterschrift durchläuft.
-
03
Unter Änderung beweisen
Ich bringe eine echte Änderung durch den neuen Pfad, inklusive der unangenehmen Teile: Rollback, eine Ausnahme, die erteilt werden muss, und was passiert, wenn eine Prüfung blockiert.
Ergebnis
Was am Ende vorliegt
Dinge, die weiterlaufen, wenn ich nicht mehr da bin.
- Ein Policy-Bundle mit Tests, in OPA und Rego, verdrahtet in Pipeline und Cluster.
- Supply-Chain-Prüfungen im Build: Image-Hashes, Vulnerability-Scans und eine Stückliste neben dem Code.
- Secret-Handling, das zu Ihren Randbedingungen passt: Vault, age mit SSH-Keys oder etwas dazwischen.
- Admission und Policy-Durchsetzung im Cluster, mit einem Ausnahmeprozess ohne Ticket-Warteschlange.
- Ein Autorisierungsmodell, wo das die Lücke ist: Decision Points, Enforcement Points und Decision Logging.
- Ein Runbook für die Fehlerfälle: was tun, wenn eine Prüfung ein Release blockiert, und wer übersteuern darf.
Formate
Drei Arten der Zusammenarbeit
Eine Auditfeststellung liest sich besser als klar umrissene Arbeit denn als offenes Programm.
Kurzanalyse
Zwei bis drei Wochen. Ich lese Pipelines und Cluster und liefere eine schriftliche Einschätzung, wo die Prüfungen sitzen und was zuerst zu tun ist.
Delivery-Umbau
Teilzeit über zwei bis vier Monate. Pipeline-, Policy- und Supply-Chain-Änderungen mit Ihrem Plattformteam, Schnitt für Schnitt.
Rettung
Vollzeit in einem stockenden Programm. Eine Policy-Plattform oder Pipeline, die nicht mehr vorankommt, mit einem Termin, der zählt.
Fragen
Vor dem ersten Gespräch
Die drei Fragen, die zuerst kommen.
Brauchen wir eine OPA-Plattform, um mit Ihnen zu arbeiten?
Nein. Entscheidend ist die Disziplin: Prüfungen, die als Code leben, getestet werden und laut scheitern. Je nach Lücke ist das Kyverno, OPA oder keins von beiden.
Bremst das die Lieferung?
Die erste Version meistens, für einige Wochen. Der Zielzustand ist das Gegenteil: normale Änderungen laufen ohne manuelle Freigabe, weil die Prüfungen automatisch laufen und Ausnahmen explizit sind.
Geht das auch mit einer halbfertigen Plattform?
So beginnen die meisten Mandate. Ich würde eher fertigstellen und stabilisieren als ersetzen, und die Analyse sagt offen, welche Teile es wert sind.
Kontakt
Beschreiben Sie den Delivery-Pfad, wie er heute läuft
Eine kurze Nachricht mit Kontext, Rahmenbedingungen und Zeitplan reicht, um einzuschätzen, ob das Mandat passt.