OWASP SPVS: Lehren aus der Sicherung der Software Pipeline

Jahrelang attackierten Angreifer Anwendungen einzeln. Doch ihre Taktik hat sich geändert: Warum eine Anwendung kompromittieren, wenn man gleich alle kompromittieren kann? pipeline Das baut viele? Xygenis Malware-Frühwarnung (MEW) erkannt 4,452 schädliche Pakete im Jahr 2025 als auch Bislang sind es 1,281 weitere im Jahr 2026.Jeder der aufsehenerregenden Vorfälle der letzten Jahre hat ein anderes Glied in der Software-Lieferkette getroffen:

• SolarWinds (2020): Kompromiss bei der Build-Umgebung; versteckte Updates wurden an 18,000 Kunden ausgeliefert.
• Codecov (2021)Durch ein falsch konfiguriertes Docker-Image konnten Angreifer ein Bash-Uploader-Skript modifizieren und so CI-Geheimnisse von mehr als 23,000 Kunden exfiltrieren.
• CircleCI (2023): Der Diebstahl von Session-Cookies auf dem Laptop eines Ingenieurs führte zur Erlangung von Produktionszugriffstoken; jeder Kunde wurde angewiesen, jedes Geheimnis regelmäßig zu ändern.
• XZ Utils-Hintertür (2024) Eine mehrjährige Social-Engineering-Kampagne, die fast jede Linux-Distribution erreichte.
• tj-Aktionen (2025) — eine GitHub Actions-Lieferkettenkaskade, die eine von über 23,000 Repositories genutzte Komponente vergiftete.
• Angriffe auf Aqua Trivy als auch Scheckmarx (2026) — Die TeamPCP-Kampagne nutzte zwei weit verbreitete Sicherheitsscanner als Angriffsvektoren und verwendete anschließend die gestohlenen Daten. CI/CD Zugangsdaten, die an npm, OpenVSX und PyPI weitergegeben werden können.

Jeder Angriff nutzte einen anderen Teil des Systems aus. pipelineBuild-Umgebung, CI-Tools, Abhängigkeiten, Entwicklerberechtigungen, Maintainer-Vertrauen, veränderliche Referenzen auf Artefakte. Die meisten Organisationen reagieren darauf mit Punktkontrolle, einem Scanner in der CI, 2FA beim IdP und Branch-Schutz. mainWas typischerweise fehlt, ist eine Möglichkeit zu fragen Sind wir systematisch abgesichert? statt Haben wir daran gedacht, X nach dem letzten Vorfall zu aktivieren?

Anbieter von Anwendungssicherheitslösungen stehen im Zentrum der Kritik; die Kompromittierung eines Anbieters betrifft jeden Kunden, der auf seine Produkte vertraut. Der Druck, von reaktiven Kontrollen zu einer systematischen Vorgehensweise überzugehen, ist nicht theoretisch. Das ist Realität.cisWas hat die Einführung des OWASP SPVS motiviert? standard als ein Projekt mit höchster Priorität.

Was SPVS ist und warum die Struktur wichtig ist

Die Entstehungsgeschichte ist einfach. Auf der LASCON 2023 stellten sich Farshad Abasi und Cameron Walters immer wieder dieselbe Frage: Wo ist das ASVS für pipelineOWASP ASVS hatte der Anwendungssicherheit eine umfassende, überprüfbare standardFür … existierte nichts Entsprechendes. CI/CD.

Es gab die OWASP Top 10 CI/CD Risiken, die auf Sensibilisierung ausgerichtet und nicht testbar waren; SLSA, das sich ausschließlich auf die Herkunft der Builds konzentrierte; S2C2F, das sich ausschließlich auf den Verbrauch von Abhängigkeiten konzentrierte; und OpenSSF Die Scorecard umfasste spezifische Repository-Prüfungen. Jede Prüfung deckte einen Teilbereich ab. Keine Prüfung deckte das Ganze ab.

Rahmen oder Projekt	Primärer Geltungsbereich
OWASP Top 10 CI/CD Risiken	Bewusstseinsorientiert CI/CD Risikohinweise, keine überprüfbare Verifizierung standard.
SLSA	Herkunftsnachweis und Integrität der Artefakte sicherstellen.
S2C2F	Sicherer Abhängigkeitskonsum.
OpenSSF Scorecard	Spezifische Sicherheitsprüfungen auf Repository-Ebene.

Die Lücke: Jedes Rahmenwerk deckte einen wichtigen Teil ab software supply chain securityAber keine bot eine durchgängige, überprüfbare standard für das Ganze CI/CD pipeline.

