Drydock
Your AI Production Engineer

Your app works. What might you be missing?

Drydock checks your code for exposed secrets, risky patterns and setup gaps — then explains what it found and what you can do next.

See an example report

Public GitHub repos only. We download the source for an online audit.

The scan runs in the background — you get a link you can come back to.

No account. No card.

Scan a ZIP on your device — your code stays with you

Local static checks · ZIP up to 50 MiB · Initial download required.

See what you get for free

See example findings, source references and suggested next steps. This example shows static checks only. A free online audit also includes a limited model preview when available; static results remain available when it cannot run.

Free report exampleIllustrative data — not a real audit

A short example of the free report when model review is unavailable. These selected static checks show what was observed, what remains unverified, and what to do next. All values are synthetic.

3 example observations

Example archive: 8 files

1 critical1 low
  • A value matches a Stripe live-key format.

    Potential critical impact

    Static signal — unverified

    A valid key may allow payment operations within its permissions. A format match does not establish that this key works or which operations it permits.

    Evidence and conditions
    Source check
    A static rule emitted this observation. Its consequence was not tested.
    Required conditions — not checked
    Not recorded; do not assume the conditions for harm are satisfied.
    Consequence check
    No independent verification recorded.

    Check whether this is a fixture. Rotate an exposed real key and store its replacement in server configuration.

    Stripe live secret key · app/api/checkout/route.ts:1 · sk_l****(32 chars)

  • An environment configuration file is included in the archive.

    Potential low impact

    Static signal — unverified

    .env.production contains only recognized frontend-public settings with simple URLs or build values. Their names use frontend-public conventions. File presence alone is not evidence of credential exposure.

    Evidence and conditions
    Source check
    A static rule emitted this observation. Its consequence was not tested.
    Required conditions — not checked
    Not recorded; do not assume the conditions for harm are satisfied.
    Consequence check
    No independent verification recorded.

    Keep intentional public build settings in version control when the project needs them. Put private credentials in separate ignored configuration; do not rotate values or delete this file solely because of its name.

    Public frontend configuration included in the archive · .env.production

Deployment inventory

  • No Dockerfile was found in the supplied archive.

    Informational

    Deployment inventory — informational

    Deployment configuration files found: deploy/demo.service. This is file inventory only; configuration validity and live deployment are not checked.

    Evidence and conditions
    Source check
    A static rule emitted this observation. Its consequence was not tested.
    Required conditions — not checked
    Not recorded; do not assume the conditions for harm are satisfied.
    Consequence check
    No independent verification recorded.

    Review existing deployment instructions; add a Dockerfile only if containers are needed.

    No Dockerfile found in the archive

Example scope and scan record

3 observations: 2 in source, 0 in tests/examples, 1 informational, 0 with contradicted syntax premises.

Security
Partly checked · 2 unverified findings
Auth
Not checked
Testing
Partly checked
Deploy
Partly checked
Money & Data
Not checked
Frontend
Not checked
Scan record
Archive SHA-256
570014dfbe0f0d2bc579e1757115947e3835dbe3b503ffe555aae5abf0fe29ea
Git commit
Not recorded for this archive
Scan engine
illustrative-demo
Files in archive
8
Static checks run
secrets, project_files
CVE Program
Not recorded or unreadable for this audit
Last responding model
No model response recorded
Model responses
0
Review areas applied
None
Files eligible for model review
0
Unique files submitted to model
0
Eligible files not submitted
0
Model limits / skip reasons
None recorded
Model finding processing
No model response processed
Files not submitted: No keyword match in configured review areas
0
Files not submitted: Matching review areas were not reached
0
Files not submitted: Outside file-selection budgets of attempted areas
0
Files not submitted: Removed to fit the request window
0
Static scope: secrets
Illustrative scope: secret-format matching in an 8-file synthetic archive. Credential validity, permissions and runtime use were not checked.
Static scope: project_files
Illustrative scope: archive file inventory and environment configuration inspection. File presence does not establish deployment or successful CI/test execution.
Static scope: example
Selected checks only: secrets and project_files. Other static analyzers, model review and dependency vulnerability checks are outside this example.
Python manifests
0 found
JavaScript manifests
1 found: package.json
Lockfiles
0 found
CI workflows
1 found: .github/workflows/ci.yml
systemd units
1 found: deploy/demo.service
Dockerfiles
0 found

File presence is not a deployment check. Submitted files may be excerpted; submission does not prove full review. Model cost is not recorded in this report.

This is a source review. Static signals and model hypotheses need verification. A repeated model claim is not independent evidence.

Runtime behaviour, payment replay and crash recovery, user isolation, and live deployment configuration have not been verified here. Check the cited code and reproduce the claimed consequence in an isolated test environment before applying a suggested fix.

What we go looking for

Security risks and project setup gaps worth checking before a demo handles real users. These are examples of the static checks included in the free audit; each report explains what was checked and its limits.

  • Credentials sitting in the code

    AWS keys, GitHub tokens, Stripe live keys, Supabase service keys, bot tokens, private keys — committed to the repository, where anyone who gets the code gets them too.

  • Secrets that slipped into git

    A .env committed by mistake, or a .gitignore that never covered the files holding your keys. Both are quiet until they aren't.

  • Access checks that may be missing

    Inconsistent identity checks between related Python/FastAPI routes, and supported Supabase patterns where row-level security is missing or a service key reaches browser code. These are source signals to verify, not proof that a route is publicly reachable.

  • Risky queries, requests and file access

    Supported patterns for SQL injection, caller-controlled outbound URLs, disabled TLS verification, unsafe deserialization and path traversal. Coverage depends on the language, framework and code structure.

  • No recognised test files

    No test files matching the scanner's supported conventions in the submitted source. Tests maintained elsewhere or in an unrecognised format may be outside this check.

  • Gaps in project setup

    No recognised CI workflow or Dockerfile in the submitted source. These are configuration inventory findings: the app may use another build or deployment process.

The scan is free. The fix is what you pay for.

Free, no account, no card

Static checks for secrets, supported security and access-control patterns, and project setup. The report includes source references, explanations and guidance where available.

A limited model security preview reviews selected code when available. It does not cover every file or the full authentication review. Static results remain available if the preview is unavailable or incomplete. The report shows which model analysis completed and any limits that affected it.

Every report shows findings and verification limits. Neither the free scan nor the deeper review provides a validated readiness score out of 10. Absence of findings does not establish safety.

Paid: the fix, as a pull request

A Fix Pack moves hardcoded credentials into environment variables, removes a committed .env, repairs .gitignore, and opens one pull request against your repository. You read the diff and decide whether to merge it. Bought once, for that one audit.

What a Fix Pack will not touch

Missing tests and missing CI come back as findings with guidance — not as code we wrote for you. Nor would we rewrite a login: doing that to an app we saw for the first time ten seconds ago is how an audit tool locks you out of your own product. And when there is nothing a Fix Pack can safely change, checkout refuses the sale instead of taking your money and reporting that it found nothing to do.

The deeper review

included with a Fix Pack

The full model review adds broader authentication and security analysis to the static checks and limited free preview. It examines selected source code for access-control and injection risks; it does not establish that every file or vulnerability was covered. Model findings are hypotheses to verify, with source references and stated limitations. You can't buy it on its own — buy a Fix Pack and the pull request arrives with a link to the full review of the same code.

How paying works →