Secrets detection on every pull request that bugweg reviews sounds obvious until you look at how review pipelines gate their checks. bugweg sorts each PR into a risk tier. A diff that touches only docs or images, with a confident LOW verdict, skips the AI review, and anything that changes code gets at least a MEDIUM-tier review. That is a sensible call for review depth. It would be the wrong call for credentials, so the secrets scan does not depend on the tier.
The diffs nobody reads closely
A pasted cloud key rarely arrives in a PR that looks dangerous. It arrives in the boring one: a README example, a docs snippet copied from a local file nobody scrubbed, a config line pasted into a markdown guide. Those are the diffs a human skims fastest. If the scan only ran when the PR looked risky, it would miss the PRs where it matters most.
So bugweg runs it as a separate pass on the raw diff before any model call, using regular expressions and a Shannon-entropy check. No AI review is needed for it to run, and a refused or truncated model reply cannot drop it.
What the scan looks for
| Rule | What it looks for | How it decides |
|---|---|---|
| AWS access key ID | The AKIA prefix followed by 16 uppercase letters or digits | Pattern match |
| GitHub token | A ghp_, gho_, ghu_, ghs_ or ghr_ prefix followed by 36 or more letters or digits | Pattern match |
| Slack token | xoxb-, xoxa-, xoxp-, xoxr- or xoxs- followed by 10 or more letters, digits or hyphens | Pattern match |
| Stripe secret key | An sk_live_ or sk_test_ prefix followed by 24 or more letters or digits | Pattern match |
| Private key block | A -----BEGIN ... PRIVATE KEY----- header (RSA, EC, OpenSSH, DSA, PGP or plain) | Pattern match |
| Generic assignment | A name ending in api_key, api-key, apikey, secret, token, password, passwd or pwd, followed by = or : and a quoted string of 16 or more letters, digits or the characters + / = _ . - | Pattern match, then an entropy check (at least 3.3 bits per character), with obvious placeholders (such as changeme or your_key_here) ignored |
The vendor-shaped rules are the more precise ones, because those token formats are distinctive. The generic rule is the noisy one, which is why it needs the entropy threshold and the placeholder filter before it reports anything.
What a finding contains, and what it doesn't
A finding names the credential type, the file and the line, for example "Possible AWS Access Key ID committed in this diff". It does not repeat the matched value, so the finding is not a second place the secret now lives. That applies to the scan's own finding: the AI review reads the same diff, so the diff text it sees still contains the value.
What happens when it fires
Every secrets finding is CRITICAL. That sets the PR's User Impact Score to CRITICAL and the bugweg check run to action required. Whether that actually blocks a merge depends on your branch protection: if the bugweg check is a required status check, the PR cannot merge until someone deals with it. A hit also raises the AI review for that PR to at least the HIGH tier, so a docs-only PR that adds a credential gets a deeper read, not a lighter one.
Config can't switch it off
A repo can tune bugweg with a .bugweg.yml file that excludes paths or changes the severity of specific bug types. Secrets findings are added after that config is applied, so an exclusion cannot hide a leaked key and a severity override cannot turn one into a low-priority note. The config is also read from the PR's base commit, so a pull request cannot edit the file that reviews it.
A checklist for when a key does leak
This is general guidance, not a complete incident-response plan. If the key protected customer or regulated data, follow your own security policy and any breach-notification duties.
- Rotate first. Revoke the credential and issue a new one before anything else. Deleting it from the PR does not undo the exposure.
- Assume the history may have been read. The commit is still in the branch history, so anyone with read access to the repository can find it.
- Remove it from the code. Load the value from a secret store or an environment variable instead.
- Check where else it lives. Search other branches, forks, build logs and config files for the same value.
- Make the check required. In branch protection, mark the bugweg check as required so a CRITICAL finding blocks the merge instead of waiting for someone to notice.
What this isn't
This is pattern and entropy matching for a known set of credential shapes, applied to the lines a PR adds. It does not scan your existing history or the rest of the codebase, it does not check whether a credential is still valid, and it will not recognise token formats it has no rule for. Treat it as one layer. A clean result means one fewer way a credential slipped through this particular PR, not proof that nothing sensitive is anywhere in your repo.
For the full list of checks, see the feature status page, where secrets detection is listed as live, and how a review runs for where the scan sits in the pipeline.
See it on your own repo. 3 free PR reviews. Card required; nothing is charged during the trial.
Install on GitHub