In the fast-paced world of software development, efficiently managing security incidents is crucial for maintaining a robust security posture. GitGuardian is pivotal in identifying and alerting teams to exposed secrets within code repositories. Deciding whether to resolve or ignore these incidents can be challenging. Ignoring an incident is reasonable when a secret is low-risk or a false positive. However, without careful consideration, this action can introduce significant risks, potentially leaving the organization vulnerable to security breaches.

In 2024, a publicly listed technology company experienced a breach when a thief stole an employee's developer's Access Token. It gave them access to a codebase containing an active credential that had been incorrectly labeled as a test credential. Thankfully, the damage was minimal: a forensic investigation revealed that the intruder only accessed a small portion of the production environment and obtained personal information on a limited number of individuals and dummy data.

In this blog post, we'll explore the risks of ignoring an incident and discuss best practices to ensure such decisions do not compromise your organization's security.

The risks associated with ignoring an incident and premature closure

Ignoring a secret in GitGuardian typically occurs when the identified secret poses low/no significant security risk. Common reasons to ignore a secret include:

1. The secret was used for testing purposes: During development or testing phases, developers might use dummy or placeholder secrets to simulate real-world scenarios. These secrets are not meant to be used in production environments and are often considered harmless.
   The rationale for ignoring: Since these secrets are not tied to sensitive data or production systems, they might be deemed safe to ignore.
2. The secret is a false positive: GitGuardian may sometimes flag non-sensitive information as a secret due to pattern-matching algorithms. For instance, a string that looks like an API key or a password might actually be something entirely benign, like a configuration identifier or a comment in the code.
   The rationale for ignoring: False positives can be ignored to reduce noise and focus on real security threats
3. The secret has a low risk: Not all secrets are created equal; some may have a low impact if exposed. For example, a secret might only grant access to a non-critical service or a sandbox environment with minimal risk to the organization.
   The rationale for ignoring: If a secret's potential impact is determined to be negligible, it might be ignored to focus resources on more critical issues.

Even diligent teams can sometimes ignore or prematurely dismiss security alerts. Understanding and addressing the causes is crucial for improving incident management.

• Alert fatigue: GitGuardian may be just one of the numerous security tools security teams utilize. Some of these tools raise an overwhelming number of alerts, leading to desensitization and the potential to overlook real threats.
  For instance, in 2017, Equifax overlooked some security alerts, resulting in the breach of around 150 million private records. After litigation, the total cost of the settlement exceeded $500 million.
• Lack of training: Inadequate training or awareness among team members contributes to misclassifying incidents as low-risk or false positives.
  All teams don't learn the same way; that's why GitGuardian provides continuous education and training on how to reduce these errors through different media.
• Resource constraints: Limited resources—such as time, personnel, and budget—can lead to shortcuts in incident management and premature closure of incidents.
  When dealing with a pile of security debts, organizations can adopt strategies to manage these constraints without compromising security.
• Human bias: Cognitive biases, such as confirmation bias or optimism bias, might cause security teams to downplay certain alerts. For example, if a team member has encountered similar alerts that turned out to be false positives in the past, they might prematurely dismiss a legitimate threat.

We looked at GitGuardian users. Out of about one million incidents with valid secrets, approximately 2% were ignored. When taking into account every closed incident, this number increases to 6%. This means tens of thousands of closed incidents could be potential vulnerabilities!

Ignoring a security incident without thorough consideration can pose significant risks.

