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.
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.
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-scanni...
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) based on the embedded URL for the disclosure endpoint.