WHAT WE REPORT
As part of our work, we occasionally discover security vulnerabilities in third party products/software. This policy outlines the actions and procedures followed by TASZK Security Labs to disclose vulnerabilities responsibly. In some cases the discovery is covered by a contractual IP transfer agreement.
In such cases, our policy for disclosure is guided by the contract - typically the disclosure responsibility is transferred together with the IP. This covers cases where we discover vulnerabilities in a third-party supplier authored or open-source component of a client’s product as part of an audit for the client.
In other cases, vulnerability discoveries are made as part of our own research. In such cases, our main concern is to report these vulnerabilities to the affected parties and assist in the creation of a fix. We are also committed to sharing such discoveries with the research community and the public at large in order to raise awareness, and to assist developers, vendors, and security professionals in learning about and providing effective defenses against known threats.
WHO WE REPORT TO
When we attempt to disclose a vulnerability, we will first make every reasonable attempt to contact the affected vendor(s) responsible for the development of the software(s) and/or service(s) and/or product(s).
Ownership of a software/hardware component within a product is not always straightforward to identify. As a generic rule, we will attempt to disclose vulnerabilities to the vendor of the specific product that they are identified in. In cases where alternative component ownership is clarified either by a published licensing notice or by the publicly available security reporting policies of the vendor, we will attempt the disclosure towards the third-party vendor / open-source project.
Whenever a formal security reporting program policy can be identified on the affected party’s official website or on the website of a Bug Bounty Program provider affiliated with the affected party, we will attempt to follow the rules established by the policy to the most reasonable extent possible, notwithstanding the limits set forth further in this policy.
In the absence of other formal mechanisms defined by a publicly available security reporting policy, we will attempt a contact by any reasonable means possible, which may include sending an email to ‘security@’, ‘info@’, ‘support@’, ‘secure@’ under the affected parties’ official domain.
In order to facilitate the tracking of vulnerability disclosures, we will request the assignment of a CVE ID for all vulnerabilities that are confirmed by the affected party. In all cases, we will consult the official Mitre website for determining the CNA appropriate for the vulnerability. In cases where the affected party is not the CNA, we will contact the appropriate CNA directly.
DISCLOSURE RULES WE FOLLOW
After we exhaust all reasonable means of contact, in case the affected party fails to acknowledge our efforts, TASZK Security Labs may publicly disclose the vulnerability within 2 weeks (14 days) following the initial contact.
If the affected party’s response is received within the timeframe outlined above, we will allow 3 months (90 days) from the initial contact attempt to address the vulnerability with a security patch or other corrective measures as deemed appropriate (“disclousure embargo”).. In extreme cases, following a request and a reasonable explanation from the affected party, we may allow an additional 60 days extension at our discretion. No further deadline extensions will be given under any circumstances.
A public disclosure will be released under the following circumstances:
- Following an official confirmation from the affected party stating the issue was fixed.
- After the above deadline expires, if the affected party does not respond or is unable to provide a reasonable explanation as to why the vulnerability was not fixed within the deadline.
- If the affected party communicates in response that it is unable to, or chooses not to, fix the particular security vulnerability.
In the event that we learn that a vulnerability that we have disclosed is being actively exploited in-the-wild, we may at our discretion shorten the disclosure embargo from 90 days. In any such case, we will inform the affected party about our decision at least 48 hours ahead of publication.
In the event that in response to a submitted report the affected party communicates that it considers the vulnerability out of scope and is not willing to provide a fix and CVE, we may at out discretion shorten the disclosure embargo from 90 days for all future vulnerabilities that fit into the same scope. In any such case, we will still inform the affected party about the vulnerability at least 48 hours ahead of public disclosure.
In the event that in response to submitted reports we find that the affected party repeatedly abuses its own advertised vulnerability submission program rules, we may at our discretion elect not to participate in coordinated disclosure and shorted the disclosure embargo from 90 days for all future vulnerabilities found in the affected party’s products. In any such case, we will still inform the affected party about the vulnerability at least 48 hours ahead of public disclosure.
HOW WE PUBLISH
TASZK Security Labs will formally and publicly release security disclosures on our official TASZK Security Labs Research web site. Only advisories listed on the web site should be considered official TASZK Security Labs disclosures.
A public disclosure by TASZK Security Labs may include a CVE identifier, technical details of the vulnerability and the impact, and a summary of the disclosure timeline and communications with the affected parties.
In addition to our official advisories, we may release information about vulnerabilities that we have identified through research articles on our website or via conference presentations. Research articles or presentations shall always be published after or together with the relevant advisory.