Skip to content

Add Google API keys in AG001 - #14

Open
bashirokk wants to merge 2 commits into
amic25:mainfrom
bashirokk:main
Open

Add Google API keys in AG001#14
bashirokk wants to merge 2 commits into
amic25:mainfrom
bashirokk:main

Conversation

@bashirokk

Copy link
Copy Markdown

What changed

Added detection for hard coded Google API key to the existing rules. Previous covered OpenAI, AWS, GitHub but not Google.

Threat model or motivation

Trust Boundary: Source code should never contain secrets such as Google API keys. Google API keys follow a fixed format that is easy to regex and should have a low false positive rate. Test have been added to detect false postives.

Validation

  • Tests cover vulnerable and safe cases
  • make check passes
  • Documentation/changelog updated when behavior changed
  • Fixtures contain no real credentials or private data

Related issue

Closes #8

@amic25

amic25 commented Jul 29, 2026

Copy link
Copy Markdown
Owner

Thanks for this — Google API keys are a real gap in AG001's pattern set.

One thing needed before it can merge: a true-negative corpus case.

A new secret pattern is untested surface until something proves it doesn't over-match. Every pattern in AG001 has cost us false positives at some point — the assigned credential pattern matched Python type annotations (token: "contextvars.Token[Any]") as credentials in a real project, twice. AIza... is a fixed 39-char shape so it should be well-behaved, but "should be" is what we're trying to stop relying on.

Please add to tests/corpus/:

  • a true positive: a Google API key committed in production-shaped code, with a manifest entry saying expect: [AG001] and why;
  • a true negative: something close enough to trip a careless pattern but which must not fire. Documentation placeholders and AIza-prefixed identifiers that aren't keys are the obvious candidates.

Use a fabricated key — the corpus is public and GitHub secret-scans this repo.

Two other things worth knowing, both from work merged after you opened this:

  • AG001 now runs unbounded over line length, so your pattern will be applied to minified bundles in full. Please run python -m tools.measure_linearity and confirm it reports linear; a non-linear pattern with no length bound is a denial-of-service vector.
  • There's now a credential_class distinction (public vs secret). Google has both — an API key restricted to a referrer is often shipped in client code deliberately. Worth considering whether some Google key shapes belong in the public class, capped at Low. Your call; happy either way, but say which you intend.

make bench will show the precision/recall effect once the corpus cases are in.

@bashirokk

Copy link
Copy Markdown
Author

Alright will do, ill have an update by tomorrow hopefully. Thanks for the support

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Detect Google API keys in AG001

2 participants