Leaked API keys

The short version

Smarter Weather is a registered partner in GitHub’s secret-scanning program. Whenever GitHub’s scanners find a string matching the live API-key shape sw_live_ (43 base64url characters) in a public repository, gist, or issue, they POST a signed payload to our partner webhook.

We verify the signature, force-revoke the key within seconds, and write an audit row attributed to system:github-secret-scanning. The owner of the leaked key sees the revocation in the same audit trail they’d see for any human administrator action. No human at Smarter Weather is in the loop; the action is fully automated and idempotent.

If your key was leaked, mint a replacement from the dashboard and update your application. The leaked key is already dead and cannot be revived.

What happens, step by step

1. GitHub detects the match. GitHub’s secret-scanning crawlers continuously scan public repositories, gists, and issue text. When they match the registered sw_live_ prefix, they package the matching strings into a ECDSA-P256-signed JSON payload.
2. Webhook delivery. GitHub POSTs the payload to a public Smarter Weather endpoint dedicated to this purpose (no human authentication is involved; the cryptographic signature is the entire trust boundary). Our endpoint accepts the payload, verifies the signature against GitHub’s rotating public-key set, and rejects anything that fails verification.
3. Revocation. For each verified token, we mark the key as revoked in DynamoDB. A revocation broadcast travels via DynamoDB Streams to every running API instance, which evicts the key from its in-memory cache. The full propagation is typically under thirty seconds; in the worst case it bounded by the cache TTL of sixty seconds. (Inflight requests using the leaked key complete normally; only new requests are rejected.)
4. Audit row. A row is written to the key’s owner audit log with command = "auto-revoke" and adminEmail = "system:github-secret-scanning". The row carries the same shape any human-administrator action would, so existing audit consumers handle it without changes.
5. No notification email is sent automatically. We deliberately do not email the leaked key’s owner on revocation because the email itself would be a phishing target (“your key has been revoked, click here”). The audit log is the source of truth; the dashboard surfaces the same information when you log in.

How to mint a replacement

Once a key has been revoked, it cannot be restored. Mint a replacement and roll your application:

1. Open the API keys page in the developer dashboard.
2. Click Create new key, give it a name that distinguishes it from the leaked predecessor (e.g. the date or the rotation reason), and copy the plaintext exactly once — we never display it again.
3. Update your application’s configuration to use the new key. Restart the affected services. (Smarter Weather’s tooling reads keys from environment variables or your secret store; never check them into source control.)
4. Confirm the new key is working by issuing a test request from your application. The dashboard’s usage view will show the new key’s traffic within a minute.

If you have an enterprise contract, your account contact can mint or rotate keys for you via swadmin key rotate on your behalf; reach out via your usual support channel.

Preventing leaks in the first place

GitHub’s secret-scanning service is a safety net, not a primary defence. Treat it the way you’d treat a smoke alarm: it’s great that it exists, but you shouldn’t plan around it firing.

• Never commit keys to source control. Use environment variables, your CI/CD provider’s secret store, or a dedicated secret manager (AWS Secrets Manager, Doppler, 1Password Secrets Automation, etc.).
• Use sw_test_ keys for development. Test keys never bill, are isolated from production traffic, and are designed to be shareable across a developer team without putting real-customer billing at risk. They have a separate prefix so GitHub’s scanner does not match them — if a test key leaks, no automatic revocation fires.
• Add a pre-commit hook for sw_live_. Tools like gitleaks can be configured to fail any commit that contains the live-key prefix. The catch-it-locally pattern beats the catch-it-after-it-leaks pattern every time.
• Rotate keys on a schedule. Even without a known leak, periodic rotation limits the blast radius of an incident you don’t know about yet. Pair rotation with a deploy and the operational cost is minimal.

Reporting a leak we missed

GitHub’s secret-scanning program covers public repositories, gists, and issues on github.com. It does not cover private repositories, paste sites, chat platforms, or anywhere else a key might end up. If you discover a Smarter Weather API key exposed in any venue:

• If it’s your own key: revoke it from the API keys page immediately and mint a replacement. You don’t need to contact us.
• If it’s someone else’s key: email security@smarterweather.com with the leak location and a clear description. We will revoke the key on the owner’s behalf and notify them through the audit log. Please don’t share the key itself in the email body; a link to the leak location is enough.

We do not run a public bug-bounty programme today, but we credit responsible disclosures in our changelog when the reporter wishes to be named.

Technical references

The protocol details below are documented for partners who want to understand the underlying contract; they are not required reading for normal use.

• GitHub’s upstream documentation: Secret scanning partner program. Smarter Weather is a registered partner; the live-key regex is sw_live_[A-Za-z0-9_-]{43}.
• The signature scheme is ECDSA-P256 over the raw request body, verified against the rotating public-key set published at api.github.com/meta/public_keys/secret_scanning. Every rejection emits a structured CloudWatch metric with a category dimension; we track the volume on our public-API dashboard.
• Revocation propagation is fast-path-invalidated via DynamoDB Streams; expected latency is under thirty seconds, bounded by a sixty-second TTL on the in-memory key cache. The cache layout is documented in the public API’s architectural decision record on key invalidation.
• The full webhook auth model — including non-goals, alternatives considered, and the kill-switch semantics — is recorded in the public-partner webhook architecture decision record shipped with the API source.

Questions about this page? Email security@smarterweather.com.