Shift-Left: Sicherheit wird zum Quality Gate

APIs ändern sich mit jedem Deploy. Ein im Januar geprüfter Endpunkt kann im Februar einen neuen Parameter, eine neue HTTP-Methode oder eine neue Rolle haben und damit eine neue Lücke. Ein Befund von vor zwölf Monaten sagt nichts über den heute ausgelieferten Stand aus. OWASP formuliert das im Kapitel What's Next For DevSecOps unmissverständlich: Scanning and penetration testing yearly are no longer enough. Stattdessen fordert OWASP continuous security testing across the entire software development life cycle sowie Sicherheitsautomatisierung in der Pipeline, ohne die Entwicklungsgeschwindigkeit zu bremsen.

Shift-Left bedeutet, Sicherheitstests so früh wie möglich und bei jeder Änderung auszuführen, nicht erst kurz vor oder nach dem Produktiv-Release. Der entscheidende Hebel ist das Quality Gate: Ein fehlgeschlagener Sicherheitstest bricht den Build ab, ein verwundbarer Stand erreicht die Produktion gar nicht erst. Genau diese Logik schreibt OWASP für BOLA (API1:2023) als Präventionsmaßnahme fest: Write tests to evaluate the vulnerability of the authorization mechanism. Do not deploy changes that make the tests fail. Der Test ist damit nicht Reporting, sondern Bedingung für das Ausliefern.

Wichtig ist die Abgrenzung zum Pentest: Ein jährlicher Penetrationstest und ein externes Audit bleiben sinnvoll, ersetzen aber keine kontinuierliche Prüfung. Sie sind Stichproben zu einem Zeitpunkt, die Pipeline prüft jeden Commit. Beides ergänzt sich, das eine geht nicht im anderen auf.

VerfahrenWas es prüftPipeline-PhaseAdressiertes Risiko
SASTQuellcode statisch, ohne AusführungBuild / Pull RequestInjection, fest verdrahtete Secrets
DASTLaufende API von außenTest (deployte Instanz)Fehlkonfiguration, Laufzeitverhalten
SCADrittanbieter-Abhängigkeiten, SBOMBuildUnsafe Consumption, Lieferkette
Contract-Tests AutorisierungZugriffsregeln pro Rolle/ObjektTestBOLA (API1), BFLA (API5)
OpenAPI-Spec-DiffingÄnderungen gegen freigegebene SpecBuild / GateImproper Inventory (API9), Misconfiguration (API8)
Secret-ScanningGeheimnisse in Code und HistoriePre-Commit / CISecrets-Leakage

Sicherheitsprüfungen in der CI/CD-Pipeline

Die Testarten: SAST, DAST, SCA, IAST

Die OWASP-DevSecOps-Guideline ordnet die automatisierten Prüfungen der Pipeline-Phase Vulnerability Scanning zu und unterscheidet mehrere komplementäre Verfahren. Jedes deckt einen anderen Fehlertyp ab, keines genügt allein.

  • SAST (Static Application Security Testing): Analyse des Quellcodes ohne Ausführung, typischerweise auf jedem Pull Request. Findet unsichere Muster, fest verdrahtete Geheimnisse und Injection-Pfade früh. OWASP nennt Werkzeuge wie Semgrep und Checkmarx; für Infrastructure-as-Code kommen Scanner wie Checkov und tfsec hinzu.
  • DAST (Dynamic Application Security Testing): Prüft die laufende, deployte API von außen, also gegen reale Antworten statt gegen Code. Geeignet, um Fehlkonfigurationen und Laufzeitverhalten zu finden, die statisch nicht sichtbar sind.
  • SCA (Software Composition Analysis): Untersucht Drittanbieter- und Open-Source-Abhängigkeiten auf bekannte Schwachstellen und Lizenzrisiken. Relevant für API10:2023 Unsafe Consumption of APIs und die Lieferkette insgesamt; eine SBOM macht den Bestand nachvollziehbar.
  • IAST (Interactive Application Security Testing): Instrumentiert die Anwendung während funktionaler Tests und beobachtet Datenflüsse zur Laufzeit, als Brücke zwischen statischer und dynamischer Sicht.

