Sicherheitslücken im Repository kostenlos aufdecken

Um Sicherheitslücken in Ihrem Repository kostenlos zu erkennen, kombinieren Sie drei Ebenen: einen Dependency-Scanner (npm audit, pip-audit oder OSV-Scanner), einen Secret-Scanner (Gitleaks) und einen Code-Scanner (Semgrep Community Edition). Führen Sie diese bei jedem Pull Request aus. Keines dieser Tools findet jedoch fehlende Autorisierungsprüfungen – ergänzen Sie dafür daher einen Laufzeittest.

npm audit --audit-level=high
pip-audit -r requirements.txt
gitleaks git . --no-banner
semgrep scan --config p/default --metrics=off --error

Was sich durch Vercel Security Review ändert

Vercel Security Review ist ein Feature des Vercel Agent und befindet sich seit dem 2. November 2026 in der Public Beta. Es scannt jeden Push in einem verknüpften GitHub-Repository, analysiert das Diff sowie den umgebenden Code, prüft die Erreichbarkeit der Änderungen und validiert jeden Befund noch einmal, bevor er gemeldet wird.

Das von Vercel genannte Beispiel ist der Anlass für diesen Beitrag: Bei einer Änderung an einem Rechnungs-Endpunkt wurden Rechnungen per ID abgefragt, ohne die Organisation zu prüfen. Dadurch konnte jeder angemeldete Benutzer die Rechnungen fremder Organisationen herunterladen. Das ist ein Logikfehler – und musterbasierte Scanner tun sich mit Logikfehlern schwer.

Wer das Feature nutzen kann:

In der Dokumentation von Vercel wird auch die Grenze deutlich: Es analysiert lediglich Code, nicht die laufende Anwendung, und ersetzt keinen Penetrationstest. Falls Sie die Voraussetzungen nicht erfüllen oder diesen Artikel nach dem kostenlosen Zeitraum lesen: Die restlichen Schritte in diesem Leitfaden kosten Sie keinen Cent.

Was ein Schwachstellen-Scan im Repository abdecken sollte

Ein vollständiger Schwachstellen-Scan eines Repositories prüft vier Bereiche: bekannte Sicherheitslücken in Abhängigkeiten, in Git eingecheckte Zugangsdaten (Secrets), unsichere Code-Muster wie Injections sowie die Autorisierungslogik. Für die ersten drei Bereiche gibt es kostenlose, ausgereifte Scanner. Der vierte Bereich hängt von der Semantik Ihres Codes ab und erfordert daher einen Test gegen eine laufende API.

Ein gelöschter Schlüssel verbleibt in der Git-Historie. Scannen Sie daher stets die gesamte Historie und tauschen Sie alle echten Zugangsdaten umgehend aus. Wie Sie Schlüssel im API-Traffic und in Test-Collections aufspüren, erfahren Sie in unserem Leitfaden zur Erkennung von API-Key-Leaks.

Kostenlose Schwachstellen-Scanner im Vergleich

Preise und Lizenzen wurden am 5. November 2026 überprüft. Keines der Kommandozeilen-Tools erfordert ein Konto oder eine Kreditkarte für die Befehle in diesem Leitfaden.

Zwei Hinweise zu den Lizenzen: Die Community-Regeln von Semgrep unterliegen der Semgrep Rules License, die die interne geschäftliche Nutzung erlaubt, jedoch nicht deren Weiterverbreitung oder das Anbieten als Dienstleistung. Und falls Sie Trivy einsetzen, beachten Sie CVE-2026-33634: Angreifer hatten im März 2026 Teile des Trivy-Ökosystems kurzzeitig kompromittiert. Verwenden Sie daher ein aktuelles Release und pinnen Sie Actions stets auf einen Commit-SHA.

Repository-Scan mit wenigen Befehlen: Unsere Ergebnisse

Wir haben eine kleine Express-Rechnungs-API erstellt und in ein lokales Repository committet. Sie enthielt vier veraltete npm- und drei veraltete Python-Abhängigkeiten, zwei Dummy-Keys (im Format von Stripe und AWS), eine SQL-Injection, eine Command-Injection sowie eine Route, die jedem angemeldeten Benutzer Rechnungen beliebiger Organisationen zurückgibt.

Anschließend haben wir jedes Tool am 5. November 2026 unter macOS ausgeführt:

npm audit
pip-audit -r requirements.txt --no-deps --disable-pip
osv-scanner scan source -r .
trivy fs --scanners vuln,secret .
gitleaks git . --no-banner
semgrep scan --config p/default --metrics=off
semgrep scan --config p/nodejsscan --metrics=off

