A Practical Security Checklist for Small Development Teams
Small teams do not fail security because they skipped a framework logo. They fail it because a key sat in a log, a route had no auth check, or a public page still said "debug" in production.
This checklist is for people who ship one product, not a bank. Invince is a tool that reports findings with evidence. It is not a pentest and it is not a certification.
Look here first
Work top down. A stolen session cookie beats a missing security.txt on the priority list.
- Secrets in git. API keys, tokens, and
.envfiles that were committed once. Rotate anything that ever landed in history, even if you deleted the file later. - Secrets in logs and errors. Stack traces and client breadcrumbs love to echo
Authorizationheaders. Strip them at ingest. Invince redacts keys it recognizes and can open a finding so you rotate. - Auth gaps. Pages that should require a session and do not. APIs that trust a user id in the body. "Hidden" admin URLs.
- Public surface. Directory listings, default frameworks pages, missing HTTPS, mixed content. A public Check is built for this layer.
- Dependencies with known issues. SCA scanners will never be complete. They still catch the package you forgot you installed.
- Write access you did not mean to grant. GitHub Apps, deploy tokens, and "allow this bot to open PRs" flags. Invince's GitHub App cannot push unless you grant contents write and turn on pull requests in project settings. Leave that off until you want it.
How to prioritise
Ignore score theatre. Ask three questions:
- Can a stranger use this without an account? If yes, it is ahead of an internal-only footgun.
- Is the secret still live? A revoked key is cleanup. A live key is an incident. Invince can check some providers during a scan. Do not wait on that if you already know it is live: revoke first.
- Do we actually own this code? Do not "fix" a dependency by vendoring a guess. Upgrade, replace, or isolate.
Then pick one finding and close it. A board of 40 open items with no owner is worse than three items with a date.
Plan the fix
Write the change like a pull request you would accept at 11pm:
- What is broken (evidence: file, route, header).
- What "fixed" means (unauthenticated request returns 401; key no longer authenticates).
- How you will re-check (repeat the Check, re-run the scan, hit the route).
Invince findings include a copy-paste prompt for your editor. Use it as a start. Review the diff. The product is allowed to recommend. You still own the merge.
What this checklist is not
It is not SOC 2. It is not a guarantee that nothing else is wrong. Specialist scanners such as Snyk still cover more of the dependency universe. Use them if that is your risk. Use Invince when you want findings next to docs, errors, and the commit that introduced the hole.
Run it on an app you own
Read security findings and the security docs. Start with a public URL you are allowed to test, then connect GitHub when you want repo-backed evidence.