Secret scanning: public leak locations and alert de-duplication across an organization or enterprise - feedback

[erinhav]

What do you think about secret scanning's new public leak and multi-repo indicators?

Public leak locations and duplicate alerts

To help you triage and remediate secret leaks more effectively, GitHub secret scanning now indicates if a secret detected in your repository has also leaked publicly with a public leak label on the alert. The alert also indicates if the secret was exposed in other repositories across your organization or enterprise with a multi-repo label.

These labels provide additional understanding into the distribution of an exposed secret, while also making it easier to assess an alert’s risk and urgency. For example, a secret which has a known associated exposure in a public location has a higher likelihood of exploitation. Detection of public leaks is only currently supported for provider-based patterns.

The multi-repo label makes it easier to de-duplicate alerts and is supported for all secret types, including custom patterns. Both indicators apply only for newly created alerts.

Exact locations, REST API, webhook support

Coming next: you'll be able to view exact locations of known public leaks for a secret scanning alert, as well as any repository names with duplicate alerts across your organization or enterprise. Public leak and multi-repo labels will also be surfaced via the REST API and webhooks.

📖 Helpful information and some friendly reminders:

Learn more about the feature via product documentation. Let us know what you think by signing up for a 60 minute feedback session or commenting below -- we're listening!

[magmanu]

This is a very useful feature, thanks!
Could I suggest further enhancements, please?

• Public leaks are critical vulns and should scream in the security dashboard 😆 A simple red counter banner/tag on the Secret scanning tile shown at the dashboards security/risk and security/metrics/secret-scanning could suffice though. Currently, afaik, we only become aware of public leaks by actively looking for them using a GUI filter or some in-house automation.
• Push an email to security managers about public leaks as soon as they are identified, so remediation happens asap.
• currently, the default list of security alerts in security/alerts/secret-scanning is sorted by recency. I'd suggest that it prioritises secrets with the tag public leak by default and show them at the top of the list, regardless of when they were discovered. Otherwise, public leaks might get lost among other non-critical alerts that haven't been handled yet.

---

I also have another feat request, tangentially related to the current topic: secret criticality.

It would be handy to attach criticality levels to secret alerts. Of course committed secrets are always bad, but not all alerts are the same. There are public leaked secrets, experimental secrets, confirmed active secrets, secrets with unknown validity, critical services secrets (e.g., stripe_api_key), less important service secrets (e.g. wakatime_api_key)... They don't all carry the same weight, and it would be helpful if the alerts reflected that. If alerts can be easily and quickly prioritised by criticality, everyone's job could get a little easier.

If critically becomes a feat, I'd also request to allow us to set custom criticality levels, so we can fine-tune them by secret type, repository metadata, public leak status, validity or whatever's our heart desire. Some use cases from the top of my head: a Wakatime alert can be low by default; any secret in my crown jewel repos are critical by default, secrets with unknown validity will score lower than active secrets. Of course this could be set via GUI, but a REST endpoint would be great to automate these evaluations. Thank you!

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams.
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences.
• GitHub staff may reach out for further clarification or insight.
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[Johnismaiel]

https://doka-guide.vercel.app/js/deal-with-forms/

[zetFF]

The new public leak and multi-repo features in GitHub's secret scan are really helpful in keeping data safe. With the public leak label, we can immediately know if a secret has leaked to a public repository, so it can be dealt with quickly before someone misuses it. Meanwhile, the multi-repo label makes it easier to track whether the same secret is spread across multiple repositories in the organization. This is very important so that we can remove duplicates more effectively and reduce the risk of exploitation.

In addition, REST API and webhook support makes monitoring more automated and response faster. So, if there is a leak or duplicate alert, we can take immediate action without having to manually check one by one. With clearer information about the location of leaks, security teams can more easily manage risks and prevent bigger problems in the future. This feature is not just about detecting, but also making the data protection process more efficient.

[1unxx]

How does GitHub define a ‘public leak’ if the repo was private at the time of commit but later forked publicly?