Vulnerability Disclosure Policy

Header_strip

Vulnerability Disclosure Policy

This vulnerability disclosure policy serves as a guideline of how Scorpion Labs, a division of K logix, LLC, and its affiliates handle vulnerability notification and disclosure, and further to instruct Maintainers as to the expectations when a researcher discovers a security vulnerability. This document is not in any way legally binding to any party, rather serving strictly as a guideline. This policy may be updated at any time solely at the discretion of Scorpion Labs.

Table of Contents

  • Scope and Contact
  • Purpose of the Policy
  • Definitions
  • Discussion
  • Disclosure Process
  • Questions and Answers

Purpose of the Policy

This policy exists to establish a guideline for interaction between a researcher and software Maintainer. It serves to quash assumptions and clearly define intentions, so that both parties may immediately and effectively gauge the problem, produce a solution, and responsibly disclose the vulnerability.

First and foremost, a note to the software Maintainer: the researcher who contacted you has chosen NOT to immediately disclose the problem, but rather make an effort to work with you. This is a choice they did not have to make, and a choice that hopefully you will respect and accept accordingly.

The goal of following this policy, above all else, is to minimize the impact of security vulnerabilities on consumers. The policy seeks to balance numerous factors which place computing infrastructures at risk and to find the most effective way to notify consumers without unnecessary negative impact.

Definitions

Maintainer: the individual, group, or vendor that maintains the software, hardware, or product affected by the Issue.

Patch Release Date: The estimated date when the Maintainer will publish a fix for the identified vulnerability.

Advisory Prerelease Date: The date when Scorpion Labs will release limited information about the flaw to warn the public.

Advisory Full Release Date: The date when Scorpion Labs will release full details about the vulnerability to the public.

Discussion

The ultimate goal of Scorpion Labs' responsible disclosure process is to minimize the exposure of consumer systems to attack. A determination must be made as to how much technical information should be released, and when it should be released. Releasing detailed exploit information before users have the ability to correct or mitigate a flaw will clearly have a negative impact. However, allowing software Maintainers to drag out a release process indefinitely will also negatively impact consumers since, with passing day, a chance exists that an unethical researcher will independently discover and use the flaw to attack consumers.

While it is likely impossible to accurately quantify the true risk of any vulnerability, there are clearly several factors at play in how vulnerabilities and their public release could impact consumers. When determining how and when to publish information about any given vulnerability, Scorpion Labs considers at least the following criteria:

  • Severity - The more serious a vulnerability, the more caution is warranted in public release of technical details
  • Mitigation options - If technical controls can be easily put in place to mitigate the flaw, then publishing information about the issue may benefit the public more than it would aid potential attackers.
  • Size of user base - If the set of affected consumers is large, then attackers are more likely to find it worth their while to develop exploits for a vulnerability and therefore more caution is necessary.
  • Likelihood of discovery - Recent history has shown that it is not uncommon for vulnerabilities to be identified independently by multiple researchers. If a flaw is perceived to be "easy" to find or evidence exists that it may have already been identified by unethical researchers, then making the issue public sooner will likely benefit consumers more.
  • Difficulty of Fix - Excessively pressuring Maintainers to make technically tricky fixes in a short amount of time may in fact harm consumers more than help them due to the introduction of additional bugs and vulnerabilities. On the other hand, pressure should be applied (through the incentive of possible early disclosure) to Maintainers who drag their feet on making relatively simple fixes, since this will encourage sufficient quality assurance processes in the long run.

Keeping these factors in mind, Scorpion Labs has developed a disclosure process which hopefully strikes a reasonable balance for responsible disclosure.

Disclosure Process

The Scorpion Labs disclosure process is broken down into five stages: notification, triage, support, prerelease, and full release. These stages typically occur in that order, but several may be omitted depending on the results of previous stages. Each stage is described below.

Notification

After identifying and assessing a vulnerability, a Scorpion Labs researcher will attempt to contact the Maintainer. The researcher will start by searching for information published by the Maintainer (such as on its website) on how to report vulnerability information. If this fails, the researcher will attempt to contact the Maintainer through generic email addresses or contact forms. If this information is not available or a timely response to these inquiries is not received, the researcher may use third-party resources, such as CERT/CC vendor coordination, security.txt records, or public domain registration contacts to attempt to reach the Maintainer. The researcher may also attempt to contact the Maintainer at commonly used email addresses such as security@{maintainer}, secure@{maintainer}, info@{maintainer}, support@{maintainer}.

Maintainers are expected to manually respond within 7 calendar days. All reasonable attempts to contact the Maintainer will be made by Scorpion Labs researchers, but after published methods of contact are exhausted, Scorpion Labs will consider the Maintainer to be non-responsive.

