# Jeden Release oder Deploy aus deiner CI scannen

Starte bei jedem Release oder Deploy einen Pulse- oder Deep-Scan deiner Website, aus GitHub Actions, Vercel, GitLab, Bitbucket, CircleCI oder einem Deploy-Skript.

Diese Seite ist für alle, die deine Website bauen und veröffentlichen. Wenn das nicht du bist, schick ihnen den Link.

Ein Release-Scan läuft dort, wo deine Website veröffentlicht wird. Er startet einen Pulse- (oder Deep-) Scan deiner Website, wartet auf das Ergebnis, meldet es und stoppt die Veröffentlichung, wenn der Scan etwas mit der Schwere findet, die du wählst, oder schlimmer. Deine Live-Website läuft in jedem Fall weiter. Jeder Release-Scan verbraucht einen Scan aus deinem Monatskontingent, mit denselben Grenzen und Eigentumsprüfungen wie ein Scan, den du in Lockpick startest. Zähle deshalb, wie oft du veröffentlichst.

## Einrichten

1. Öffne deine Website in Lockpick, wähle **Einstellungen** und dann **Release-Scans einrichten**.
2. Erstelle einen **CI-Schlüssel**. Kopiere ihn sofort: Lockpick zeigt ihn nur einmal.
3. Speichere ihn in den Secrets deiner CI als `LOCKPICK_CI_KEY`.
4. Öffne auf der Seite Release-Scans die Einrichtung für den Ort, von dem deine Website veröffentlicht wird, und kopiere sie in dein Repository. Deine Website ist dort bereits eingetragen.

> **Careful**
>
> Bewahre den Schlüssel im Secret-Speicher deiner CI auf, nie in einer Datei in
> deinem Repository. Wer den Schlüssel hat, kann Scans deiner Website starten,
> die dein Kontingent verbrauchen.

## Wo er läuft

| Wo du veröffentlichst                 | Wann er scannt                                       | Wohin der Schlüssel gehört                             |
| ------------------------------------- | ---------------------------------------------------- | ------------------------------------------------------ |
| GitHub Actions                        | Wenn du einen Release veröffentlichst, oder von Hand | Repository-Secret `LOCKPICK_CI_KEY`                    |
| Vercel                                | Nach jedem Produktions-Deployment oder von Hand      | Repository-Secret `LOCKPICK_CI_KEY`                    |
| GitLab CI                             | Für Tags, nach deinen anderen Stages, oder von Hand  | Maskierte CI/CD-Variable `LOCKPICK_CI_KEY`             |
| Bitbucket Pipelines                   | Für Versions-Tags, oder von Hand                     | Gesicherte Repository-Variable `LOCKPICK_CI_KEY`       |
| CircleCI                              | Für Versions-Tags                                    | Umgebungsvariable des Projekts `LOCKPICK_CI_KEY`       |
| Fly.io, Railway, Render, alle anderen | Am Ende deines Deploy-Skripts oder CI-Jobs           | Umgebungsvariable `LOCKPICK_CI_KEY` aus deinen Secrets |

### GitHub Actions

Kopiere die Action mit den beiden Befehlen von der Seite Release-Scans in `.github/actions/lockpick-scan/` und füge dann den Workflow hinzu. Veröffentliche einen Release oder starte den Workflow im Tab **Actions**, dann beginnt der Scan. Die Job-Zusammenfassung zeigt das Ergebnis.

### Vercel

Wenn dein Vercel-Projekt mit einem GitHub-Repository verbunden ist, meldet Vercel jedes Deployment an GitHub. Der Vercel-Workflow hört auf diese Ereignisse und scannt nach jedem **Produktions**-Deployment, nie bei Previews. Dafür muss die Action ebenfalls in das Repository kopiert sein, und Vercel sendet diese Ereignisse nur an Workflows in deinem Standard-Branch.

Jedes Produktions-Deployment verbraucht einen Scan aus deinem Kontingent. Wähle das also nur, wenn du ein paar Mal im Monat in die Produktion deployst. Sonst scanne lieber bei Releases.

### GitLab, Bitbucket, CircleCI und Deploy-Skripte

