Summary
We take security seriously and we appreciate the work of researchers who report vulnerabilities to us.
If you find a security issue in Daxlate, email security@daxlate.com. Give us a reasonable amount of time to fix it before disclosing publicly. We do not pursue legal action against good-faith research conducted under this policy.
I. Reporting a vulnerability
Send a report to security@daxlate.com. Write in English or French.
We acknowledge receipt within two (2) business days.
A machine-readable version of this contact, per RFC 9116, is published at /.well-known/security.txt.
II. What to include
A useful report typically contains:
- A clear description of the vulnerability and its potential impact.
- Steps to reproduce, ideally with a minimal proof of concept.
- The version of the application or website affected (the desktop version is visible in Help → About).
- Your environment: operating system, Power BI Desktop version if relevant, browser and version for website reports.
- Any logs or screenshots that help us understand the issue, with sensitive data redacted.
- A name or handle you would like to be credited under, if you want public recognition.
III. Scope
The following are in scope for this policy:
- The Daxlate Windows desktop application, including the installer, the bundled runtime, and the license-validation flow.
- The marketing website at daxlate.com and any subdomain we operate.
- The license server and update manifest endpoints used by the application.
- Any artifacts we publish, including the MSI installer and the release manifest.
IV. Out of scope
The following are out of scope. Please do not test them, and we will generally not act on reports about them:
- Denial-of-service attacks, traffic flooding, brute-force attacks, or any test that degrades service for legitimate users.
- Social engineering of our staff, customers, or contractors.
- Physical attacks against our offices, equipment, or personnel.
- Issues in third-party services we use (Stripe, Microsoft Power BI, our cloud infrastructure provider). Report those to the relevant vendor.
- Vulnerabilities that require physical access to an unlocked machine, root or administrator on the user’s device, or a debugger attached to the application.
- Theoretical issues without a demonstrated security impact (missing security headers on static pages with no sensitive content, missing rate limits with no exploit path).
- Reports generated solely by automated scanners without manual validation.
V. Safe harbor
If you act in good faith, comply with this policy, and avoid privacy violations, service disruptions, and data destruction, we will not pursue or support legal action against you for your research.
This includes claims under the Canadian Criminal Code provisions on unauthorized use of a computer (sections 342.1 and 430(1.1)) and similar laws in your jurisdiction, to the extent we can waive them.
We cannot waive third-party rights or grant immunity against laws we do not enforce. If your research could affect a third party (a customer, an integration partner, an infrastructure provider), coordinate with us first.
If a third party initiates legal action against you for research conducted under this policy, let us know. We will make clear to that third party that your activity was authorized under this policy.
VI. Response timelines
- Initial acknowledgement: within 2 business days of the report.
- Triage and severity classification: within 5 business days, using CVSS 3.1 as a baseline.
- Remediation target: 30 days for critical, 60 days for high, 90 days for medium, best-effort for low. Complex issues may take longer; we keep you updated.
- Public disclosure: coordinated with you, typically once a fix is available and customers have had a reasonable window to update.
VII. Coordinated disclosure
We ask that you give us 90 days from the date we acknowledge your report before disclosing publicly. If we have shipped a fix before then, we coordinate disclosure with you on a mutually agreeable date. If we have not, we tell you why and propose a timeline.
If a vulnerability is being actively exploited in the wild, we move faster, and we may publish before the 90-day window if doing so protects users.
VIII. Recognition
With your permission, we credit researchers in the changelog entry for the release that contains the fix.
We do not currently operate a paid bug bounty program. If we launch one in the future, we will announce it on this page.
IX. Vulnerabilities in third-party components
We use open-source components (the .NET runtime, Serilog, ClosedXML, BouncyCastle, and others). If you find a vulnerability in one of those components, report it to the upstream maintainers first. If you believe our use of the component introduces an exploitable issue specific to Daxlate, report it to us as well.
X. Contact
- Security disclosures: security@daxlate.com.
- For non-security matters: contact@daxlate.com.
- Postal address: 15152038 Canada Inc., 11 Avenue Ste Brigitte, B, Sainte-Brigitte-de-Laval, QC G0A 3K0, Canada.
Document version 1.0 · last updated May 2026