Research disclosure policy

What we do

We analyze firmware and binaries for a living, and that work finds vulnerabilities in products we did not write. Reporting them is a duty rather than a courtesy: a bug we find and sit on is a bug still shipping on somebody's device.

When our analysis confirms a finding in third-party or open-source software, we report it to whoever maintains that component, under our own name, whether or not the component is one we ship. The clock starts the day the analysis confirms it, not the day we decide what to do about it.

What we will not publish

A customer's artifact is theirs. We never publish a vulnerability found in a customer's own product, or through their use of our platform, and we never name the customer or their code without permission. Where a customer's artifact is how we found a bug in a third-party component, we tell the customer first and disclose upstream without identifying them.

That protection covers what we find in work you commission. A report already in your hands keeps the deadline it was sent with: the clock runs from the day our analysis confirmed the finding, and it runs the same whether you become a customer or stay one.

Deadlines

Disclosure is a two-way street, so our deadlines are fixed in advance rather than argued case by case. We notify the maintainer immediately and publish after ninety days, or sooner if a fix ships first. That moves in four situations, and only these:

• A patch with a date: up to fourteen extra days. If, before the deadline, a maintainer tells us a fix is scheduled within fourteen days of it, we wait for the patch.
• Under active exploitation: seven days. Every day an exploited vulnerability stays unpatched and unannounced costs more devices. Seven days is aggressive and may be too short to ship a fix, but it is enough to publish a mitigation. After that we support making details available so users can defend themselves.
• End of life or end of support: thirty days, unless we get confirmation that an out-of-band patch is coming. Nobody is served by a ninety-day wait for a fix that was never going to be written.
• Weekends and US public holidays move a deadline to the next working day.

We reserve the right to move a deadline either way in extreme circumstances, and we apply these rules to every vendor equally. We expect to be held to the same standard, and our own products are: see how to report a vulnerability to us.

Where a critical vulnerability affects a large user base, we may bring in a national CERT to coordinate publication.

Working with maintainers

We put real effort into reaching the right person: a published security contact first, then the vendor's own support channel, then security@, psirt@, and info@. If you maintain a product, publishing a security contact and a key is the single thing that most improves what happens next.

No vulnerability is kept quiet because a vendor would rather it were. The advisory includes a summary of our correspondence, so a silence is visible as a silence.

We ask maintainers for the affected versions, the fixed version, and where a user gets the update, and we recommend they request a CVE. Before we publish, the maintainer gets a courtesy copy of the advisory and at least two business days to comment. We consider that feedback; we do not guarantee to incorporate it, and it does not postpone publication.

We credit the researcher who found the issue, and ask that vendors do the same in their release notes.

Contact

Anything about a report we sent you, or a finding you think we should have: security@2atomic.com.