Tab · Build

Security

Know it won't ship broken. A plain-language scan for the footguns that hurt — secrets in git, env vars referenced but never declared, hard-coded localhost URLs, open CORS, sensitive-path drift — each finding paired with the exact file, line, and the fix.

OverviewGuardrailsVulnerabilitiesFile integrity

See it in motion

Where to find it

  • Localhost: http://localhost:4000/security.html?repo=<id>
  • Sub-rail: Guardrails · Vulnerabilities · File integrity — each at its existing URL so deep-links survive.
  • Keyboard: ⌘ K then sec, or g s jumps direct.
  • Today cockpit: The Vulnerabilities tile on Today links straight to this tab.

What it does for you

You'll catch the footgun before deploy.Guardrails scan for .env in git, committed secrets, open CORS, and a server bound to all interfaces — each with the exact file, line, and copy-pasteable fix. high findings are always actionable.
You'll see every npm CVE in one place.Vulnerabilities runs live npm audit across every tracked surface, grouped by severity. No more guessing which workspace is flagged.
You'll spot the unexpected edit.File integrity flags changes to sensitive paths vs. origin/main— auth, billing, CI files — with a colored diff and a guarded revert if it's wrong.

Configure

Nothing required — Security works out of the box once you've registered a repo. The integrity subtab needs read access to the working tree (already granted via the mirror).

  • Sensitive-path watchlist — defaults cover .env*, auth.*, billing.*, **/secrets/*; extend per repo via repos.config.json.
  • CODEOWNERS / branch-protection — the File integrity subtab can emit the hardening snippet for you.
  • npm audit cache — Vulnerabilities re-runs on demand from the subtab; results cache per-repo for the session.

Use it well

  1. Run the guardrail scan before every push.

    A red finding (high severity) is always actionable — the evidence panel includes the line of code and the rewrite. Amber findings are review-and-decide.

  2. Track npm audit findings as a rollup, not file-by-file.

    The Vulnerabilities subtab is the one place to track npm audit across the workspace tree, so you can prioritize one big-blast fix over ten low-severity bumps.

  3. Open File integrity weekly even when nothing's pinging.

    That's where surprises live — a teammate's AI touched .env.example while extracting a feature, or a CI workflow drifted. Catch it before it becomes a question in standup.

  4. Wire CODEOWNERS for sensitive paths.

    File integrity will print the snippet you can drop into .github/CODEOWNERS — it makes every sensitive-path edit require a named reviewer.

Examples

✓
Before opening a PR (Vince)
Open Security → run Guardrails → 0 high, 1 medium (a stale localhost URL in a test) → ignore for now → green-light the push.
⚠
When integrity flags a sensitive-path edit
If File integrity highlights a change to auth.ts or .env.exampleyou didn't intend to make, use the guarded revert button on the subtab. Don't commit the change just to make the flag go away.

Read more