Website: xyz
Contact: research@certainity.com

The Offensive Security team of CERTAINITY regularly discovers security vulnerabilities in third-party software during assessments for our customers. We aim to achieve a responsible disclosure where the third-party vendor has the opportunity and time to investigate and mitigate the identified flaw, but customers of the software product are also informed in a timely manner. This responsible disclosure policy defines the timeframe and frame conditions until the public release of a security advisory by CERTAINITY.

Benefits and Goals

The benefits of a responsible disclosure are [1]:

  1. Increased security: Helps to increase the security of software, hardware, and systems by allowing vendors to address vulnerabilities before malicious actors exploit them.
  2. Improved collaboration: Promotes collaboration between security researchers and vendors/organizations, leading to stronger and more secure products and systems.
  3. Trust and reputation: Builds trust and improves the reputation of both vendors and security researchers.
  4. Legal protection: Provides legal protection for security researchers by reporting vulnerabilities responsibly.
  5. Public safety: Reduces the risk of cyberattacks and other security incidents that could harm individuals or organizations.

Responsible Disclosure Process

1. Advisory Preparation

CERTAINITY will create a security advisory containing detailed information about the uncovered issues, including version information and a proof of concept. If the vulnerability was detected during a customer assessment, the advisory is fully anonymized.

2. Vendor Notification

CERTAINITY will notify the vendor of the affected software to establish direct and secure communication. The advisory is transmitted to the vendor, and the date of first vendor notification marks the start of the public disclosure deadline.

Contact may be established via:

  • Bug Bounty Program: If available, the advisory is submitted via the vendor’s bug-bounty program.
  • Public Security Contact: If available, encrypted communication is established (using PGP/SMIME certificates). If not immediately available, CERTAINITY will initiate communication to obtain required encryption details.
  • No Public Security Contact: If no public contact is available, other available contact details are used. If the customer has a B2B relationship and agrees, internal contacts may be used.

Note: CERTAINITY may use unencrypted channels only if explicitly allowed by the vendor’s security contact.

If the vendor does not respond after multiple contact attempts, CERTAINITY will proceed with a “full disclosure” after the deadline, skipping the vulnerability resolution phase.

3. Vulnerability Resolution

After receiving the advisory, the vendor validates the issue and works on a fix or workaround. Key points:

  • Vendor should assess impact and complexity, and provide feedback on remediation timelines.
  • A coordinated release may be scheduled; public disclosure deadline may be extended up to 3 months for compelling reasons.
  • Vendor must provide a patch/workaround or give reasons if not possible.
  • Public advisory will be released regardless of vendor’s agreement after the deadline.
  • CERTAINITY encourages vendors to share detailed patch and version info for the public advisory.
  • Vendor is expected to credit CERTAINITY and the researcher.
  • Additional support by CERTAINITY during resolution may require a consulting contract; otherwise, the advisory is provided “as-is.”

4. Public Disclosure

The advisory is publicly disclosed according to these scenarios:

  • Coordinated release: All advisory info plus mitigation approaches/patch instructions.
  • No vendor response: Public advisory released after 60 days with all prepared information, but without vendor-supplied mitigation details.
  • Extended period: If agreed, release occurs no later than 5 months after initial contact.

CERTAINITY may withhold detailed proof-of-concept information or contact CERT teams if wider user groups are affected, depending on criticality and impact.

Advisory Content

A CERTAINITY advisory typically includes:

  1. Title
  2. Vendor
  3. Software Name / Identification
  4. Affected / Fixed Versions
  5. Criticality Rating (CVSS)
  6. CVE Number (if available)
  7. Discovery date
  8. Vulnerability Researcher(s)
  9. CERTAINITY Vulnerability Research Contact
  10. Vendor description of the product
  11. Vendor / Software homepage
  12. Overview of the Vulnerability
  13. Proof-of-Concept (PoC)
  14. Solution / Patch information / Workaround
  15. Disclosure Timeline