Triage

Once the Maintainer has responded to the initial notification, Scorpion Labs will arrange to provide the full technical details of the flaw. Scorpion Labs encourages the use of secure forms of transfer of detailed vulnerability information during this stage.

Upon receiving the vulnerability information, Maintainers are expected to review the technical details and respond to Scorpion Labs within 14 calendar days. Maintainers should provide a brief summary of how they expect the flaw to impact users and if there are any mitigations for the flaw that customers could implement which Scorpion Labs did not previously identify. Maintainers must also provide an expected Patch Release Date for the distribution of a fix to customers. This date should be no more than 120 days in the future.

Scorpion Labs will then assign Advisory Prerelease and Advisory Full Release dates. If the Maintainer supplies a Patch Release Date that is within a reasonable period of time, then the Advisory Prerelease will typically be skipped and the Advisory Full Release Date will occur on or shortly after the Patch Release Date. However, in situations where the risk to consumers is deemed significant, an Advisory Prerelease Date may be assigned on or before the Patch Release Date with the Full Release being delayed until the overall risk subsides.

If the Maintainer provides a patch release date greater than 120 days in the future, refuses to provide a date, is unresponsive or becomes non-responsive, Scorpion Labs will assign a reasonable Advisory Prerelease and Full Release Dates. Assigned release dates are selected based on the criteria described in the Discussion section above and will generally fall between 90 and 120 days into the future, from the end of the Triage stage. The assigned release date will be communicated to the Maintainer.

Note that advisory release dates may be altered at any time by Scorpion Labs. Changes most often occur when indications of active exploitation in the wild come to Scorpion Labs' attention, but may also occur for other reasons. In any case, changes to release dates will be communicated to the Maintainer.

Support

The support stage begins once a Patch Release Date is established. During this stage, Scorpion Labs awaits the patch and provides the Maintainer support in correcting the flaw. Support may include additional technical details such as exploit scenarios or recommended approaches to correct the flaw. Support for Maintainers may even include testing of preliminary fixes for the flaw. However, note that this support is a free service provided to the Maintainer and the level of support provided is completely up to Scorpion Labs to decide.

During this stage, Scorpion Labs may also provide support to Scorpion Labs customers who are potentially impacted by the flaw. For instance, Scorpion Labs may provide limited prerelease information to customers in order to help them secure their environments. In all cases, the utmost care is taken in providing prerelease information in order to minimize the possibility of dissemination to unethical parties.

Prerelease

Scorpion Labs may publish a prerelease advisory to the public on or before the established Patch Release Date. Prereleases are commonly published on the Patch Release Date when the severity of the vulnerability is perceived to be high or if a vendor failed to release a fix for the flaw by the previously established deadline. Scorpion Labs may also opt to publish a Prerelease Advisory prior to the Patch Release Date if evidence exists that a third-party researcher may have also discovered the flaw, or the flaw is being actively exploited in the wild. Scorpion Labs may also opt to skip the Prerelease stage entirely if the release process goes smoothly and the severity of the flaw does not warrant giving consumers an early "heads up".

Prerelease advisories include very general information about the flaw, along with information to help consumers mitigate the issue. All attempts are made to help consumers protect themselves while making it difficult to develop an independent exploit for the vulnerability without significant additional effort.

Full Release

During the Full Release stage, Scorpion Labs publishes full technical details about the vulnerability. The Full Release may occur on the established Patch Release Date, or if a Prerelease was published, will typically occur within 30 days of the Prerelease. Ideally, the Full Release Advisory will occur after a fix is provided by the Maintainer, but this may not be possible if the Maintainer is uncooperative.

Maintainers are asked to credit at least the first researcher who brought a given issue to their attention. For instance, a simple attribution of credit might read:

"Thanks to {researcher name} of Scorpion Labs for bringing this issue to our attention."

Questions and Answers

Do you use the CVE to identify vulnerabilities?

Yes. If the Maintainer acts as a candidate naming authority (CNA), then Scorpion Labs will ask that the Maintainer assign an identifier after the triage phase. Otherwise, Scorpion Labs will request a number directly from MITRE or another CNA.

Isn't it unfair to set arbitrary deadlines for Maintainers?

No. The recent past has shown that the lack of deadlines for Maintainers only leads to longer and longer fix times. Scorpion Labs strives to avoid "arbitrary" deadlines by trying to understand Maintainers' and consumers' situations for each and every vulnerability. For more information on security community trends in this area, see the similar approaches employed by Google Project Zero and ZDI.

Where does Scorpion Labs publish advisories?

We publish all advisories on our website, X, and on popular security mailing lists.

History

Version 1.0 — May 5, 2026. Initial publication aligned with Scorpion Labs' responsible disclosure policy.