Shift-Left

Den Begriff prägte Larry Smith 2001 in einem Artikel für Dr. Dobb's Journal. Das Bild dahinter ist eine Zeitachse, die links mit der Anforderung und dem ersten Commit beginnt und rechts in der Produktion endet. Shift-Left zieht Prüfungen auf dieser Achse nach vorn. Unit-Tests laufen beim Commit, statische Analyse im Pull Request, Security- und Compliance-Checks in der CI-Strecke, statt gesammelt vor dem Release.

Der Grund ist der Aufwand, den ein Fehler verursacht, je länger er unentdeckt bleibt. Beim Commit kennt der Entwickler seine Änderung noch, der Fix dauert Minuten. Taucht derselbe Fehler Wochen später im Systemtest auf, muss jemand erst herausfinden, welche Änderung ihn verursacht hat. Liegt er im Feld, kommen Hotfix, Auslieferung und im schlimmsten Fall ein Rückruf dazu. Derselbe vertauschte Parameter kostet beim Commit fünf Minuten und im Feld eine Woche Serviceeinsätze.

Im Security-Kontext ist Shift-Left das Kernprinzip von DevSecOps, oft als Shift-Left-Security bezeichnet. Statt eines Penetrationstests kurz vor dem Release laufen Dependency-Scans, statische Analyse (SAST) und Policy-Checks bei jedem Commit. In der Industrie kommen Safety und Compliance hinzu. Anforderungen aus ISO 26262 oder IEC 62443 prüft die Pipeline laufend, nicht erst ein nachgelagertes Audit.

Ein verbreitetes Missverständnis ist, Shift-Left mache späte Prüfungen überflüssig. Ein abschließender Integrations- oder Penetrationstest bleibt sinnvoll, weil er Fehler im Zusammenspiel findet, die frühe Prüfungen nicht sehen. Der zweite Stolperstein sind frühe Prüfungen, die zu lange dauern. Wartet ein Entwickler bei jedem Commit 40 Minuten auf einen Security-Scan, hat Shift-Left das Problem nur verschoben.