Drei Dinge fallen besonders auf:

• Zahlenwerte sind nicht vergleichbar. Ein Paket, ein Advisory und ein Befund sind unterschiedliche Einheiten, und jedes Tool analysiert andere Daten. Vergleichen Sie daher, was erkannt wurde, und nicht die reinen Gesamtzahlen.
• Ein einzelner Secret-Scanner reicht nicht aus. Sowohl Gitleaks als auch Trivy haben den Key im AWS-Format übersehen.
• Die Wahl des Regelwerks ist entscheidend. Das Standard-Regelwerk von Semgrep übersah eine per String-Verkettung aufgebaute SQL-Abfrage. p/javascript, p/nodejs, p/owasp-top-ten und p/sql-injection lieferten für dieses Repository keine Treffer, während p/nodejsscan die Lücke fand.

Keines der Tools schlug bei der Rechnungs-Route an. Da es sich hierbei um ein einzelnes kleines Repository handelt, sollte dies als Demonstration und nicht als Benchmark verstanden werden. CodeQL wurde nicht ausgeführt.

GitHub-Repository bei jedem Pull Request scannen

Standardmäßige von GitHub gehostete Runner sind für öffentliche Repositories kostenlos. Bei privaten Repositories beinhaltet GitHub Free ein monatliches Guthaben von 12 $, was nach aktuellem Tarif rund 2.000 Minuten auf einem Linux-Runner mit 2 Kernen entspricht. Dieser Workflow nutzt einfache Shell-Befehle, sodass Organisationen keinen Lizenzschlüssel für die Gitleaks-Action benötigen:

name: repo-scan
on:
  pull_request:
  push:
    branches: [main]
permissions:
  contents: read
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7 # pin to a commit SHA
        with:
          fetch-depth: 0
      - name: Dependencies (npm)
        run: npm audit --audit-level=high
      - name: Dependencies (Python)
        run: pipx run pip-audit -r requirements.txt
      - name: Secrets
        run: |
          curl -sSL https://github.com/gitleaks/gitleaks/releases/download/v8.30.1/gitleaks_8.30.1_linux_x64.tar.gz | tar xz gitleaks
          ./gitleaks git . --no-banner
      - name: Code patterns
        run: pipx run semgrep scan --config p/default --config p/nodejsscan --metrics=off --error

Alle vier Scanner beendeten den Durchlauf in unserem Test-Repository mit dem Exit-Code 1 – und ein Exit-Code ungleich null lässt den Job fehlschlagen. Entfernen Sie einfach die Schritte, die für Ihren Stack nicht relevant sind. Wie Sie API-Tests in dieselbe Pipeline einbinden, beschreibt unser Artikel zu Apidog CLI mit GitHub Actions.

Aktivieren Sie außerdem Dependabot-Warnungen. Diese sind in jedem Tarif kostenlos und schlagen auch unabhängig von Pull Requests an.

Die Sicherheitslücke, die Scanner übersehen: Autorisierungsfehler

Autorisierungsfehler sind für musterbasierte Scanner schwer zu erkennen, da der Code auf den ersten Blick vollkommen korrekt wirkt: eine valide Abfrage, ein valider Parameter und eine vorgeschaltete auth-Middleware. Der Fehler liegt in einer fehlenden Bedingung – und dass diese Bedingung erforderlich ist, lässt sich nur aus Ihrem Datenmodell ableiten.

// Every scanner passed this
db.query("SELECT * FROM invoices WHERE id = $1", [req.params.id]);

// The fix: scope the lookup to the caller's organization
db.query("SELECT * FROM invoices WHERE id = $1 AND org_id = $2",
  [req.params.id, req.user.orgId]);

Hierbei handelt es sich um Broken Object Level Authorization (BOLA), Platz 1 der OWASP API Security Top 10 2023. Die OWASP empfiehlt, bei jeder Anfrage, die eine vom Client bereitgestellte ID verwendet, die Zugriffsberechtigung zu validieren und automatisierte Tests zu schreiben, die Autorisierungsfehler bereits vor dem Deployment abfangen.

Coding-Agenten können hierbei unterstützen. Wir haben die Kommentare aus dem Test-Repository entfernt und Claude Code um ein Review gebeten – einmal mit und einmal ohne Hinweis auf Organisationen. Beide Male erkannte das Modell die problematische Rechnungs-Route. Allerdings ist dies kein völlig kostenloser Ansatz, da hierfür das Kontingent Ihres KI-Agenten beansprucht wird und die Ergebnisse zwischen Durchläufen variieren können.

