When Melina Security discovers vulnerabilities in third-party software, firmware, or systems during research or client engagements, we follow a coordinated disclosure process. This page documents that process so vendors, clients, and the security community know what to expect. This policy applies to vulnerabilities Melina discovers in third-party products. For vulnerabilities reported TO Melina (in our own systems or services), see [Reporting a vulnerability to Melina](#reporting-to-melina) at the bottom of this page. --- ## 1. Standard timeline Our default disclosure window is **90 days** from initial vendor notification to public disclosure. This aligns with the de-facto industry standard established by Google Project Zero and adopted by many research teams. The 90-day clock starts when: - We send the initial advisory to the vendor security contact via an authenticated channel - The vendor acknowledges receipt (within 5 business days) - If no acknowledgement after 5 business days, we treat the clock as started anyway and escalate via secondary channels The 90-day clock stops only by mutual agreement, never unilaterally. --- ## 2. Timeline extensions Vendors may request an extension under specific circumstances. We consider extensions case-by-case based on: - **Patch complexity:** complex fixes affecting multiple platforms or product lines may justify additional time - **Customer rollout windows:** enterprise customers may need lead time after patch release - **Vendor disclosure infrastructure:** vendors with mature PSIRT processes often need less time; new processes may need more Typical extensions are 14–30 days. Extensions beyond 60 days require an unambiguous justification and agreement that the vendor will not request further extensions. We do not extend disclosure timelines indefinitely. --- ## 3. Early disclosure (under 90 days) In specific scenarios we disclose earlier than the standard window: - **Active exploitation observed in the wild** — when we observe or have credible reports of active exploitation of an unpatched vulnerability, we disclose immediately along with mitigation guidance, regardless of patch availability - **Vendor unresponsiveness** — when a vendor does not acknowledge initial contact within 30 days despite escalation attempts through multiple channels, we may disclose with partial details to enable defensive action - **Vendor refusal to coordinate** — when a vendor explicitly declines to engage on the disclosure, we disclose at the original 90-day mark with all relevant technical details These early-disclosure scenarios are rare; the standard path is the 90-day coordinated disclosure. --- ## 4. Coordination with clients When Melina discovers a vulnerability during a client engagement and the vulnerability affects a third-party product: - We notify the client first with the technical details and our intended disclosure timeline - We coordinate with the client on disclosure timing, especially if the client wants to deploy fixes internally before public disclosure - If the client has an existing relationship with the affected vendor, we may route disclosure through the client's vendor management channel - The client's name is not disclosed without explicit consent — we anonymize the discovery context For engagements where the client is itself the affected vendor (assessment of the client's own product), disclosure timing is the client's decision; we provide the technical content and adhere to whatever timeline the client chooses. --- ## 5. CVE assignment For findings that warrant a CVE, we coordinate with the affected vendor's CNA (CVE Numbering Authority) or, when appropriate, request CVE assignment through MITRE directly. We do not pre-emptively request CVE assignment without vendor coordination unless the vendor is unresponsive per §3. --- ## 6. Public advisory format When disclosure occurs, we publish advisories under our Melina-NNN naming scheme (e.g., Melina-2026-001). Advisories include: - Vendor name, product, affected versions, fixed-in version - CVE ID (if assigned) - CVSS score (v4 base + temporal where applicable) - Vulnerability type (CWE classification) - Technical description sufficient to verify but not weaponize - Reproduction guidance proportional to defender need (we err on the side of less detail when the issue affects systems where defenders cannot easily deploy fixes) - Vendor response timeline - Credit to researchers (Melina staff + any external co-finders) - Acknowledgement of vendor cooperation when applicable - Mitigation guidance for systems that cannot be patched Advisories are published at `/research/advisories/melina-{YYYY}-{NNN}/` and indexed in the [Research silo](/research/). --- ## 7. What we do not do - We do not sell vulnerabilities or exploits to brokers, marketplaces, or undisclosed buyers - We do not retain working exploit code for vulnerabilities after disclosure beyond what is necessary for research reproduction - We do not disclose vulnerabilities to a third party while a coordinated disclosure is in progress with the vendor - We do not bypass vendor disclosure programs to embarrass vendors or seek publicity - We do not use disclosure timelines as commercial leverage in unrelated business discussions --- ## 8. Bug bounty programs When a vendor operates a public bug bounty program, we submit findings through that program. Bug bounty rewards, if any, are accepted by Melina the firm; researcher credit goes to the named Melina staff member who performed the research (per the byline convention on advisories). We do not require bounty payment as a precondition for responsible disclosure; the policy applies regardless of whether a bounty exists. --- ## 9. Reporting a vulnerability to Melina If you have discovered a vulnerability in Melina's own systems, website, or services, please report it via: Include in your report: - A description of the vulnerability - Reproduction steps - Affected systems / URLs / versions - Your name and contact preference (we credit researchers in our advisory; let us know if you prefer to remain anonymous) We respond to reports within 5 business days. We do not currently operate a paid bug bounty program but are happy to credit researchers in published advisories and may offer modest acknowledgement at our discretion. We do not pursue legal action against good-faith security research conducted under this policy. Good faith means: - Testing only against Melina's own systems - Not accessing or downloading data beyond what is necessary to demonstrate the issue - Not disrupting Melina services or other users - Providing reasonable time for remediation before public disclosure (we suggest 90 days, consistent with our outbound policy) --- ## 10. Contact For general questions about this policy: contact@melinasec.com.