Responsible disclosure policy

Send a written report to security@cmdash.com, or via the contact published at https://www.cmdash.com/.well-known/security.txt. We do not publish a PGP key — if a finding is sensitive enough that you would rather not send it over plain email, say so in your first message and we will agree an encrypted channel with you before you share detail. Please include:

• a clear description of the issue and its impact;
• the affected URL, endpoint, component, or product feature;
• reproduction steps, ideally with a minimal proof-of-concept;
• any logs, screenshots, or request captures that help us reproduce;
• your preferred name and credit language for any public acknowledgement — or a request to stay anonymous.

We aim to meet the following response windows during standard business hours (Monday–Friday, US Pacific / UTC-8):

• Acknowledge receipt within two business days — the same first-response commitment we make to Starter, the most conservative tier in our support SLA, since a security report may come from someone who isn’t a customer at any tier;
• Triage verdict (in scope / out of scope / needs more info) within five business days;
• Remediation target communicated within fifteen business days of triage — the actual fix timeline depends on severity and the scope of the change;
• Coordinated disclosure: by default, we ask reporters to withhold public details for up to 90 days from the initial report, or until a fix is released, whichever comes first. Exceptions negotiated in good faith.

If a report describes an actively exploited issue, email the same address with "URGENT" in the subject. We monitor the inbox continuously and will engage on-call if the evidence supports it.

The following targets are in scope for good-faith research:

• app.cmdash.net and any*.cmdash.net customer-tenant subdomain the researcher owns or is explicitly authorised to test.
• api.cmdash.net.
• api.cmdash.com, the control plane (licence issuance and refresh, billing and AWS Marketplace integration).
• www.cmdash.com (marketing site).
• CMDash’s official mobile applications and browser extensions, if and when published.
• Container images published to ghcr.io/bgovanlu/cmdash/*, for supply-chain findings.

Issues we are particularly interested in: authentication and session flaws, tenant-isolation failures (cross-tenant data access), server-side request forgery, broken access control, injection into logs / queries / templates, insecure default configurations, secrets in source.

The following are explicitly out of scope or will not be rewarded:

• Denial-of-service attacks and load-testing against CMDash infrastructure.
• Social-engineering attacks against CMDash staff, contractors, or customers. Phishing simulations without prior authorisation.
• Physical attacks against CMDash offices, colocation sites, or personnel.
• Findings requiring a rooted or jailbroken device, or an attacker who has already compromised the target user’s machine.
• Missing headers or cookies on endpoints that are not part of the authenticated attack surface (e.g., static marketing assets), where the finding has no demonstrable impact.
• Automated scanner output without a validated, reproducible impact.
• Reports of outdated software versions without a concrete exploit path relevant to CMDash.
• Self-XSS, clickjacking on endpoints without sensitive state change, missing CSRF protection on non-authenticated endpoints.
• Third-party services we integrate with — report those directly to the vendor (see our subprocessor list).

CMDash will not take legal action against, nor refer to law enforcement, any researcher who:

• acts in good faith under this policy;
• avoids privacy violations (does not intentionally access or retain data beyond what is needed to demonstrate the issue);
• avoids service disruption (no destructive testing, no brute-force against production, no exfiltration at scale);
• gives us reasonable time to remediate before public disclosure;
• does not extort CMDash or attempt to leverage the finding for commercial gain beyond an agreed acknowledgement or reward.

If a good-faith action is inadvertently found to violate an applicable law, CMDash will make clear that the activity was authorised under this policy and will not pursue claims under the Computer Fraud and Abuse Act, the UK Computer Misuse Act, or analogous statutes in other jurisdictions.

CMDash does not operate a formal, funded bug-bounty program at this time. We publicly and privately recognise researchers who report validated, impactful findings (see "Recognition" below), and we can offer a modest discretionary reward on a case-by-case basis — typically merchandise, public credit, or a discount on a future CMDash subscription. We expect to formalise a funded program once the product surface area and security engineering capacity support a consistent triage cadence.

We don’t run a public hall-of-fame page — we’d rather say that honestly than link to one that doesn’t exist. What we do today: with your consent, we credit you by name (or a handle you choose) in the release notes for the fix, and we’re glad to write a reference on request for researchers who’d like one. If you have reported a finding and would like to be credited or to have your report kept anonymous, email security@cmdash.com.