Reporting a vulnerability

If you believe you have found a security vulnerability in Furx (desktop app, the license API, or the public site), please report it to security@furx.cloud. We aim to acknowledge reports within 2 business days and to provide a remediation timeline within 5 business days.

Encrypt sensitive reports with our PGP key (fingerprint published in /.well-known/security.txt).

What to include

A description of the vulnerability and its potential impact.
Steps to reproduce, including a minimal proof-of-concept where possible.
The affected component (desktop, license API, site) and version.
Whether the issue requires user interaction or specific OS/CLI configuration.
Your name + contact details for follow-up (optional but appreciated, hall-of-fame credit).

Coordinated disclosure

We follow a coordinated-disclosure model with a 90-day embargo from acknowledgement. We commit to:

Working in good faith to investigate and fix valid reports.
Providing credit in our hall of fame (with your permission).
Not pursuing legal action against researchers who comply with this policy.
Public disclosure with CVE assignment when applicable.

Reward programme

Furx is bootstrapped, so we don't have a cash bounty programme. We offer:

Pro lifetime for the first valid HIGH/CRITICAL report.
One year Pro for valid MEDIUM reports.
Public credit in the hall of fame for all valid reports.

Out of scope

Denial-of-service or volumetric attacks against the public site or license API.
Social-engineering attacks against Furx staff (sole founder).
Vulnerabilities in third-party dependencies that have not yet been disclosed by the upstream maintainer.
Theoretical vulnerabilities without practical impact.
Issues affecting unsupported versions (older than 6 months).
BYOK key compromises caused by user mistakes (e.g., committing keys to public repo) — Furx never stores or transmits user keys.

Security controls in place

OS Keychain (macOS), Secret Service (Linux), Credential Manager (Windows) for all secrets.
Append-only audit log (SQLite triggers block UPDATE/DELETE).
Apple Dev ID notarization (macOS, Team ID 7SB9GJ5W4L).
Azure Trusted Signing (Windows).
Tauri auto-update signed with minisign (Ed25519); public key in tauri.conf.json.
SHA256 manifest + minisign signature on every release artifact.
License API: HTTPS only, HMAC-SHA256 webhook validation (Paddle), short-lived JWTs.
Public site: HSTS preload, CSP with no unsafe-inline, Subresource Integrity on third-party scripts.
Magic-link sign-in rate-limited (3/min per IP via Cloudflare).
Crash capture with PII scrub (no paths, no env vars, no clipboard).
Renovate weekly + manual pip-audit / npm audit / osv-scanner in CI.
Gitleaks pre-commit + GitHub Actions.

Trust signals

/.well-known/security.txt (RFC 9116) — contact + PGP + canary.
GitHub Security Advisories — public CVE list.
SECURITY.md — version support matrix.
DPA for Team/Enterprise customers with audit-evidence clause.

Known accepted risks (transparency)

CSP script-src 'unsafe-inline' on the marketing site: we use inline application/ld+json blocks for Schema.org. Static export precludes nonce-based CSP, and hash-based CSP would re-issue per JSON-LD change. We accept this and mitigate by minimizing inline scripts to data-only (no executable inline). Tracking a future move to nonce CSP via edge Worker.
SmartScreen on Windows first-launch warning is expected on fresh releases (reputation accrues over installs); the binary is signed via Azure Trusted Signing.

Hall of fame

Open. Be the first.

Security policy