Why the order matters
Not all findings are equal. A committed Stripe live key is an incident waiting to happen. A missing lockfile won't hurt anyone today. quality·vibes weights the six categories to match: secrets and credentials carries weight 30 in the overall score, injection 20, auth and data exposure 15 each, dependencies and transport 10 each. A sensible manual checklist follows the same order.
There's also a sequencing trap with secrets specifically: if you find a committed key, rotating it comes before anything else. Deleting the file doesn't help, because the key is still in git history and anyone who cloned or fetched the repo has it. Rotate first, then clean up.
What each step is actually looking for
The secrets step covers more than obvious API keys. Hardcoded passwords, JWTs, private key blocks, and database connection strings with credentials in them all count. The injection step is mostly about string-built SQL (f-strings, .format(), concatenation, template literals), plus eval/exec, shell commands built from variables, subprocess with shell=True, pickle, and yaml.load without SafeLoader.
The auth step checks the dangerous defaults: JWT 'none' algorithm, disabled signature verification, signing secrets like "changeme", Flask or Django debug mode, CORS wildcards paired with credentials, insecure cookie flags, and ALLOWED_HOSTS set to *. Data exposure is about files that should never be in the repo (.env, private keys, cloud service-account JSON, database dumps, .npmrc tokens) and whether .gitignore actually covers them.
Checklist done. Now what?
A checklist tells you what to look for. It doesn't find the instances. Grepping a codebase for every pattern above is slow and easy to get wrong, which is why most people skip it. quality·vibes automates the finding: every issue comes back with the file, the line, redacted evidence, why it matters, and how to fix it, ranked by severity.
Each finding also carries a ready-to-paste Claude prompt, so closing it is a paste into Claude Code rather than a research project. Pro adds a fix-everything mega-prompt covering all findings in severity order. One caveat: this is a heuristic static scan, not a pentest. It catches the problems that repeat. It can't promise there are no others.
how it works
- 01
Hunt for committed secrets
Search for API keys (AWS, Stripe, OpenAI, Anthropic, GitHub, Google, Slack), hardcoded passwords, JWTs, private key blocks, and connection strings with credentials. Anything you find, rotate the credential first, then remove it. That's the order that matters.
- 02
Kill injection paths
Find SQL built with f-strings, .format(), concatenation, or template literals and parameterise it. Remove eval/exec, shell commands built from variables, subprocess shell=True, pickle on untrusted data, and yaml.load without SafeLoader.
- 03
Fix the auth defaults
Turn off Flask/Django debug mode, replace default signing secrets, reject the JWT 'none' algorithm, re-enable signature verification, drop wildcard CORS anywhere credentials are on, lock down ALLOWED_HOSTS, and set secure cookie flags.
- 04
Check what's in the repo
Make sure .env files, private keys, service-account JSON, database files and dumps, and .npmrc tokens are not committed, and that .gitignore covers them so they can't come back.
- 05
Pin your dependencies
Commit a lockfile, replace wildcard and "latest" versions with pinned ones, remove dependencies pulled from raw git or http URLs, and avoid curl|sh installs.
- 06
Verify transport
Re-enable any disabled TLS verification, switch plain-http API calls to https, and add helmet if you're running Express.
- 07
Or run it all at once
Paste the repo's public GitHub link into quality·vibes: all six categories scanned in memory, scored out of 100 with a letter grade, every finding ranked with a fix and a Claude prompt. Typically under a minute.
frequently asked
Do I need to do all of this before launch?
Step one, secrets, is non-negotiable: a committed key is exploitable the moment the repo goes public. The rest is strongly worth doing in the order listed. The weights quality·vibes uses (secrets 30, injection 20, auth 15, data exposure 15, dependencies 10, transport 10) are a fair guide to impact.
Can't my AI coding tool just check this for me?
You can ask it to, and you should. But a freeform "check my code for security issues" prompt is inconsistent: ask twice, get two different lists. A dedicated scan checks the same patterns every time and gives you a score you can compare across runs. quality·vibes then hands the fixes back to your AI tool as paste-ready prompts.
I found a committed API key while doing step one. What now?
Rotate it immediately, before you remove the file. The key lives in git history even after deletion, so revoking it at the provider is the only move that ends the exposure. Then clean the history and add prevention.
Is passing this checklist the same as being secure?
No. It covers the predictable, pattern-detectable issues AI-built apps most often ship. It doesn't replace a penetration test or runtime analysis, and quality·vibes says so plainly: heuristic static scan, neither of those two things.
Last updated June 10, 2026