4 ms·

GitHub PM here. We switched our own token format to something similar to the above in April of last year and have been encouraging other service providers to do

GitHub PM here. We switched our own token format to something similar to the above in April of last year and have been encouraging other service providers to do the same. The big benefit of highly identifiable tokens is not just that we can alert on them, but that we can scan for them at pre-receive time and prevent them from leaking (by rejecting the push). We already have that functionality as part of GitHub Advanced Security, and are planning to make it available (for free) on public repos in 2023. [1] https://github.blog/2021-04-05-behind-githubs-new-authentication-token-formats/ https://github.blog/2021-04-05-behind-githubs-new-authentica...

ericpauley 4y ago
One of the big issues with secret scanning now is that it’s opt-in from platforms, and from the list of supported platforms it seems like small ones may not be able to be included. The holy grail here would be to introduce a standardized token format that encodes a disclosure endpoint. Then platforms can issue tokens to this standard and receive notifications without needing to explicitly opt in.
- yencabulator 4y ago
  > standardized token format that encodes a disclosure endpoint This should be relatively easy... secret:example.com:entropy-goes-here secret:subdomain.example.com:entropy-goes-here secret:example.com/path/optional:entropy-goes-here and then a Well-Known URI (https://en.wikipedia.org/wiki/Well-known_URI https://en.wikipedia.org/wiki/Well-known_URI) based on the embedded URL for the disclosure endpoint.
- greysteil 4y ago
  For the secret scanning partner program we're happy to work with partners of any size - there are details of the program, including how to get in touch, at the link below.[1] However, with secret scanning alerts we look for credentials from service providers we _don't_ have a partnership with, too. Our partnerships team are pretty good, so the delta isn't that big, but Asana, Notion, Intercom and Artifactory are a few of the service providers whose tokens we scan for where we don't (yet!) have a relationship to send detections. We also scan for tokens where a partnership isn't possible or would be much harder (like HashiCorp Vault service tokens). On standardized formats, if one existed we would scan for it! However, as we've worked with dozens of service providers to update their formats we've found many have specific constraints and everyone has different preferences - as a result, for now, we're pursuing a broad church approach, rather than pushing a standard. If you haven't already read Thomas Ptacek's survey (for fly.io) I recommend it.[2] [1] https://docs.github.com/en/developers/overview/secret-scanning-partner-program https://docs.github.com/en/developers/overview/secret-scanni... [2] https://fly.io/blog/api-tokens-a-tedious-survey/ https://fly.io/blog/api-tokens-a-tedious-survey/
dottedmag 4y ago
Is there a way (or a plan to have a way) to register custom prefixes to have them scanned on a specific repository?

ericpauley 4y ago

One of the big issues with secret scanning now is that it’s opt-in from platforms, and from the list of supported platforms it seems like small ones may not be able to be included. The holy grail here would be to introduce a standardized token format that encodes a disclosure endpoint. Then platforms can issue tokens to this standard and receive notifications without needing to explicitly opt in.

yencabulator 4y ago
> standardized token format that encodes a disclosure endpoint This should be relatively easy... secret:example.com:entropy-goes-here secret:subdomain.example.com:entropy-goes-here secret:example.com/path/optional:entropy-goes-here and then a Well-Known URI (https://en.wikipedia.org/wiki/Well-known_URI https://en.wikipedia.org/wiki/Well-known_URI) based on the embedded URL for the disclosure endpoint.
greysteil 4y ago
For the secret scanning partner program we're happy to work with partners of any size - there are details of the program, including how to get in touch, at the link below.[1] However, with secret scanning alerts we look for credentials from service providers we _don't_ have a partnership with, too. Our partnerships team are pretty good, so the delta isn't that big, but Asana, Notion, Intercom and Artifactory are a few of the service providers whose tokens we scan for where we don't (yet!) have a relationship to send detections. We also scan for tokens where a partnership isn't possible or would be much harder (like HashiCorp Vault service tokens). On standardized formats, if one existed we would scan for it! However, as we've worked with dozens of service providers to update their formats we've found many have specific constraints and everyone has different preferences - as a result, for now, we're pursuing a broad church approach, rather than pushing a standard. If you haven't already read Thomas Ptacek's survey (for fly.io) I recommend it.[2] [1] https://docs.github.com/en/developers/overview/secret-scanning-partner-program https://docs.github.com/en/developers/overview/secret-scanni... [2] https://fly.io/blog/api-tokens-a-tedious-survey/ https://fly.io/blog/api-tokens-a-tedious-survey/

dottedmag 4y ago

Is there a way (or a plan to have a way) to register custom prefixes to have them scanned on a specific repository?