Investigate public incidents

Before you prioritize or remediate a public secret incident, you need to know what it represents and whether it is relevant to your organization, which is the hardest part of working with public sources. This page describes the context GitGuardian provides on each incident to help you answer that.

The agents' own conclusions, the Company-related verdict and the risk score, are covered separately in Agents analysis.

Secret detail

Every public incident provides detailed information about the secret itself:

Detector information

The detector identifies the type of secret found. This helps you understand what service or system might be compromised.

Secret validity

GitGuardian performs validity checks when possible to determine if the detected secret is still active and usable. Valid secrets pose immediate security risks and, when related to your company, should be prioritized for quick remediation.

Secret analyzer results

For some detectors, when the secret is valid, our secret analyzer provides additional context about the secret's permissions and scope. This analysis helps you understand the potential impact if the secret were to be exploited.

Occurrences detail

The table of occurrences provides you with the detailed information you need:

• Author identity: The Git author name and email associated with the commit
• Commit timestamp: When the secret occurrence was committed
• Repository: The GitHub repository where the secret was found
• Commit hash: The specific commit containing the secret
• File path: The exact file and location within the repository
• Patch preview: A code snippet showing the secret in context (may be hidden for large patches)
• GitHub link: Direct link to view the occurrence on GitHub (when still publicly visible)
• Presence indicator: Shows whether the occurrence is still visible on public GitHub. The value "removed from GitHub" typically indicates that the repository has been deleted or made private after the leak, or that the commit itself has been deleted.

caution

The fact that the occurrence has been erased from GitHub does not mean that the incident is resolved! Indeed a malicious actor could have cloned the repository and seen the secret before it was erased from GitHub.

Attachment reasons

Attachment reasons explain why GitGuardian associated a public secret incident with your organization. Understanding these reasons helps validate the relevance of each incident:

• By developer from perimeter: One of your monitored developer is involved in the secret incident.
• On organization from perimeter: The secret incident happened on a repository of one of your monitored GitHub organizations.
• From secret grasper: The secret incident was attached to your company thanks to a secret grasper in the commit.

info

Attachment reasons provide insight into the probability that a leak is related to your organization. Incidents attached "By developer from perimeter" may contain company secrets, but could equally be unrelated personal credentials from your developers. In contrast, incidents leaked "On organization from perimeter" are company-related since they originate from your organization's repositories.

Tags and contextual information

GitGuardian automatically applies tags to each incident to surface useful details about the leak and where it was found. They are clues rather than conclusions, and they can be used in filters and saved views.

• Company domain in commit: One of your monitored domains appears in the file content of the occurrence.
• Company name in commit: Your company name appears in the patch where the secret is leaked.
• Secret grasper in commit: One of your defined secret graspers (which can be seen as company-specific identifiers) appears in the occurrence patch.
• Internally leaked: This tag (only available if you also have Internal Monitoring) indicates that the same secret has been found in an internal incident within your monitored sources. The exploration map will show you the related internal incident. In Internal Monitoring, this relationship is shown as the Public incident linked exposure type on internally leaked secrets. See Public exposure information for more details.
• Sensitive file: One of the occurrences of the incident happened on a potential sensitive file
• Production: The commit associated with one of the occurrences seems related to a production environment.
• Test file: One of the occurrences of the incident happened on a potential test file. A file is automatically classified as a test file if its path contains any of the following patterns (with only numbers or special characters around them): test/tests, example/examples, mock/mocks, fixture/fixtures, fake, dummy, false, or testdata. For example, .test.env or 00testdata.json will match, but dummydata.json will not.
• False positive: GitGuardian's ML engine has identified this as likely not being an actual secret. These incidents can typically be safely ignored. (Learn more here)
• From historical scan: The incident was discovered during a historical scan rather than through real-time monitoring.

Previous behavior

On workspaces not yet switched to the agents analysis, a Context related to company tag also appears: GitGuardian's ML engine flags leaks whose surrounding context looks related to your company, based on company-specific terms or enterprise-grade indicators. The agents analysis supersedes it.

Exploration map

info

This feature provides the most value when you also use Internal Monitoring, NHI Governance, or have integrated with your secret managers using GitGuardian Scout for comprehensive context.

The exploration map provides a visual representation of where GitGuardian has detected this specific secret across your integrated sources and what access it potentially grants.

The map can reveal:

• Internal incidents (if you use Internal Monitoring): Whether the secret also appears in your internal codebase, JIRA tickets, Slack messages, or other internal sources
• Secret manager storage (if you've integrated secret managers): Whether the secret is stored in your vaults or secret managers
• Infrastructure usage (if you use NHI Governance with infrastructure integrations): Whether the secret is used in infrastructure sources like GitLab CI or Kubernetes clusters

A strong company-related signal

For public secret incidents, an exploration map showing multiple nodes is strong evidence that the secret truly belongs to your company and requires immediate remediation.

ML-powered similar incident grouping

GitGuardian automatically groups incidents that share similar characteristics, so you can spot recurring patterns and handle related incidents together. On a public incident you get a Similar incidents section in the sidebar, a sortable Similar incidents column in the incidents table, and a similar_to search operator.

See similar incident grouping for how the grouping works.