Dein Blog zum Thema digitales Business

Was ein Pipeline-Gate tatsächlich prüft

Du kennst das Muster: SAST durchsucht deinen Quelltext nach bekannten unsicheren Konstrukten. Ein Dependency-Scan vergleicht die eingebundenen Pakete mit einer Liste bekannter Schwachstellen. Ein Image-Scan prüft die Schichten eines Container-Images gegen dieselbe Art von Referenzdaten. Alle drei Kontrollen arbeiten nach demselben Prinzip: Sie vergleichen etwas Feststehendes, Code, Abhängigkeit, Image-Layer, mit etwas bereits Bekanntem, einer Signatur, einer CVE-Datenbank, einem Regelsatz. Das Ergebnis ist ein Gate, das vor dem Deploy greift und einen Build stoppen kann, bevor er in Produktion geht.

Genau diese Eigenschaft ist zugleich die Grenze. Ein Scanner findet nur, wofür es eine Regel oder einen bekannten Eintrag gibt. Was dein Code zur Laufzeit tatsächlich tut, mit welchen Prozessen, mit welchen Verbindungen, mit welchen Rechten, dazu sagt keine dieser drei Kontrollen etwas, weil zum Prüfzeitpunkt noch nichts läuft.

Drei Dinge, die erst nach dem Deploy sichtbar werden

Ungewöhnliche Prozessausführung: Ein Container startet plötzlich eine Shell oder einen Prozess, der in seinem Image gar nicht vorgesehen war. Unerwartete Netzwerkverbindungen: ausgehender Traffic zu einem Ziel, das im normalen Betrieb der Anwendung nicht vorkommt. Privilege Escalation zur Laufzeit: ein Prozess verschafft sich Rechte, die er beim Start nicht hatte.

Alle drei Verhaltensweisen existieren nicht im Quellcode, nicht in der Abhängigkeitsliste und nicht im Image selbst. Sie entstehen erst, wenn der Prozess läuft, mit echten Eingaben, echter Konfiguration und echter Umgebung. Ein Gate, das Build für Build prüft, hat zu diesem Zeitpunkt schlicht nichts zu prüfen, weil das Verhalten noch gar nicht existiert.

Warum Shift-Left diese Lücke nicht schließt

Shift-Left verschiebt Prüfungen nach vorn, in den Build, in den Pull Request, in den Commit. Das verkürzt die Zeit zwischen Fehler und Fund erheblich, und genau deshalb ist Shift-Left richtig. Es ändert aber nichts daran, was grundsätzlich vor dem Deploy prüfbar ist. Eine Prüfung, die früher stattfindet, sieht dadurch nicht mehr, sie sieht nur schneller. Ein Muster, das erst zur Laufzeit entsteht, lässt sich nicht durch einen früheren Zeitpunkt sichtbar machen, sondern nur durch eine andere Art von Beobachtung.

Was Runtime-Erkennung stattdessen beobachtet

Runtime-Detection-Werkzeuge setzen an einer anderen Stelle an als ein Scanner: nicht am Code vor dem Start, sondern am tatsächlichen Verhalten des laufenden Systems. Ein bekanntes Beispiel für diesen Marktansatz ist Falco, ein Open-Source-Projekt, das bei der Cloud Native Computing Foundation den Graduated-Status trägt und nach eigener Beschreibung eBPF nutzt, um Systemaktivität auf Linux-Kernel-Ebene in Echtzeit auszuwerten (Quelle: falco.org, Stand dieser Beschreibung: 2026). Weicht ein Prozess von den hinterlegten Regeln ab, entsteht ein Alarm zur Laufzeit, nicht erst beim nächsten Build.

Der Unterschied zur Pipeline-Kontrolle liegt nicht allein in der Technik, sondern im Zeitpunkt: eBPF-basierte Ansätze beobachten, was tatsächlich passiert, während es passiert. Ein Pipeline-Gate kann das nicht nachholen, weil zu seinem Prüfzeitpunkt noch nichts läuft, das beobachtet werden könnte.

Zwei Kontrollschichten, keine Konkurrenz

Wer im Team für ein Sicherheitswerkzeug zuständig ist und wie aus einem Befund eine Entscheidung wird, ist eine Prozessfrage, die an anderer Stelle bereits eine eigene Betrachtung bekommen hat. Hier geht es um etwas davor: um die Kontrollebene selbst, unabhängig davon, wer sie bedient.

Shift-Left und Runtime-Erkennung sind deshalb keine konkurrierenden Antworten auf dieselbe Frage. Ein Pipeline-Gate fragt: Ist vor dem Deploy ein bekanntes Risiko vorhanden? Runtime-Erkennung fragt: Verhält sich das System nach dem Deploy so, wie erwartet? Wer nur die erste Frage beantwortet, hat vor dem Deploy ein sauberes Bild und nach dem Deploy einen blinden Fleck. Beide Kontrollen decken unterschiedliche Zeiträume ab, und keine ersetzt die andere.

Das Leistungsspektrum ist gestaffelt und baut auf Delivery-Transparenz auf. Alles Weitere richtet sich nach der Lage und läuft über drei Felder: Implementation, also Delivery und Nachweis modulweise in die Pipeline einziehen, AI Governance, also Nachvollziehbarkeit bei KI-gestützten Build- und Deployment-Schritten, und Maintenance, also die Frage, wem ein System nach dem Go-Live gehört und woran man merkt, dass es niemandem mehr gehört. Ein festes Angebot daraus entsteht erst, wenn klar ist, was der Kunde wirklich braucht. Kontakt: mm@mhm-dl.de