Secret Scanning Issue: Same Secret in Multiple Files/Commits Is Grouped as a Single Finding

[gozuata]

Select Topic Area

Question

Body

Hello GitHub Support,

We’ve encountered a challenge with the way Secret Scanning currently reports findings. Specifically:

When the same secret appears in multiple files or commits, GitHub consolidates all instances into a single finding. This behavior significantly impacts our ability to triage and manage secret exposure effectively.

For example, the same secret string may be detected across 5 different files:

2 of them are confirmed exposures and need remediation,

1 is a false positive,

and the others require different resolution paths.

Since GitHub treats them as a single finding, we are forced to apply one resolution across all occurrences, which makes it difficult to accurately track and manage them. It also complicates coordination between teams responsible for different parts of the codebase.

This issue is negatively impacting our current secret remediation process, as it prevents us from resolving each occurrence independently. Additionally, we’ve received feedback from developers expressing confusion and difficulty in properly tracking and resolving findings due to this grouping behavior.

We would prefer a more granular reporting approach where:

Each occurrence of a secret (even if the same value) is treated as a separate finding if it appears in different files or commits.

Could you let us know if this behavior is expected, and whether there are any workarounds or upcoming changes planned to improve this experience?

Thank you for your support.

Best regards,

[Lakshya2099]

Yes, GitHub currently groups all identical secret values into a single finding, regardless of how many files, commits, or branches the secret appears in. This is by design — the goal is to reduce noise and avoid duplicate alerts for the same credential.

However, this grouping introduces serious challenges in practical remediation workflows, especially in larger repositories or multi-team environments.

⚠️ Why This is Problematic
In real-world use cases, context is critical. Here's why grouping identical secrets causes friction:

Different files = different owners
One file might belong to the frontend team, another to backend — and a single grouped finding doesn’t allow assigning or resolving per team.

Mixed validity
Some occurrences may be true positives needing immediate remediation, while others may be false positives — but you’re forced to resolve all of them the same way.

Blocked triage process
Teams can’t independently manage their own exposure, which slows down incident response and increases confusion.

✅ Suggested Improvements
This could be significantly improved with the following enhancements:

Occurrence-Level Findings
Treat each occurrence (same secret in a different file or commit) as a separate finding, or at least allow individual resolution within the grouped finding.

Expose Full Context
In both the UI and API, show:

File path(s)

Commit hash(es)

Author and timestamp
for each occurrence of the secret.

Configurable Grouping Behavior
Offer a repo/org-level setting to toggle between:

Grouped (current behavior)

Per-occurrence (granular, preferred for triage-heavy workflows)

Partial Resolution Support
Allow marking individual occurrences as false positives or resolved without forcing a global resolution across all appearances.

🛠 Temporary Workarounds
Until GitHub introduces native support for granular secret findings, here are some interim solutions:

Use the Secret Scanning API to fetch findings and build an internal dashboard to track secrets by file and commit.

Correlate findings manually with git log or codeowners data to assign responsibility more accurately.

Use issue tracking systems (e.g., Jira) to break out secret handling tasks by context manually.

📌 Final Thoughts
While grouping secret findings makes sense from a “reduce alert fatigue” standpoint, it unintentionally adds friction in security operations and development workflows. Giving users the option to handle secrets on a per-occurrence basis would significantly improve clarity, accountability, and remediation speed.

Would love to hear if this enhancement is on GitHub’s roadmap — and I highly recommend this be considered for future iterations of Secret Scanning.

Thanks again for raising this important point.