how to

How to check a GitHub repo for security issues (by hand, and in one paste)

the short answer

To check a GitHub repo for security issues, search it for committed secrets, string-built SQL, dangerous auth defaults, exposed data files, unpinned dependencies, and disabled TLS — or skip the manual grep and paste the public repo link into securevibes, which runs all of those checks in memory and returns a 0–100 score with ranked, line-level findings in under a minute.

Maybe it's your own repo before launch. Maybe it's a project you're about to fork, a template you found, or a codebase you inherited. Either way, the question is the same: is there anything in here that's going to hurt me? GitHub will happily host a repo with a live Stripe key in it; nothing flags it for you.

There are two honest ways to answer the question: a manual pass, which is free and educational but slow and easy to do incompletely, and an automated scan. This guide covers the manual route properly — what to search for and where — and then where a scanner like securevibes fits.

file + lineevery securevibes finding points at the exact location, with redacted evidence
scan your repo →about securevibes

The manual pass: what to actually look at

Start with secrets, because they're the most damaging: search the repo for provider key prefixes (AWS, Stripe, OpenAI, Anthropic, GitHub, Google, Slack), the words password and secret near assignments, BEGIN PRIVATE KEY blocks, and connection-string schemes like postgres:// with credentials embedded. Check committed files too: .env, anything ending in .pem or .key, service-account JSON, database dumps, .npmrc.

Then read for code patterns: SQL queries assembled with f-strings, .format(), concatenation, or template literals; eval and exec; shell commands built from variables; subprocess with shell=True; pickle; yaml.load without SafeLoader; innerHTML and dangerouslySetInnerHTML. Finish with configuration: debug mode, CORS set to *, default JWT secrets, missing lockfiles, dependencies pinned to "latest", and TLS verification flags set to false.

Why manual checks come up short

The problem isn't that manual checking is impossible — it's that it's a long list of patterns across two-plus language ecosystems, and missing one is as bad as missing all of them. A grep for "sk_live" won't catch a hardcoded password; reading the .gitignore won't catch the f-string SQL. Doing it properly takes an hour and a checklist; doing it casually gives you false confidence.

Manual review also can't tell you how bad the overall picture is. Twelve findings in one repo and three in another doesn't tell you which is riskier until you weigh severity and category — which is judgment most builders don't have calibrated, through no fault of their own.

Where a scanner fits

securevibes runs the whole pattern list at once: paste the public GitHub repo link and it fetches the same archive anyone can download — no OAuth, nothing cloned to disk — and scans it in memory. You get a 0–100 score with a letter grade, six category subscores, and a ranked findings list where each item has the file, the line, redacted evidence, why it matters, and how to fix it.

Two limits worth stating plainly: it works on public repos only in v1 (private repo support is coming), and it's a heuristic static scan — it doesn't execute the code or check dependencies against a vulnerability database, so it complements rather than replaces deeper tooling. For the is-this-repo-safe-to-ship question, it answers in under a minute what the manual route answers in an afternoon.

how it works

  1. 01

    Search for secrets

    Grep for provider key patterns, password/secret assignments, private key blocks, JWTs, and connection strings with embedded credentials.

  2. 02

    Check committed files

    Look for .env files, .pem/.key files, cloud service-account JSON, database files and dumps, and .npmrc tokens — and whether .gitignore would have stopped them.

  3. 03

    Read the risky code patterns

    String-built SQL, eval/exec, shell commands from variables, subprocess shell=True, pickle, unsafe yaml.load, innerHTML/dangerouslySetInnerHTML.

  4. 04

    Review config and dependencies

    Debug flags, wildcard CORS, default signing secrets, missing lockfiles, "latest" versions, raw git/http dependencies, disabled TLS verification.

  5. 05

    Or paste the link into securevibes

    All of the above, scanned in memory in under a minute, scored 0–100, with ranked line-level findings and a paste-ready Claude fix prompt per issue.

frequently asked

Can I check someone else's repo, or only my own?
Any public repo. securevibes fetches the same public archive anyone can download, so checking a template before you fork it or a project before you depend on it works exactly like checking your own.
Does securevibes need access to my GitHub account?
No. There's no OAuth and no GitHub permissions — you paste a public repo link, and it scans the public archive in memory without cloning anything to disk. Reports are private to your account.
Will secrets it finds be shown in the report?
Findings include redacted evidence — enough to identify the secret and its location, never the full credential. Secrets are always redacted in reports.
What about private repos?
v1 is public repos only; private repo support is coming. If your repo is private, the manual steps on this page still apply in full.

Last updated June 10, 2026

more on securevibes

ready to try securevibes?

scan your repo →