CVE Assignment Policy

Overview

We participate in the Common Vulnerabilities and Exposures (CVE) Program as a CVE Numbering Authority. Our aim is to publish clear, timely records for security issues in our client applications.

Scope

  • Covered: Our client software
    Arc on macOS and Windows
    ArcSearch on Android and iOS
    Dia on macOS
  • Not covered: Our backend services and infrastructure when the issue does not create a vulnerability in client software.
  • Supported versions only: We issue CVEs only for the most recent supported versions of our client apps. We do not assess or publish CVEs for older or retired versions.
  • Overlap with retired versions: If the same vulnerability affects both a supported version and an older, retired version, we publish one CVE for the vulnerability and reference the supported version. We do not create a separate CVE for the retired version. If a vulnerability applies only to a retired version, we will mark the record to indicate it was unsupported when assigned.
  • Third-party components and specifications: For issues rooted in another supplier’s component (for example, Chromium) or a shared specification, we contact the upstream supplier first and defer assignment to them when appropriate. If the insecure behavior is specific to our implementation in our client apps, we may assign for our implementation and reference any upstream CVEs.

How we decide a vulnerability exists

We assign CVEs for issues that harm confidentiality, integrity, or availability in our client software. Generally, we do not assign for:

  • Physical or local attacks that do not bypass a stated security protection
  • Brute-force denial of service or resource exhaustion
  • General malware unrelated to our product
  • Non-default or unusual configurations
  • Routine dependency updates where the fix is in the dependency itself
  • See our scoping on our Bug Bounty Policy page

Severity and when we assign

  • We typically only consider assigning CVEs for high-severity and critical issues in our client software.
  • Discretionary: We may assign for medium or low severity when the issue presents significant user harm or requires action by others (for example, active exploitation or broad industry impact).

Fix-first publication

  • Default: We publish advisories and CVE records after a fix or mitigation is available for supported versions.
  • Exception: In coordinated or high-harm cases, we may publish guidance and a CVE record before a fix, consistent with CVE rules.

Publishing timelines

After a CVE we assigned is publicly disclosed, we publish the CVE record promptly:

  • Target: within 24 hours
  • Required: within 72 hours

Coordination and “first refusal”

  • We contact the organization with the most appropriate scope first (often the upstream supplier) and coordinate to avoid duplicate IDs.
  • When we are not the supplier of the affected component, we make a good-faith effort to notify the supplier.

Right to decline

We may decline to assign when an issue is outside this scope, not a vulnerability by the criteria above, or out of scope according to our Vulnerability Rewards Guidelines. If we reserved an ID and later determine it does not apply, we will reject the ID rather than publish.

Response targets

  • Critical fixes: targeted within 7 days
  • High fixes: targeted within 30 days

Contact and advisory pages

Live scope and exclusions

For the current list of assets in scope and exclusions for researcher submissions, see our HackerOne program.