Diese führen dasselbe Scan-Skript mit Node 20 oder neuer aus. Die Einrichtung lädt es von Lockpick herunter und setzt `LOCKPICK_SITE_ID`, `LOCKPICK_SCAN`, `LOCKPICK_FAIL_ON` und `LOCKPICK_API_URL`; der Schlüssel kommt aus `LOCKPICK_CI_KEY`. Das Skript schreibt die Zusammenfassung ins Job-Log und endet mit 1, wenn der Scan fehlschlägt, sodass deine Pipeline dort stoppt. Das ist der Vertrag des eigenständigen Skripts; die CLI verwendet für eine Schwelle für Feststellungen den Exit-Code 8. Siehe die [Vergleichstabelle](/de/docs/cli/ci#cli-and-release-scan-script-exit-codes).

Fly.io hat keine Deploy-Benachrichtigungen, und Railway- und Render-Deploys laufen meist aus einem CI-Job oder Skript. Füge das Skript deshalb nach deinem Deploy-Befehl hinzu (zum Beispiel `fly deploy` oder `railway up`).

Wenn du die Lockpick-CLI schon nutzt, funktioniert `lockpick pulse <site> --fail-on high` auch mit einem CI-Schlüssel, wobei der Schlüssel in `LOCKPICK_KEY` steht. Es läuft nur Pulse.

## Was ein CI-Schlüssel kann

Ein CI-Schlüssel funktioniert nur für eine Website. Er kann einen Pulse starten, einen Deep-Scan starten, wenn du das erlaubt hast, und diese Scans lesen. Er kann deine anderen Websites nicht sehen, keine Websites hinzufügen und nichts in Lockpick ändern.

Ein CI-Schlüssel läuft an dem Datum ab, das du bei der Erstellung wählst (30, 90, 180 oder 365 Tage), egal ob er benutzt wird. Die Seite Release-Scans zeigt, wann jeder Schlüssel zuletzt verwendet wurde und wann er abläuft. Widerrufst du dort einen Schlüssel, stoppt jede Pipeline, die ihn nutzt, sofort. Ein Schlüssel funktioniert außerdem nicht mehr, wenn die Person, die ihn erstellt hat, den Zugriff auf die Website verliert.

## Deep-Scans aus einem Release

Kreuze **Auch Deep** an, wenn du den Schlüssel erstellst, um Deep in der CI zu nutzen, und dann **Ich genehmige Deep-Scans meiner Website, die mit diesem Schlüssel gestartet werden**. Mit dem Haken genehmigst du Deep-Scans dieser Website, die mit diesem Schlüssel gestartet werden, sodass die CI nie darauf wartet, dass du jeden einzeln bestätigst. Jeder Deep-Scan braucht trotzdem:

* Deep in deinem Tarif und noch Deep in deinem Kontingent übrig;
* [einen Nachweis, dass dir die Website gehört](/de/docs/protect/prove-you-own-your-site), wobei der Eintrag beim Start des Scans noch veröffentlicht sein muss.

Setze dann `scan: deep` im GitHub-Workflow (oder wähle **deep**, wenn du ihn von Hand startest) oder `LOCKPICK_SCAN=deep` überall sonst.

## Wenn der Job fehlschlägt

Der Job schlägt fehl, wenn:

* offene Feststellungen auf oder über `fail-on` liegen (standardmäßig `high`; wähle `critical`, `medium`, `low` oder `none`);
* der Scan fehlgeschlagen ist, abgebrochen wurde oder nach dem Zeitlimit noch lief (der Scan läuft in Lockpick weiter);
* Lockpick den Scan nicht starten konnte, zum Beispiel wenn in diesem Monat keine Scans mehr übrig sind, Deep nicht erlaubt ist, der Eigentumsnachweis fehlt oder der Schlüssel abgelaufen ist. Der Job sagt dir, warum und was zu tun ist.

Die Zusammenfassung zeigt die Note, die offenen Feststellungen nach Schwere und einen Link zum Scan, wo jede Feststellung ihre Korrektur hat. Sie kopiert Details zu Feststellungen nie in deine Logs. Ein Scan, der nicht alles prüfen konnte, wird nach dem beurteilt, was er gesehen hat, und die Zusammenfassung sagt, dass einige Bereiche unbekannt sind.

Wenn du dieselbe Pipeline erneut ausführst, wird ihr Scan wiederverwendet, statt einen neuen zu starten. Das funktioniert bei GitHub Actions, GitLab CI, Bitbucket Pipelines und CircleCI. Ein Vercel-Deployment wird einmal gescannt, egal wie oft sein Ereignis eintrifft.

Ein Release-Scan, der besteht, ist keine Sicherheitszertifizierung. Was Lockpick nicht beurteilen konnte, gilt als unbekannt, nicht als bestanden.