0002 Secret Scanning
Changelog
- Unkey now offers automated alerts when root keys are checked in to Github.
- Unkey has partnered with Github to offer secret scanning for root keys.
- Root keys all take the shape
unkey_xxx
. Whenever you check in code to a public Github repository, Github will scan for this pattern and notify us. - Unkey will automatically invalidate the key, notify you that this has taken place, and ask you to generate a new key to replace it.
- Currently, this is only offered for root keys – not for API keys that you generate in Unkey for your users. Stay tuned as we look to expand our partnership with Github in future.
Context
Github offer a secret scanning program. Whenever code is checked in to a public repository, Github will scan the code for secrets that match a list of patterns published by official Github partners. If they detect that a secret matches that pattern, they notify the partner. The provider validates the string and decides if they should revoke the secret, issue a new secret, or contact the customer that published the secret.
Example flow
Unkey has registered as a partner with Github, meaning that we can enable this protection for our customers’ root keys. Currently we can’t offer the same protection to non-root keys:
- This is against Github’s term of service since Unkey does not own the infra that the API key belongs to (source: Slack thread). This will change once Unkey offer a gateway product, which is why Zuplo are already able to offer this.
- Currently there is no identifier that marks an Unkey API key as having been created by Unkey. This could change in the future: MRFC: Key shape
So only root keys are in scope for this RFC. However, we should avoid making assumptions that keys are root keys in our implementation to make future refactors easier.
Implementation
Steps
- Contact Github to register as a partner
- Identify the secrets we want to scan for, and create regular expressions to capture them
- Create a secret alert service which accepts webhooks containing the secret scanning payload
- Implement signature verification in the secret scanning service
- Implement secret revocation and user notification in the secret scanning service
Secret identification
As per above, only root keys are in scope for now.
Create secret alert service and implement signature verification
The secret alert service will receive payloads from Github with the following shape:
We should verify the signature of requests from Github:
Sample POST request from Github:
Implement key revocation and user notification in the service
Questions
- Should this run in a trigger.dev background job? Github say that it needs to be able to “handle requests with a large number of matches without timing out”