Für APIs gilt eine spezifische Grenze: Generische SAST- und DAST-Scanner erkennen Muster und bekannte Signaturen, aber keine Berechtigungs- und Logikfehler. Ob Nutzer A das Objekt von Nutzer B sehen darf, ergibt sich aus Identität, Rolle und Objektbesitz, nicht aus der Form des Requests. Diese Fälle brauchen eigene, kontextbewusste Tests.

Contract-Tests für Autorisierung und OpenAPI-Spec-Diffing

Die häufigsten und schwerwiegendsten API-Risiken sind Berechtigungsfehler: BOLA (API1:2023) und BFLA (API5:2023). Beide bestehen aus syntaktisch einwandfreien Requests, ein Signatur- oder Mustererkenner sieht hier nichts. Der richtige Test muss aktiv formuliert werden: Kann Nutzer A auf ein fremdes Objekt zugreifen? Kann ein regulärer Nutzer eine administrative Funktion auslösen, etwa durch Methodenwechsel von GET zu DELETE?

OWASP beschreibt im Authorization Testing Automation Cheat Sheet ein konkretes Vorgehen: Man pflegt eine Autorisierungsmatrix aus den Dimensionen Feature, logischer Rolle und optional Datenfilterung und leitet daraus Integrationstests ab, die bei jedem neuen Release laufen. So fällt sofort auf, wenn eine geänderte oder neu hinzugefügte Funktion gegen die definierten Berechtigungen verstößt. Der Hintergrund: Die meisten Autorisierungsprobleme entstehen erst, wenn Features in späteren Releases ergänzt oder geändert werden, ohne ihre Wirkung auf die Berechtigungen zu prüfen. Diese Tests sind Contract-Tests für Autorisierung: Sie schreiben die erwartete Zugriffsentscheidung als Vertrag fest und schlagen an, sobald der Code ihn bricht.

Parallel sichert OpenAPI-Spec-Diffing im Build den deklarierten Bestand ab. Jede Änderung wird gegen die freigegebene Spezifikation geprüft; neue, nicht reviewte Routen oder inkompatible Änderungen brechen den Build, bevor sie ausgeliefert werden. Das adressiert API9:2023 Improper Inventory Management und API8:2023 Security Misconfiguration direkt im Entwicklungsprozess. Wichtig ist die Grenze: Spec-Diffing prüft den bekannten, deklarierten Stand. Endpunkte, die nie in Spec, Ticket oder Review standen (Shadow- oder Zombie-APIs), rutschen durch reine Pipeline-Prüfung durch und brauchen ergänzend Laufzeit-Discovery.

Secret-Scanning in CI

Geheimnisse wie API-Schlüssel, Tokens und Passwörter gelangen regelmäßig in Repositories, CI-Konfigurationen, Docker-Images und kompilierte Artefakte. Einmal in der Git-Historie, bleibt ein Secret auch nach dem Löschen aus dem aktuellen Stand abrufbar; es muss als kompromittiert gelten und rotiert werden.

Das OWASP CI/CD Security Cheat Sheet nennt zwei Schutzlinien. Erstens dürfen Geheimnisse niemals fest in Code-Repositories oder CI/CD-Konfigurationsdateien stehen. Zweitens sollen Werkzeuge wie gitleaks oder git-secrets solche Geheimnisse erkennen. Das Ziel laut OWASP: verhindern, dass ein Secret überhaupt committet wird, und laufend überwachen, um Abweichungen zu entdecken. Praktisch heißt das:

  • Pre-Commit-Hook: blockiert Geheimnisse, bevor sie in die Historie gelangen.
  • CI-Gate: ein Scan auf jedem Push und Pull Request, der bei Fund den Build abbricht (Quality Gate).
  • Historien-Scan: periodische Prüfung der gesamten Git-Historie, nicht nur des aktuellen Diffs.

