Skip to contentLockpick
Docs

Verify Codex Security fixes on your live site

After a code assistant patches your code, ask Lockpick whether the deployed site still shows the problem, and get back fixed, still open or inconclusive.

Lockpick works with Codex Security. They look at different halves of the same problem. Codex Security reads your source code and patches it. Lockpick checks what is actually deployed at your URL. After a patch, one question is left, does the live site still show the problem. Lockpick answers it.

Lockpick is not affiliated with or endorsed by OpenAI. Codex Security is named here only to say that Lockpick composes with it.

The loop

  1. Codex Security finds an issue in your code and, after codex-security patch, proposes or applies a fix.
  2. You deploy the fix to the site.
  3. Lockpick checks the deployed URL again and returns one of three states.

What checking again can prove

A new scan is compared with the earlier one. Each earlier finding comes back as one of these.

  • Fixed. Lockpick read the same resource again and did not observe the finding. It is a statement about that one resource, not a certificate for the whole site, and not proof that a credential was rotated.
  • Still open. The finding is still observed. If you expected a fix, check that the patch is actually live at the URL Lockpick tested.
  • Inconclusive. Lockpick could not check this time, because the site blocked the scan, rate-limited it, or the depth did not reach it. Inconclusive is never fixed.

Lockpick never marks something fixed because a patch merged or a ticket closed. It reports only what it observed on the deployed site.

Do it from your coding agent

Connect Lockpick to your assistant (see Codex and permissions), then ask it to verify the fix. The skills pack’s lockpick-fix skill walks it through the repair and checking it again.

Prompt
I deployed the fix for the SSRF Codex Security found at /api/fetch. Use Lockpick to check the live URL again and tell me if it is fixed, still open or inconclusive.

Do it from the CLI

Checking again needs permission to start scans on the site and a CLI key with Pulse access. Deep scans also need ownership proof and approval.

A supported public-record (DNS) finding can be re-read for free, which leaves the grade unchanged.

DNS recheck
lockpick recheck <scan-id> --dns <finding-id>

Anything reachable over HTTP needs a fresh scan at the finding's depth, which uses one scan from your monthly allowance. Read the cost first.

Recheck a deployed HTTP finding
lockpick status
lockpick pulse <site>
lockpick compare <run-id>

lockpick compare prints the same three states for each earlier finding.

Bring the code findings in

To see Codex Security's code findings beside Lockpick's live findings, correlate them on your machine.

Correlate, nothing leaves your machine
lockpick import findings.json --run <run-id>

It reads a Codex Security findings.json or a SARIF 2.1.0 file, matches each code finding to the live findings on the same route, and raises confidence when Lockpick saw that route answer without signing in. By default nothing about the code findings leaves your machine. Only an explicit --upload builds a minimal set of correlation keys, the route paths, rule ids and severities, and shows you exactly what it would share first.

Was this helpful?

On this page