People leak secrets. This is now a proven statement, backed by data provided and analyzed by GitGuardian, for example in the State of Secret Sprawl report. Leaked secrets are obviously a threat to the security of every entity, from individual developers to Fortune 500 companies, and something that must be acted upon.

At GitGuardian, we try our best to help tackle the leaked secrets problem in three main ways:

• GitGuardian products: If you are a GitGuardian customer or a free-tier user, you are covered by our enterprise-grade detection and remediation capabilities.
• The Good Samaritan program: While monitoring the public cloud space, when we find a sensitive secret, we automatically send an alert e-mail to its identified owner. This is provided free of charge since GitGuardian early days.
• Responsible disclosure: When we find company secrets during our security research.

In the past 6 months, GitGuardian responsibly disclosed critical secret leaks to more than 30 companies and faced various kinds of responses. If 50 to 60% of the disclosures ended with proper remediation, others were not and received pushback:

• No answer or acknowledgment: We sometimes receive no response at all.
• The alerted team does not care: We receive an acknowledgment but observe no status update or remediation or we receive a polite response stating this is not a security boundary.
• The issue was already known: Which is generally a surprise as we only disclose valid and critical leaks.

Those are only a fraction of the problems we face during our responsible disclosure process. Overall, our experience shows that companies are not always prepared to receive responsible disclosure inbound for security incidents. However, responsible disclosure is a well-known and documented process and some good practices can help foster this cybersecurity collaboration.

Have a team identified to handle disclosure inbound

The first step in being able to handle responsible disclosure messages is to have a team assigned to handle those messages. Having no specific team assigned to inbound security incidents is likely to create friction. We all know receiving security alerts is not the most enjoyable event in a day. Having a clear procedure to handle them makes the process less painful.

In general, the security alerts should be handled by the internal security team. Depending on its size, you might want to assign a sub-team with the right scope such as the Security Operation Center, the Monitoring Team, or similar. In some cases, you might want to have multiple teams with distinct scopes. A typical example is for companies to have a Product Security Incident Response Team (PSIRT) and a Computer Security Incident Response Team (CSIRT).

The only requirement when you have multiple teams assigned is to have clear guidelines about the teams’ scope for security researchers to contact the right team for their incident.

Give public information about security contacts

A crucial point to be able to receive external security alerts is to publicly provide the contact to your security teams. Not finding the right security contacts caused a lot of headaches for GitGuardian’s cybersecurity research team over the last months.

There is a risk that, if no contact can be found, researchers will not report their findings which would be a severe issue.

There are various ways you can publicly provide your security contact information. The most well-known and standard method is to place a security.txt file on your main website’s domain. This method is defined in rfc9116 and the file should follow a strict structure.

Contact: mailto:security@gitguardian.com
Expires: 2025-12-31T22:59:00.000Z
Preferred-Languages: en,fr
Canonical: https://www.gitguardian.com/.well-known/security.txt
Policy: https://vdp.gitguardian.com/

There is nothing mandatory in following the standard rfc9116 method. You can also:

• Host a vulnerability disclosure program website
• Have a page on your corporate website with security contact information
• Delegate everything to a bug bounty platform

Anything works as long as the information is easily discoverable.

It can also be a good idea to prepare and share encryption keys in case sensitive information has to be sent by the researchers. GPG is often used for this purpose and is a de facto standard.

Fine-tune your bug bounty scopes and policies

If you rely on a bug bounty platform to handle the inbound security alerts, make sure your scopes and policies are clear for researchers and also for you. Especially, ask yourself what happens when findings have to be reported on an out-of-scope asset.

GitGuardian’s security researchers, who mainly report secret leak issues, faced a lot of out-of-scope kind of answers when reporting through bug bounty platforms. The question that arises in that case are:

• Will the bug bounty platform still forward the incident information to the company?
• Is there another reporting channel available for out-of-scope findings?

If answering no to both questions, there is a risk that out-of-scope findings never reach your security teams and stay without remediation. 

Be prepared to receive negative feedback

Receiving external security is not an enjoyable experience. It can lead to crises, investigations, and other unwanted situations. In such cases, it can be easy to badly react after a report. Our security researchers already faced such situations in the past with:

• Security contacts getting suspicious.
• Receiving improper response.
• Legal threats.

It is important to remember that responsible disclosure is meant to be responsible. Most researchers are not looking for personal profit or to cause any harm. Also, findings and reports are generally not personal. There are a lot of reasons why people discover security threats and targeting a specific individual is generally not one of them. Don’t take it personally and overreact. All this is for the greater good.

A good way to prepare for disclosure is to do exercises and simulations. This will not only challenge your security teams on the handling of inbound reports but also validate that your emergency response procedures are up to date and working. Such exercises are mandatory for a lot of security certifications like SOC2.

Follow a transparency-first approach in communications

To finish, adopting clear and transparent communication is another way of ensuring the process is smooth and enjoyable for everyone involved. Considering that independent researchers take time and effort to report findings, it is generally appropriate to as open as possible in the exchanges.

Nothing is surprising about the actions to take to achieve a great experience for both parties:

• Acknowledge the reports: If you received and read a security report, send an acknowledgment to the researchers.
• Send updates on time: If you act upon the report, let the researchers know, they might propose to help you with the investigations or remediation. If you think you’ll need time to handle the situation, let them know too.
• Avoid legal threat: Security researchers are not threat actors. While it has become less of an issue over time, some companies still sue independent researchers. This is a bad security practice.

The key point is that the more pleasant the process, the higher the chances that researchers will reach out in the future in case of an incident. This increases the chances that vulnerabilities are reported to you before being exploited by threat actors.

A Shared Path Forward

Leaked secrets pose real, growing threats, but organizations don't have to face them alone. Responsible disclosure processes, paired with clear internal procedures and transparency toward security researchers, build trust and strengthen overall cybersecurity posture. By embracing collaboration and openness, companies not only mitigate immediate risks but also foster relationships that can prove invaluable in the long run. After all, cybersecurity is a shared responsibility—and proactive collaboration benefits us all.