Scan every release or deploy from your CI

This page is for whoever builds and publishes your site. If that isn't you, send them the link.

A release scan runs where your site ships from. It starts a Pulse (or Deep) scan of your site, waits for the result, reports it and stops the publish when the scan finds something at the severity you choose or worse. Your live site keeps running either way. Each release scan uses one scan from your monthly allowance, with the same limits and ownership checks as a scan you start in Lockpick, so count how often you publish.

Set it up

1. Open your site in Lockpick, choose Settings, then Set up release scans.
2. Make a CI key. Copy it straight away: Lockpick shows it once.
3. Save it in your CI's secrets as LOCKPICK_CI_KEY.
4. Open the setup for where your site ships from on the Release scans page and copy it into your repository. It already has your site filled in.

Where it runs

GitHub Actions

Copy the action into .github/actions/lockpick-scan/ with the two commands on the Release scans page, then add the workflow. Publish a release, or run the workflow from the Actions tab, and the scan starts. The job summary shows the result.

Vercel

When your Vercel project is connected to a GitHub repository, Vercel tells GitHub about each deployment. The Vercel workflow listens for those events and scans after each production deployment, never previews. It needs the action copied into the repository too, and Vercel only sends these events to workflows on your default branch.

Each production deployment uses a scan from your allowance, so pick this only if you deploy to production a few times a month. Otherwise scan on releases instead.

GitLab, Bitbucket, CircleCI and deploy scripts

These run the same scan script with Node 20 or later. The setup downloads it from Lockpick and sets LOCKPICK_SITE_ID, LOCKPICK_SCAN, LOCKPICK_FAIL_ON and LOCKPICK_API_URL; the key comes from LOCKPICK_CI_KEY. The script prints the summary in the job log and exits with 1 when the scan fails, so your pipeline stops there. This is the standalone script’s contract; the CLI uses exit code 8 for a finding threshold. See the comparison table.

Fly.io has no deploy notifications, and Railway and Render deploys usually run from a CI job or script, so add the script after your deploy command (for example fly deploy or railway up).

If you already use the Lockpick CLI, lockpick pulse <site> --fail-on high works with a CI key too, with the key in LOCKPICK_KEY. It runs Pulse only.

What a CI key can do

A CI key works for one site only. It can start a Pulse, start a Deep scan if you allowed it, and read those scans. It can't see your other sites, add sites, or change anything in Lockpick.

A CI key expires on the date you pick when you make it (30, 90, 180 or 365 days), whether or not it is used. The Release scans page shows when each key was last used and when it expires. Revoke a key there and every pipeline that uses it stops at once. A key also stops working if the person who made it loses access to the site.

Deep scans from a release

Tick Deep too when you make the key to use Deep in CI, then tick I approve Deep scans of your site started with this key. Ticking it is your approval for Deep scans of that site started with that key, so CI never waits for you to approve each one. Every Deep scan still needs:

• Deep in your plan, and Deep left in your allowance;
• proof that you own the site, with the record still published when the scan starts.

Then set scan: deep in the GitHub workflow (or pick deep when you run it by hand), or LOCKPICK_SCAN=deep anywhere else.

When the job fails

The job fails when:

• open findings are at or above fail-on (high by default; choose critical, medium, low or none);
• the scan failed, was cancelled, or was still running after the time limit (the scan keeps running in Lockpick);
• Lockpick couldn't start the scan, for example when no scans are left this month, Deep isn't allowed, ownership isn't proven, or the key expired. The job says why and what to do.

The summary shows the grade, the open findings by severity and a link to the scan, where each finding has its fix. It never copies finding details into your logs. A scan that couldn't look at everything is judged on what it saw, and the summary says some areas are unknown.

Running the same pipeline again reuses its scan instead of starting another. That works on GitHub Actions, GitLab CI, Bitbucket Pipelines and CircleCI; a Vercel deployment is scanned once however many times its event arrives.

A release scan that passes is not a security certification. Coverage that Lockpick could not assess is unknown, not passing.