Jeden Release oder Deploy aus deiner CI scannen

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.

Wo er läuft

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.

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, 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.