Geheimnisse gehören in einen dedizierten Secrets-Manager und nicht in Build-Variablen im Klartext; OWASP verlangt zudem Verschlüsselung nach anerkannten Standards. Vertiefung zur Leak-Vektorik und Gegenmaßnahmen auf der Seite zu API-Secrets und Key-Leakage.

NIST SP 800-204D: Sicherheit in den CI/CD-Phasen verankern

Wie Sicherheitsmaßnahmen konkret in eine Pipeline gehören, beschreibt die NIST-Publikation SP 800-204D (Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines, 2024). Sie geht von cloud-nativen Microservice-Architekturen aus und betrachtet die Pipeline als Abfolge der Phasen Build, Test, Package und Deploy, durch die der Quellcode als Teil der Software-Lieferkette (Software Supply Chain) läuft.

Der Kerngedanke: Sicherheitskontrollen werden nicht nachgelagert, sondern phasenweise in genau diese Schritte integriert. Das umfasst die Absicherung der Lieferkette, also Herkunft und Integrität von Abhängigkeiten und Build-Artefakten, sowie die Verankerung von Prüfungen entlang von Integration und Auslieferung. Für eine API-Pipeline ordnet sich das so ein:

  • Build: SAST und Secret-Scanning auf dem Quellcode, SCA und SBOM-Erzeugung für Abhängigkeiten.
  • Test: Contract-Tests für Autorisierung (BOLA/BFLA), DAST gegen die laufende Instanz, OpenAPI-Spec-Diffing als Gate.
  • Package: Signieren und Integritätsprüfung der Artefakte, keine Geheimnisse im Image.
  • Deploy: Freigabe nur konformer Builds, Übergabe des Inventars an die Laufzeit-Durchsetzung.

SP 800-204D liefert damit den Rahmen, der die einzelnen Verfahren (SAST, DAST, SCA, Spec-Diffing, Secret-Scanning) zu einer durchgehenden, automatisierten Kette verbindet und nicht zu losen Einzelmaßnahmen.

Reproduzierbare Befunde in den Werkzeugen der Entwickler

Ein Sicherheitsbefund ist nur dann wirksam, wenn er behoben wird. OWASP hält im DevSecOps-Kapitel ausdrücklich fest, Findings zeitnah und within the tools development teams are using (not PDF files) zu liefern, das Team bei der Behebung zu begleiten und jeden Befund mit einem konkreten Angriffsszenario greifbar zu machen, to make it real.

Für API-Logikfehler heißt das: Ein Befund braucht den exakten Request, die manipulierte ID oder die geänderte Methode und die beobachtete Antwort. Erst damit ist er reproduzierbar und kann als dauerhafter Regressionstest in die Suite übernommen werden, sodass dieselbe Lücke nicht erneut ausgeliefert wird. Ein PDF-Report ohne ausführbaren Nachweis erzeugt dagegen Reibung und veraltet mit dem nächsten Deploy.

Praktisch bedeutet reproduzierbar in Entwickler-Werkzeugen: Befund als annotierter Pull-Request-Kommentar oder Pipeline-Output statt als externes Dokument, mit Schweregrad, betroffenem Endpunkt und einem ausführbaren Reproduktionsschritt. So schließt sich der Shift-Left-Kreis: Der Test wird zum Quality Gate, der Befund wird zum Test, und der nächste Build prüft genau diese Bedingung erneut. Wie sich diese drei Schritte (Bestand kennen, kontinuierlich das Richtige testen, am Gateway durchsetzen) zu einem Gesamtbild fügen, beschreibt die Seite API Security sicherstellen.

Quellen

Weiterlesen
UmsetzungAPI Security sicherstellen RisikoBOLA (API1) RisikoAPI-Secrets & Key-Leakage