3 ms·

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

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/

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/