Enji Guard

A real Enji Guard audit, start to finish

This is what you get before connecting your own repo. The example below is a fictional checkout service. Your report uses your repository’s real findings, score, and files.

Executive summary

Sign-in, access control, and tenant separation look solid, with one critical configuration issue to fix first: a live payment key is exposed on a public route. Guard confirmed 1 critical, 2 high, and 4 medium findings across code, dependencies, tests, and runtime. Fixing the exposed key and the admin auth gap moves this repo from “risky” to “reviewable” in an afternoon.

What we checked

  • Sign-in and session handling
  • Access control and tenant separation
  • Incoming data, uploads, and integrations
  • Dependencies and supply chain
  • Test quality, not just coverage
  • Runtime behavior of the linked app
  • Secrets and configuration defaults

Findings, ranked by severity

Each finding says what is wrong, why it matters, and exactly where to look. No scanner jargon.

SeverityFindingWhy it mattersWhere to look
CriticalLive Stripe secret key exposed on a public routeGET /api/health returns STRIPE_SECRET_KEY to anyone, no login required. An attacker can read customers and move money through your Stripe account.apps/api/src/routes/health.ts:5
HighAdmin endpoint reachable without an auth checkThe tenant-delete route runs without verifying the caller is an admin, so any signed-in user can reach it.apps/api/src/admin/tenants.ts:22
HighNext.js is several releases behind a fixed lineA direct runtime dependency on the deployable web surface, with known fixes available.apps/web/package.json
Mediummulter upload dependency behind a fixed releaseResolved through the API runtime path; a reviewed update is available.apps/api/package.json
MediumImported package has no matching upstreamA likely hallucinated dependency an attacker could register and ship malicious code under.apps/api/package.json
MediumThree tests assert truthy and prove nothingGreen checks that create false confidence in paths nobody actually verifies.apps/api/test/checkout.spec.ts
MediumCheckout logic duplicated across two modulesFixes drift apart and the next change has to touch both copies.apps/api/src/checkout, apps/web/src/checkout

Scorecard

9 / 10
Authentication and sessions

Strong

7 / 10
Access control and tenancy

One gap

4 / 10
Dependencies

Updates pending

5 / 10
Test quality

Weak assertions

6 / 10
Maintainability

Some duplication

acme/checkoutPrivate

Critical: live Stripe key exposed on /api/health

Open
Enji Fleetbotopened issue #128

GET /api/health returns STRIPE_SECRET_KEY with no authentication. Rotate the key and remove it from the response. File: apps/api/src/routes/health.ts, line 5.

acme/checkoutPrivate

fix: remove exposed Stripe key from /api/health

Open
Enji Fleetbotopened pull request #129

Pull request, ready for review

apps/api/src/routes/health.ts1 changed file
- key: process.env.STRIPE_SECRET_KEY,
+ status: "ok",
Waiting for review, no automatic merge

Improvement checklist

  1. Fix first:

    1

    remove and rotate the exposed Stripe key, then add the missing auth check on the admin route.

  2. Then:

    2

    update Next.js and the multer path, and replace the package that has no upstream.

  3. Then:

    3

    strengthen the three weak tests so they fail when the behavior is wrong.

  4. Ongoing:

    4

    schedule a recurring audit so new AI-written code gets the same check.

What we need access to

A scoped, revocable GitHub App, never a personal access token. Audits run in ephemeral workspaces that are deleted after each run, and we never train models on your code.

What we never do automatically

Guard never merges code, never deploys, and never touches production without a person in the loop. Findings and fixes stay explicit and reviewable.

Like this format? Run it on your repo.

Connect a repo and get your own audit report in a few minutes. No card.

Run a free auditSee pricing