Aus diesem Gespräch entwickelten sich zwei Jahre Arbeit, und im Oktober 2025 veröffentlichte die SPVS-Arbeitsgruppe Version 1.0: 127 Anforderungen entlang des gesamten Lebenszyklus (Planung, Entwicklung, Integration, Freigabe, Betrieb), unterteilt in drei Reifegrade: L1 (Grundlagen), L2 (Reifegrad) und L2 (Reifegrad). Standardund L3 Advanced. Jede Anforderung ist auf NIST SP 800-53 und OWASP abgebildet. CI/CD Top 10 und CWE.

Hier haben die meisten Organisationen Schwierigkeiten. Sie analysieren Abhängigkeiten, ignorieren aber die Release-Governance. Sie signieren Artefakte, erstellen aber kein Bedrohungsmodell für ihre Releases. pipeline Architektur. Sie überwachen die Produktion, aber nicht ihre Entwicklungsumgebungen.

Dies ist die These, die den Aufwand rechtfertigt. Stärken in einer Phase gleichen Schwächen in einer anderen nicht aus. Angreifer benötigen nur ein einziges Glied, das sie knacken können. Ein Lebenszyklus standard Es zwingt dich, alle zu überprüfen, und die Abfolge von L1 über L2 zu L3 ermöglicht dir dies, ohne dich in Details zu verlieren. SPVS ersetzt weder SLSA, S2C2F, Scorecard noch Sigstore; es bietet dir lediglich das Grundgerüst, das dir zeigt, wo jedes dieser Elemente seinen Platz hat.

Anpassung der Standard an Ihre Organisation

Der erste Schritt ist eine gründliche Überprüfung Ihrer Organisation und Softwareinfrastruktur anhand jeder einzelnen Anforderung. Ein Google Sheet, das mit Daten aus dem offiziellen Verzeichnis erstellt wurde, kann dabei hilfreich sein. SPVS-Anforderungen CSV Es eignet sich gut als Ausgangspunkt. Drei Ansichten sind hilfreich: eine Anforderungsmatrix mit Status und Verantwortlichem pro Steuerelement, eine Heatmap pro Repository und eine dashboard Der Fortschritt wird nach Phase und Ebene dargestellt. Die Ergebnisse fließen nahtlos in einen technischen Fahrplan ein, ein dynamisches Dokument, das jede Phase von der Planung bis zum Betrieb abdeckt.

Die meisten etablierten Ingenieurorganisationen befinden sich bei dieser ersten Bestandsaufnahme bereits auf Level 2. Das ist durchaus vorteilhaft: So kann sich die erste Phase auf die Schließung konkreter Lücken konzentrieren, anstatt Grundlagen von Grund auf neu zu schaffen.

Eine Tabellenkalkulation ist jedoch nur eine Momentaufnahme, und SPVS verlangt mehr. Version 1.1.7 schreibt ein vierteljährliches Audit der VCS-Administratoren vor; die Versionen 5.1.1 bis 5.1.3 ergänzen dies um regelmäßige Benutzer-Audits, die Überprüfung von Zugriffsprotokollen und die Überwachung privilegierter Zugriffe; diverse Kontrollen der Versionen 2.1.x, 3.3.x und 4.2.x erfordern eine kontinuierliche Pflege der Workflow-YAML-Dateien. Manuell im gesamten Unternehmen durchgeführt, bedeutet dies einen halben Tag Klick-Tracking pro Quartal mit dem realen Risiko, dass etwas unbemerkt übersehen wird. Es handelt sich um eine Aufgabe, die entweder automatisiert oder erst nach einem negativen Ereignis überprüft wird.

Einige SPVS-Kontrollen sind keine einmaligen Checklistenpunkte. Sie erfordern regelmäßige Überprüfungen, Auditnachweise und die Erkennung von Abweichungen über Repositories, Benutzer, Workflows und privilegierte Zugriffe hinweg.

SPVS-Bereich	Anforderungstyp
V1.1.7	Vierteljährliche Prüfung der VCS-Administratoren.
V5.1.1–V5.1.3	Regelmäßige Benutzerüberprüfungen, Überprüfung der Zugriffsprotokolle und Überwachung privilegierter Zugriffe.
V2.1.x, V3.3.x, V4.2.x	Laufende Workflow-YAML-Hygiene.

Die Lösung besteht darin, Tools zu entwickeln oder zu übernehmen, die unter der Identität des Organisationsinhabers laufen und ein strukturiertes Quartalspaket erzeugen: Administratorenliste, Branch-Schutz, CODEOWNERS-Abdeckung, Workflow-YAML-Hygiene mit angehefteten Aktionen, explizite Berechtigungen, pull_request_target Zugangskontrolle, Zwei-Faktor-Authentifizierung für Mitglieder, installierte GitHub-Apps und Bereitstellungsschlüssel. Was früher einen halben Tag Tabellenkalkulations-Archäologie erforderte, wird nun mit einem einzigen Befehl erledigt, der JSON und Markdown ausgibt. Die vierteljährliche Überprüfung zwischen dem CISO- und Organisationsadministratoren werden zu einem decisEs handelt sich um ein Ionen-Meeting, nicht um ein Datenerhebungs-Meeting, und aus umsetzbaren Erkenntnissen werden Rückstände mit schweregradbasierten SLAs.

