Pre ship security

Pre-Ship Security

This is the last security gate before production: a quick, repeatable review of the finished code. It verifies that nothing slipped through what secure-coding prevented during the build.

Analogy: secure-coding is the seatbelt you wear while driving. A deep audit (Trail of Bits, fuzzing) is the garage that x-rays every part. This skill is the walk-around inspection before a road trip — lights, tire pressure, fuel. Quick, done every time, catches the obvious before you pull out of the driveway.

It does not replace a professional audit for high-risk apps — its job is to tell you when you need one. Security is never 100%; this skill is honest about that.

Trigger

Run when the user is about to deploy, merge to main, launch, or asks "is this safe to ship?". It pairs with secure-coding (which ran during the build) and deployment (which ships it).

Discovery (max 3 questions, only if unknown)

1. What does the app handle — payments, personal data (PII), health, or crypto/keys?
2. Is this the first production launch, or an incremental deploy?
3. Public-facing or internal-only?

Step 1 — Automated quick scans

• npm audit --omit=dev (or pnpm audit) → fix high/critical advisories; don't ship known-vulnerable dependencies.
• Secret scan: npx gitleaks detect (and check git history) → no API keys, tokens, or .env committed. If something is found, rotate the secret — deleting the commit is not enough, it's in the history.
• Confirm .env, .env*.local, *.pem, *.key are git-ignored.
• Client-bundle leak check: grep the built JS for known key prefixes; on Vite, anything that isn't VITE_-prefixed must be absent from the bundle.

Step 2 — Review the diff against the prevention checklist

Re-check the finished code — the secure-coding rules, now verified instead of assumed:

• Authz on every endpoint? Each route checks the user and resource ownership (no IDOR). A route with no explicit check is the bug.
• Input validated? Every handler parses input with a zod .strict() schema; no req.body spread into a DB write (mass assignment).
• No raw SQL concatenation — parameterized queries / ORM only.
• CORS is an explicit allowlist, not * with credentials.
• Security headers present (Helmet or platform headers): CSP, HSTS, X-Content-Type-Options.
• Webhooks verify signatures (Stripe, etc.) and read the raw body correctly.
• Errors don't leak stack traces in prod; logs contain no PII, tokens, or passwords.
• Auth routes rate-limited; passwords hashed with bcrypt/argon2.

Step 3 — Risk gate (escalate when needed)

Based on Discovery answer 1, decide whether a deeper review is required — and be explicit that deep auditing is out of this plugin's scope on purpose:

• Handles money, PII at scale, health data, or crypto/keys → recommend a deep audit before or shortly after launch, and point to specialized tooling:
  • Static analysis: Semgrep / CodeQL (e.g. the static-analysis or Trail of Bits skills).
  • Dependency / supply-chain: Dependabot, Snyk, supply-chain auditors.
  • Fuzzing: only if there's parsing, crypto, or native code — AFL++, libFuzzer (the testing-handbook skills). Not relevant to a typical CRUD SaaS.
• Standard low-risk CRUD SaaS → the checks above are a reasonable bar for launch. Say so honestly: this is a review, not a guarantee.

Output

Deliver: the scan results (audit + secrets), a pass/fail list against the checklist with the exact file:line of anything to fix, and a clear verdict — "safe to ship at this risk level", "fix these N items first", or "high-risk: get a deep audit". Never claim the app is fully secure.

Reference

OWASP Cheat Sheet Series (~29k⭐), npm audit, gitleaks (~18k⭐), Helmet. Escalation targets: Semgrep/CodeQL, Trail of Bits skills, testing-handbook (fuzzing), Snyk/Dependabot.