Vulnerability Disclosure Policy

Tanto Security frequently discovers vulnerabilities affecting generally-available software, including commercial software distributed by a vendor and source-available software distributed by a project. This can occur during the course of consulting work for a customer, or during our dedicated research efforts.

When we find vulnerabilities in the course of research, we apply the process detailed below.

When we find vulnerabilities in the course of our consulting work, we coordinate with our customer before reporting vulnerabilities externally. In cases where Tanto Security agrees to report vulnerabilities to an affected vendor or project on behalf of a customer, we may apply the process detailed below at the direction of our customer.

In Brief

We practice Coordinated Vulnerability Disclosure (CVD) in which we publish technical vulnerability information only after attempting to coordinate with an affected vendor or project, and only after allowing adequate time for a fix to be released and for users to have adopted it.

Upon reporting a vulnerability to a vendor or project, we withhold the publication of technical information for up to 120 days. This provides 90 days for a fix to be developed and made available to users, followed by a 30-day soak period for the fix to be widely adopted.

Under certain circumstances, such as when a vulnerability is being actively exploited or for which sufficient technical information is already public, the disclosure timeline may be shortened. This is discussed in the section titled “Early Disclosure”.

We believe that the CVD methodology provides maximum public benefit. It enables better risk management decisions by defenders and more comprehensive security assessments by offensive security professionals, while providing adequate time for vendors and projects to produce effective fixes for vulnerabilities.

When we report vulnerabilities to a vendor or project, we do what we reasonably can to support a comprehensive remediation. This can include answering questions, providing clarity, and discussing technical remediation strategies at a high level.

Payment

We will never demand payment for reporting vulnerability information under this process to a vendor or project, and we will never withhold vulnerability information under this process contingent on payment.

In cases where an existing bug bounty program applies to the affected software, we appreciate our submission being considered for recognition via the established bug bounty program.

We will never accept payment, including under a bug bounty program, in exchange for withholding publication under this process.

Vulnerability Reporting

When we discover a vulnerability, we take time to understand the nature of the vulnerability, and where possible, the root cause of the issue. We document our understanding of the vulnerability and we may document remediation suggestions. This is known as a “report”.

We deliver the report to the vendor or project responsible for the software. We make a best effort to deliver the report to a person or team who is responsible for handling this information, such as a published security contact.

If we do not receive acknowledgement that the report has been received and is being handled, we may attempt to follow up with the same person or team, and we may submit the report to alternative contacts for the vendor or project.

We endeavour to engage with a person or team who is able and willing to handle the report. In the absence of published security contact details or reciprocal engagement from a vendor or project, we may be limited in our ability to report vulnerabilities and support their remediation.

If we believe, in our sole determination, that we have exhausted all reasonable avenues for reporting a vulnerability, and that the vendor or project will not accept the report or remediate the vulnerability, we may choose to not withhold the technical vulnerability information from publication.

Timelines

In specific cases, the following timelines may be shortened. These cases are discussed in the section titled “Early Disclosure”.

If a vulnerability fix becomes available within 90 days of the submission of a report, we will withhold the publication of technical vulnerability information for 30 days from the date that a fix becomes available.

For example, if a fix is released 40 days after the submission of the report, we will withhold the publication of technical vulnerability information for 30 days from that date (total of 70 days).

If a fix is released 80 days after the submission of the report, we will withhold the publication of technical vulnerability information for 30 days from that date (total of 110 days).

We recognise that some vendors or projects operate on a defined patch cadence. If the project or vendor makes a commitment ahead of time that they will release a fix within the 14 days subsequent to the 90-day window (i.e. within 104 days of the submission of the report) then we will agree to withhold the publication of vulnerability information until a total of 120 days after the submission of the report.

If no fix for a vulnerability is available upon 90 days from the submission of a report, we will not continue to withhold publication of technical vulnerability information.

Early Disclosure

In specific cases, the public benefit of withholding details may be diminished or eliminated. In these cases, we may accelerate the publication of technical vulnerability information at our sole determination.

We will act in accordance with our values, judgement, and industry norms when performing early disclosure. We will notify the vendor or project of our intention and rationale.

If we become aware that a vulnerability is being actively exploited “in the wild” before a fix is available, we will notify the vendor or project that the 90-day timeline is accelerated to seven days from the time of notification. If a fix becomes available within seven days of the notice, we will withhold technical vulnerability information for 30 days from the fix being available, provided no other early disclosure condition is met. If a fix is not available upon seven days from notification of the accelerated disclosure timeline, we will not continue to withhold publication of technical vulnerability information.

If we become aware that sufficient technical information has been published that would materially accelerate the discovery or exploitation of a vulnerability, we may choose to cease withholding the publication of technical vulnerability information regardless of whether a fix is available. This is intended to equip defensive audiences with the information they need to assess risk and implement mitigations. In our sole judgement we may choose to withhold some information, such as information that could be directly used to reproduce the vulnerability, based on the information that has already been published.

Common Vulnerabilities and Exposures (CVE) IDs

CVE IDs are used to uniquely identify vulnerabilities. They are assigned by CVE Numbering Authorities (CNAs). They are a useful tool for cataloguing and disambiguating vulnerabilities, and are used by defenders to manage risk and drive vulnerability management programs.

We encourage vendors and projects to engage with the responsible CVE Numbering Authority (CNA) to reserve a CVE ID for each vulnerability in a report. In the absence of this, we may engage with the responsible CNA, or with the appropriate CNA of Last Resort, to reserve CVE IDs.

Last updated: 24 June 2026