Eine Zulassungsrichtlinie, die genehmigte Administratoren, genehmigte Anwendungen und funktionsbezogene Berechtigungen für Repositories und Workflows umfasst, sollte als YAML-Datei in einem versionskontrollierten Repository verwaltet und durch eine Pull-Request-Prüfung des Sicherheitsteams geschützt werden. Jede Änderung der Zulassungsliste hinterlässt einen Prüfpfad, sodass automatisch Auditnachweise generiert werden. Dadurch werden ehemals angestrebte Kontrollen, wie beispielsweise „Wir sollten vierteljährliche Audits durchführen“, zu Routinemaßnahmen, wie etwa „Das Audit dieses Quartals wurde am Montag abgeschlossen“. Die Organisation erhält so einen wiederholbaren Mechanismus zur Erkennung von Abweichungen, den das End-to-End-Prinzip erfordert.

Die Reibungspunkte, die Sie einplanen sollten

Die technischen Kontrollen sind der einfache Teil. Die Menschen sind schwieriger.

Das herausragendste Beispiel sind fast immer die CODEOWNERS. Hinzufügen .github/workflows/ @your-org/security In jedem Repository klingt das trivial. Eine Datei, eine Zeile. Doch es bedeutet, dass Entwickler, die seit Jahren Workflow-Änderungen selbstständig zusammenführen, nun einer Sicherheitsprüfung unterzogen werden müssen. Selbst sicherheitsbewusste Mitarbeiter sträuben sich: Ich habe diesen Workflow geschrieben, ich verstehe ihn, warum muss ich warten?

Um die Gründe zu klären, bedarf es eines echten Gesprächs. Arbeitsabläufe können Zugangsdaten stehlen, Daten umleiten und nachgelagerte Systeme schädigen. Eine zweite Meinung ist kein Zeichen von Misstrauen; sie entspricht der Vier-Augen-Regel bei Änderungen an Produktionsdatenbanken. Ein konkreter, aktueller Vorfall in der Lieferkette, sei es aus der Branche oder dem eigenen Umfeld, ist dabei enorm hilfreich. Nichts verdeutlicht die Notwendigkeit einer Kontrollmaßnahme so sehr wie ein konkretes Beispiel für deren Fehlen.

Andere Reibungskräfte folgen dem gleichen Verlauf:

• Explizite Berechtigungen: Blockaden in Arbeitsabläufen führen zu CI-Fehlern, solange die Mitwirkenden die Bedeutung von bereichsbezogenen Berechtigungen nicht verstehen. Dies ist kein Berechtigungsproblem, sondern ein Problem des mentalen Modells.
• Unveränderlichkeit von Tags: führt zu Problemen mit den Release-Tools, die seit Jahren im Stillen Neu-Tags erstellt haben.
• Unterzeichnet commits: Es entstehen Schwierigkeiten beim Onboarding, solange GPG- oder SSH-Schlüssel nicht auf allen Arbeitsstationen korrekt eingerichtet sind. SPVS macht dies für jedes Repository und jeden Mitwirkenden obligatorisch, nicht nur für die Haupt-Repositories.
• Ersetzen klassischer persönlicher Zugriffstoken: Es betrifft zahlreiche Repositories und Workflow-Dateien und ist mit nahezu jedem Team verbunden.

Das bewährte Vorgehen: Jede Kontrollmaßnahme wird mit einer spezifischen Bedrohung eingeführt, die sie abwehrt. Anschließend wird sie in ein oder zwei Repositories getestet, dann mit Ausnahmen auf der Zulassungsliste ausgerollt und diese Ausnahmen nach einem festgelegten Zeitplan wieder entfernt. Die Entwickler, die sich anfangs am stärksten dagegen wehren, werden in der Regel zu den größten Befürwortern, sobald sie die Gründe dafür verstehen.

Ein wichtigerer Punkt: Hier greift das End-to-End-Prinzip. Man kann nicht willkürlich einzelne Schritte auswählen. Eine zu strenge Build-Phase bei gleichzeitig laxer Release-Governance erzeugt trügerische Sicherheit – genau das ist der Fehler, den die SPVS-Autoren beschreiben. Jede Phase muss parallel ablaufen, selbst wenn eine einzelne Kontrollmaßnahme isoliert betrachtet unverhältnismäßig erscheint.

