Policy · Version 1.0 · Effective on publication

Coordinated disclosure policy

In short: we report vulnerabilities privately, publish only after a fix is available or the disclosure window (90 days by default) has closed, and treat good-faith research on our own systems as authorized. To report something to us, see clause 7.

Contents
  1. 01Purpose and scope
  2. 02How we disclose to vendors
  3. 03Timelines
  4. 04Working with programs and platforms
  5. 05Smart contracts and live protocols
  6. 06Publication
  7. 07Reporting a vulnerability to us
  8. 08Safe harbor
  9. 09What we will not do
  10. 10Contact

01Purpose and scope

This policy explains how Copperfault discloses vulnerabilities we discover in third-party software, products and smart contracts, and how to report a vulnerability in Copperfault’s own systems.

02How we disclose to vendors

We report vulnerabilities privately to the affected vendor, through the vendor’s security contact, their bug bounty program, or an established coordinating program such as the Zero Day Initiative (Trend Micro), Cantina, Immunefi or HackenProof.

Each report includes the affected versions or deployments, impact, root cause and steps to reproduce: enough for the vendor to confirm and fix the issue.

We do not disclose details publicly before a fix is available unless the timeline below has run out.

03Timelines

Unless a program’s own deadline applies (see clause 4), our default is public disclosure 90 days after the vendor is first notified, or sooner once a fix has shipped and users have had a reasonable time to update (typically up to 30 days). If a fix is scheduled to ship shortly after the deadline, we may allow a grace period of up to 14 days.

We will extend the window for vendors who are actively working on a fix and keep us informed.

If a vulnerability is being actively exploited, we may shorten the window to 7 days, and we will tell the vendor before doing so.

  1. Day 0Vendor notifiedPrivate report with everything needed to confirm and fix.
  2. Day 7If actively exploitedEarliest publication, and only after telling the vendor.
  3. Fix shipsUsers updateTypically up to 30 days, then we publish.
  4. Day 90Default publicationExtended for vendors working on a fix who keep us informed.
  5. +14 daysGrace periodIf a fix is scheduled to ship shortly after the deadline.

04Working with programs and platforms

When a finding is submitted through a disclosure program or platform, that program’s rules on timelines, communication and publication take precedence over this policy.

05Smart contracts and live protocols

We test on local forks, testnets or other isolated environments. We do not exploit live deployments, and we never move, freeze or hold user funds.

If we find a critical issue in a live protocol, we contact the team immediately through its bug bounty program or its published security channel.

06Publication

Advisories are published after a fix is available or the disclosure window has closed. Where possible, we coordinate timing and credit with the vendor.

Advisories are written for defenders: enough detail to understand and verify the issue, and no more.

Our commitment: the fix should ship before the details do.

07Reporting a vulnerability to us

Email us with a description of the issue, the affected asset, steps to reproduce and the impact you observed.

Machine-readable contact details: /.well-known/security.txt

We will acknowledge your report within 3 business days, keep you informed through remediation, and credit you publicly if you would like.

08Safe harbor

If you research Copperfault's own systems in good faith, make a reasonable effort to avoid privacy violations, data destruction and service disruption, and report what you find to us privately, we consider that research authorized. We will not pursue or support legal action against you for it.

This covers copperfault.com and its subdomains. It does not authorize testing of our hosting or email providers, whose own policies apply.

09What we will not do

  • Publicly disclose a vulnerability before the vendor has had a reasonable chance to fix it.
  • Sell or broker vulnerabilities to buyers who would keep them unpatched.
  • Access, copy or keep data beyond what is needed to show an issue exists.
  • Test systems we are not authorized to test.
  • Use denial-of-service, social engineering or physical attacks, or anything that harms users or their data.

10Contact

Security reports: security@copperfault.com. Everything else: hello@copperfault.com.