Remediate incidents

Overview

Effective remediation of public secret incidents requires an approach that balances urgency with thorough investigation. The key is distinguishing between incidents that require immediate security action versus those that can be safely ignored as irrelevant to your organization.

Understanding incident outcomes

Public incident remediation can result in two outcomes:

Resolve incidents

Mark incidents as Resolved when they represent actual security risks that you've addressed through proper remediation steps (rotating secrets, removing exposure, etc.).

Ignore incidents

Mark incidents as Ignored when they're not relevant to your organization—such as unrelated personal credentials or false positives. Ignoring helps clean your incident backlog so you can focus on genuine threats without feeling overwhelmed by irrelevant alerts.

Before you remediate: investigate the incident

Take time to thoroughly investigate your incident and assess its potential impact. It can be difficult to estimate possible damage just by examining the surrounding code. Remember that:

• Sensitive data often appears in developers' personal projects
• A single credential with elevated privileges can compromise an entire organization
• Various applications can share the same secret
• Some secrets can lead to discovering additional secrets (e.g., Slack tokens accessing shared files, GitHub tokens accessing private repositories)

Use the incident properties to assess whether the incident truly impacts your organization.

Involve the developer

Including the developer responsible for the incident in the remediation process is often essential as they possess knowledge about:

• What the secret provides access to
• Services and applications that depend on it
• Other team members who might be affected
• The context surrounding the exposure

GitGuardian offers two ways to collaborate with developers:

Share public link of the incident

Generate a public link that can be sent to the involved developer for feedback on the incident. This approach works regardless of whether the developer is currently part of your organization or workspace.

Use with caution: These links are publicly accessible without requiring authentication.

Grant access within the platform

If the involved developer is both a current employee of your organization and a member of your GitGuardian workspace, you can grant them direct access to the incident. They'll be able to view the incident details in the Public Monitoring section and provide feedback directly through the dashboard.

This is the safer approach since it doesn't require generating publicly accessible links, but it's only available when the developer is already a workspace member.

info

Developer workspace membership is common when organizations use Internal Monitoring, as developers are typically added to collaborate on internal security incidents.

Resolving confirmed impactful incidents

When an incident is confirmed as relevant and poses a security risk, here are some guidelines to take action:

1. Ensure that the compromised secret is revoked

Once a secret appears publicly on GitHub, you must consider it compromised and ensure that it is immediately revoked. Depending on the case, this might require the involved developer's assistance.

If the secret is under your direct control and used in your systems and applications, here are more detailed steps you can follow:

• Vault your secret if it's not yet safely stored in a Secret Manager
• Fix your application's code to properly reference the secret, if it has also been leaked in your internal codebase.
• Generate new credentials to replace the exposed ones
• Update all systems and applications using the old credentials
• Revoke or deactivate the compromised credentials

2. Optionally: remove evidence

Besides revoking the secret, you may want to eliminate all traces of the secret and surrounding code. This might take the involved developer's assistance to:

• Delete the repository entirely or make it private
• Rewrite git history if technically feasible

caution

Removing evidence is optional if the secret was successfully revoked, since it can no longer be used. However, it becomes a necessary mitigation action if the secret could not be revoked for any reason.

3. Review access logs

Investigate potential unauthorized access:

• Check logs for suspicious activity using the compromised credentials
• Look for evidence of data access, system intrusion, or lateral movement
• Consider that some secrets provide access to other secrets or systems
• Take additional mitigation actions if you discover further exposure

Close the incident as "Resolved"

After the remediation steps are complete, mark the incident as "Resolved" button, and document your reason by selecting the appropriate option(s):

• Repository made private or deleted
• DMCA takedown requested
• Secret revoked

Ignoring public secret incidents

If your investigation determines that a particular secret leak has no link with your company, or does not present any risk, you can close the incident as "Ignored".

Document the reason by selecting the appropriate option(s):

• Test credential
• Low risk secret
• False positive (not a secret)
• Developer not connected to the company
• Credential not related to the company