Secrets Scanning… #12620
Replies: 3 comments 3 replies
-
FYI: The spiked above is a fake key that follows the format of the API our pipeline is using. |
Beta Was this translation helpful? Give feedback.
-
I'm no expert on Secret Scanning, so hopefully a Secret Scanning colleague will correct me if any of the below is wrong. I think by default Secret Scanning only searches for patterns that are very likely to be actual secrets. A string of hexidecimal characters is quite generic and could just as well be something benign like a commit SHA or a checksum. Secret Scanning can be configured with custom rules, and if your API keys tend to be 64 character hexadecimal strings, then it makes a lot of sense to define a rule to find those. When defining a custom pattern you can perform a "dry run" to spot check the results. If it has too many false positives, you can refine it. Once you're happy with the results you can commit the pattern and GitHub Secret scanning will start reporting alerts. |
Beta Was this translation helpful? Give feedback.
-
Also…. I will look into crafting custom search rules to enhance the secrets scanning. Is there a technique for submitting vetted scanning rules back to the community after we’ve vetted them? |
Beta Was this translation helpful? Give feedback.
-
Hello Community,
I think I am in the wrong discussion for this but am hoping someone here can point me to the right spot.
We are using CodeQL in our efforts as we adopt GitHub Advanced Security (GHAS).
My question is focused on Secrets Detection and an obvious secret in a config file in our Repo is not being caught.
apiKey=d4a1e3fd50d74eadb5d750859baf10537c9b66774f6e4c05a1d229f0a30be2ae
I would like to know why this is not being caught or if it may not be a secret that the GHAS secrets scanning is not supposed to be searching for.
Let me know…
Beta Was this translation helpful? Give feedback.
All reactions