Ein automatisierter Test liefert hingegen bei jedem Pull Request ein eindeutiges Ja oder Nein. Weiterführende Informationen zur Absicherung auf API-Ebene finden Sie in unseren Beiträgen zur automatisierten Erkennung von API-Schwachstellen, der Übersicht der besten API-Security-Scanning-Tools sowie der Checkliste für API-Sicherheitstests.

Autorisierung durch Coding-Agenten mit Apidog CLI testen lassen

Schreiben Sie diesen Test nicht für jede Route manuell. Überlassen Sie das Ihrem Coding-Agenten mit der Apidog CLI: Er analysiert Ihre Routen, erstellt für jede geschützte Ressource einen Test und liefert eine Testsuite, die direkt in der CI ausgeführt werden kann. Der kostenlose Tarif von Apidog unterstützt bis zu 4 Benutzer.

npm install -g apidog-cli@latest
apidog auth login --with-token <YOUR_TOKEN>
apidog skill install

Sie benötigen eine Testumgebung mit zwei initial angelegten Organisationen und jeweils einem Benutzer. Geben Sie Ihrem Agenten anschließend folgenden Prompt:

Read the routes in src/. For each route that returns data owned by an
organization, create an Apidog test scenario in project <id>: log in as
the Org A test user, request an Org B resource by ID, and assert the
status is 403 or 404. Add an Org A request for its own resource and
assert 200, so a broken login can't pass. Group the scenarios in a test
suite, run it against the staging environment, and summarize failures.

Der Agent prüft die Payload-Struktur, erstellt die Szenarien und führt die Testsuite aus:

apidog cli-schema get test-scenario-create
apidog cli-schema validate test-scenario-create --file scenario.json
apidog test-scenario create --project <id> --file scenario.json
apidog test-scenario import-steps <scenarioId> --project <id> --source endpoint --ids <endpointIds>
apidog test-suite create --project <id> --file suite.json
apidog run --test-suite <suiteId> --project <id> -e <envId> -r cli,junit

Der Positivtest ist entscheidend: Ohne ihn würde auch eine fehlerhafte Basis-URL einen 404-Status liefern, und der Test wäre aus den falschen Gründen erfolgreich.

Fügen Sie dieselbe apidog run-Zeile in den oben gezeigten Workflow ein – ausgeführt gegen ein Preview- oder Staging-Deployment mit vorbereiteten Testorganisationen, keinesfalls gegen Produktionsdaten. Die Befehlsreferenz zu apidog run erläutert die weiteren Parameter, und der Leitfaden zu Apidog CLI in Claude Code führt Schritt für Schritt durch das Agenten-Setup.

FAQ

Wie erkennt man Schwachstellen in einem Repository am besten kostenlos? Kombinieren Sie einen Dependency-Scanner, Gitleaks und Semgrep Community Edition und ergänzen Sie das Ganze um einen Laufzeittest für die Autorisierung. Kein einzelnes Tool konnte in unserem Test-Repository alle Schwachstellen aufdecken.

Ist Vercel Security Review kostenlos? Nur bis zum 10. November 2026 und ausschließlich für Pro- und Enterprise-Teams. Danach fallen die regulären Token-Preise des Anbieters zuzüglich 0,25 $ pro Million Tokens an. Repositories, die nicht auf Vercel deployt werden, werden derzeit noch nicht unterstützt.

Ist das Secret Scanning von GitHub für private Repositories kostenlos? Nein. Secret Scanning und CodeQL sind für öffentliche Repositories kostenlos; für private Repositories werden jedoch GitHub Secret Protection (19 $) oder GitHub Code Security (30 $) pro aktivem Committer und Monat benötigt. Dependabot-Warnungen sind für beide Repository-Typen kostenlos.

Kann Semgrep Autorisierungsfehler finden? Mit den von uns ausgeführten Regelsätzen wurde unsere Rechnungs-Route nicht beanstandet. Die Community Edition kann Datenflüsse nicht über eine einzelne Funktion oder Datei hinaus nachverfolgen – Sie können jedoch eigene Regeln für musterbasierte Eigenheiten Ihrer Codebasis definieren.

Ersetzen Scanner einen Penetrationstest? Nein. Scanner und automatisierte Tests decken bekannte Muster und zuvor definierte Testfälle ab. Ein Penetrationstest spürt dagegen Schwachstellen auf, an die Sie im Vorfeld nicht gedacht haben – und auch laut Vercels eigener Dokumentation ist das Review kein Ersatz dafür.