Kosten: Für Phase 1, die sich auf die L2-Konformität für ein kleines Unternehmen konzentriert und von DevOps-, Sicherheits- und Engineering-Prüfern durchgeführt wird, wurde etwa ein Monat Entwicklungszeit aufgewendet. Die Investition amortisiert sich schnell. Ein einziger verhinderter Lieferkettenvorfall deckt die Kosten um ein Vielfaches. Größere Unternehmen sollten entsprechend mehr einplanen, aber die phasenweise Struktur (L1 – L2 – L3) stellt sicher, dass bereits vor Abschluss des Programms ein Mehrwert entsteht.

Was kommt als Nächstes?

SPVS v1.5 steht mit KI-bezogenen Kontrollfunktionen in den Startlöchern: Herkunft von KI-gestütztem Code, guardrails Für CI-Workflows, die LLMs aufrufen, sollten die Protokolle für KI-generierte pull requestsund Abwehrmaßnahmen gegen neue Bedrohungen wie Slopsquatting, bei dem Angreifer Paketnamen registrieren, die von KI-Programmierassistenten generiert werden, sowie gegen die von CrowdStrike gemeldete, betriebsbereite KI-generierte Malware. Organisationen, die bereits KI-gestützte commitDie internen Entwicklungsrichtlinien der Abteilungen und PRs sehen diese Anpassung eher als schrittweise Anpassung denn als neues Arbeitsprogramm.

Version 2.0 soll die Laufzeitüberwachung und die Anforderungen an den Lebenszyklus von Anmeldeinformationen vertiefen. Ein sinnvoller organisatorischer Fahrplan: Die verbleibenden Lücken auf Ebene 3 bis Ende des zweiten Quartals 2026 schließen, einschließlich SLSA provenance integriert standard CI/CDManuelle Zugriffskontrollen für Produktionsumgebungen und ein zentralisierter Identitätsanbieter werden eingerichtet, anschließend wird in den Wartungsmodus gewechselt. Jedes neue Repository ist von Anfang an konform, und jede vierteljährliche Prüfung deckt Abweichungen frühzeitig auf.

Ein herzliches Dankeschön an Farshad Abasi, Cameron Walters und die OWASP SPVS Arbeitsgruppe. Projekte wie dieses senken die Anforderungen für alle Organisationen, die Lieferkettensicherheit systematisch statt reaktiv gestalten wollen.

Wichtige Erkenntnisse

Ein paar Dinge, die auch außerhalb unseres spezifischen Kontextes gelten:

• So probieren Sie es aus: Laden Sie die SPVS-Anforderungen als CSV-Datei herunter und ordnen Sie Ihre aktuellen Kontrollen einer Tabellenkalkulation zu. Innerhalb eines Tages erfahren Sie, ob die Anforderungen erfüllt sind.
• Wähle ein Zielniveau aus und erreiche es, bevor du das nächste angehst. Der Übergang von L1 zu L2 zu L3 ist ein Vorteil, keine Einschränkung.
• Das pipeline ist das Ziel. Anwendungszentrierte Steuerungen sind notwendig, aber nicht ausreichend; behandeln Sie die pipeline als erstklassige Angriffsfläche.
• Überprüfen Sie das Ganze pipeline, nicht ein einziges Stück. Eine starke Abhängigkeitsanalyse kann eine schwache Release-Governance oder unüberwachte Build-Umgebungen nicht ausgleichen.
• Tabellenkalkulationen sind Momentaufnahmen; die Abweichung ist ein kontinuierlicher Prozess. Entwickeln Sie Automatisierungslösungen, sei es auch nur ein einfaches internes Tool, um Abweichungen zwischen Audits zu erkennen.
• Die organisatorische Arbeit ist schwieriger als die technische. Planen Sie ausreichend Zeit für Gespräche und Pilotprojekte vor der Veröffentlichung ein und erläutern Sie, welche spezifische Bedrohung durch die einzelnen Kontrollmaßnahmen abgewehrt wird.

Um mehr zu lesen

• OWASP: und geschützt Pipeline Verification Standard (SPVS) v1.0OWASP-Projektseite.
• Farshad Abasi: Warum wir OWASP SPVS gegründet habenOWASP SPVS-Artikel.
• Farshad Abasi: Pipeline Die Angriffe werden immer schlimmer. So können Sie sich vorbereiten.OWASP SPVS-Artikel.
• Farshad Abasi: OWASP SPVS im Vergleich zu anderen Lieferketten-FrameworksOWASP SPVS-Artikel.
• OWASP: Top 10 CI/CD SicherheitsrisikenOWASP-Projektseite.
• SLSA: Lieferkettenebenen für Softwareartefakte. slsa.dev.
• OpenSSF: Scorecardsecurityscorecards.dev.