Understand incident properties
Overview
Understanding the properties of public secret incidents is essential for effective prioritization, investigation, and remediation.
For public secret incidents, one of the main challenges is identifying which secret leaks are actually related to your organization versus credentials that are not related to your company and thus pose no direct threat.
This guide explains the metadata and properties available for each public incident, helping you assess the impact on your organization and prioritize remediation efforts accordingly.
For every public incident, GitGuardian provides comprehensive metadata to help you understand the scope and impact:
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.
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.
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 various tags to help you quickly assess and categorize incidents:
Indicators of company-related incidents
Several tags and indicators can help you identify incidents that are likely related to your organization:
- 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.
- Context related to company: GitGuardian's ML engine has determined that the context surrounding the secret leak appears related to your company, based on company-specific terms or enterprise-grade indicators.
- 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.
Other tags
Some other tags are provided by GitGuardian to help you assess the likely criticality of incidents:
- 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.
Exploration map
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
For public secret incidents, an exploration map showing multiple nodes is the strongest possible indicator that this secret truly belongs to your company and requires immediate remediation.