1. Overlooking emerging threats: Cybersecurity threats are constantly evolving, and what might seem like a low-risk or false positive today could be exploited by attackers in new and unforeseen ways. Teams might assume all problems are under control, with the risk of deploying compromised code into a production environment.
2. Inconsistent security practices: Regularly ignoring secrets without a standardized review process can lead to inconsistent security practices across the organization. Different team members might have varying thresholds for what constitutes a low-risk secret. This inconsistency can create gaps in security defenses, where some risks are ignored without proper justification.
3. Compliance and audit challenges: Security audit trails are essential for maintaining an accurate historical record of security incidents and their resolutions. Failing to demonstrate thorough review and justification for ignored incidents can result in failed audits, regulatory fines, the inability to trace the root cause of a security breach, or the need for costly remediation efforts.
4. Missed opportunities for security improvement: By ignoring incidents, organizations may miss the chance to refine their security processes, update playbooks, or adjust scanning tools to reduce false positives, ultimately weakening overall security resilience.

Organizations should establish clear guidelines and best practices for incident review to mitigate these risks and ensure that all security incidents are carefully evaluated before being ignored or closed.

Navigating incident closure in GitGuardian

Properly resolving incidents strengthens security, while incorrectly ignoring or closing them can compromise the organization's defenses. Therefore, it is crucial to comprehend the context and consequences of each action to maintain a robust security posture.

When remediating an incident in GitGuardian, there are two ways to close an open incident:

• Resolve: When an incident is resolved in GitGuardian, it means that the underlying security issue has been addressed, and the risk has been mitigated. This usually occurs when an exposed secret is rotated. The resolution typically involves verifying that the issue no longer poses a threat and documenting the steps taken to fix it.
• Ignore: Ignoring an incident is appropriate when the identified issue is a known false positive or does not pose a significant security risk.

Users may mistakenly close incidents. That's why we send notifications to their team managers (or the workspace manager if the user who closed the incident is not part of a team) when an incident is ignored while the secret is still valid.
These notifications are meant to encourage further review and prevent incidents from being overlooked, providing an extra level of protection against premature closures.

Furthermore, you can audit closed incidents using Saved views: one of the default incident views is dedicated to closed incidents with valid secrets.

What is true today may not be true tomorrow. Some services, such as AWS, may allow users to temporarily deactivate secrets.
When a secret has been exposed, GitGuardian will continue to monitor its validity, even if the incident is closed. An invalid secret may become valid later. If this occurs, GitGuardian will create new incidents to avoid unpleasant surprises.

Best practices for closing incidents in GitGuardian

At GitGuardian, we are convinced that detection without remediation is just noise. We want to help you close incidents more efficiently. More specifically, you should follow these guidelines before ignoring or closing any incident:

1. Verify the incident's nature: Confirm whether the incident is a real threat, a test, or a false positive.
2. Use playbooks: Consider employing a playbook to standardize the process of managing and closing incidents. GitGuardian offers a default remediation playbook and the option to create custom playbooks. A well-defined playbook ensures that all necessary steps are taken, reducing the risk of human error.
3. Team collaboration: Encourage collaboration with team members and security experts when unsure how to handle an incident. Leveraging the collective knowledge of the team can lead to better decision-making and prevent oversights.
4. Assess the risk: Evaluate the potential impact of the incident on the organization's security.
5. Implement remediation: If the incident is valid, take the necessary steps to remediate the issue.
6. Keep detailed records: Thoroughly document the reason for closing or ignoring an incident. This documentation is crucial for future reference, especially during audits or similar incidents. Additionally, other team members can comprehend the rationale behind the closure if they revisit the incident later.
7. Double-check: Before closing any incident, verify the issue has been fully resolved or correctly classified. It means confirming that exposed secrets have been rotated or ensuring that the incident's root cause has been addressed.

Conclusion

While some secrets may be safely ignored in GitGuardian, this decision should never be made lightly. The potential risks of ignoring genuine security threats far outweigh the convenience of reducing alert noise. 

By following best practices and using GitGuardian effectively, you can balance efficiency and security, ensuring your codebase remains well-protected against current and emerging threats.

*** This is a Security Bloggers Network syndicated blog from GitGuardian Blog - Code Security for the DevOps generation authored by Ferdinand Boas. Read the original post at: https://blog.gitguardian.com/risks-prematurely-closing-incidents/