← Back to Trust Center

Responsible disclosure & vulnerability management

EFFECTIVE: MAY 1, 2026 · LAST UPDATED: MAY 1, 2026

Security researchers and customers play an important role in keeping Arx safe. This page explains how to report a suspected vulnerability and how we triage, fix, and communicate about vulnerabilities once we know about them.

1. How to report

Email security@foundersarx.com with as much of the following as you can reasonably provide:

• A clear description of the issue and the impact you believe it has.
• Steps to reproduce, including request / response examples, payloads, or screenshots.
• Affected URL or product surface (web app, API, MCP, marketing site, public sharing link).
• Your handle or name if you would like to be credited, and how we can reach you for follow-up.

Please report privately to us first. Do not publicly disclose, post, or otherwise share the vulnerability until we have confirmed a fix has been deployed, or until the coordinated-disclosure window described below has elapsed.

We accept reports in English. PGP-encrypted reports are accepted on request — contact security@foundersarx.com to exchange keys.

2. Scope

The following Arx-operated surfaces are in scope:

• foundersarx.com — marketing site
• app.foundersarx.com — authenticated web application
• api.foundersarx.com — public REST API and webhooks
• Arx's MCP server and any OAuth flows it exposes
• Public sharing links Arx generates (data rooms, decks, public booking pages)
• Mobile or desktop clients we publish under the Arx name (if any)

3. Out of scope

The following are explicitly out of scope for this program and should not be reported as vulnerabilities:

• Findings on third-party services we use (Supabase, Vercel, Railway, Stripe, etc.) — report those to the provider directly.
• Denial-of-service tests, volumetric attacks, social engineering of Arx staff or customers, and physical attacks.
• Automated scanner output without a working proof of concept.
• Reports that consist solely of missing security headers, banner / version disclosure, or best-practice deviations without a demonstrable security impact.
• Issues that require a compromised browser, rooted device, or installed malicious extension.
• Self-XSS or self-induced privilege escalation in the reporter's own workspace.
• Email spoofing reports based on the absence of strict DMARC on non-sending subdomains.

4. Safe harbor

We will not pursue or support legal action against researchers who, in good faith, comply with this policy. Good faith means:

• You make a reasonable effort to avoid privacy violations, service degradation, and data destruction.
• You only interact with accounts you own or have explicit permission from the owner to test.
• You report the issue promptly and do not exploit it beyond what is necessary to demonstrate impact.
• You give us a reasonable amount of time to remediate before disclosing publicly.
• You comply with all applicable laws.

If at any point you are unsure whether a particular action is covered by this safe-harbor commitment, contact security@foundersarx.com first and we will tell you.

5. What to expect from us

• Acknowledgement — we aim to acknowledge new reports within 2 business days.
• Initial triage — within 5 business days we confirm whether we can reproduce the issue, classify severity, and assign an internal tracking ID.
• Status updates — we provide updates at least every 14 days while a report is open.
• Remediation — we patch on the schedule in §6.
• Coordinated disclosure — we agree a public disclosure window with the reporter, typically 90 days from initial report or earlier once a fix is deployed.

6. Severity & patching targets

We classify reported vulnerabilities using CVSS 3.1 base score as a starting point and adjust for real-world exploitability against the Arx environment. Our target time-to-fix from confirmation:

• Critical (CVSS 9.0–10.0; account takeover, mass data exposure, RCE): patch within 7 days; emergency change window may apply.
• High (CVSS 7.0–8.9): patch within 30 days.
• Medium (CVSS 4.0–6.9): patch within 60 days.
• Low (CVSS 0.1–3.9): patch within 90 days or queued into the next planned release.

If the issue is actively being exploited, all timelines compress and the on-call engineer is engaged immediately.

7. Internal vulnerability management

Alongside this disclosure program we maintain an internal vulnerability management process:

• Dependency scanning — automated scanning of npm dependencies (`pnpm audit` and provider advisories) on every pull request and on a daily schedule against the main branch.
• Static analysis (SAST) — code-level scanning runs on every pull request; findings block merge based on severity.
• Dynamic analysis (DAST) — authenticated and unauthenticated dynamic scans against a staging environment on a defined cadence and before major releases.
• Container & image scanning — base images and built containers are scanned for known CVEs before deploy.
• Penetration testing — we engage a qualified third party for periodic external penetration tests of the production environment and key product surfaces; an executive summary is available under NDA on request.
• Ownership — the engineering lead is accountable for the program. Each finding has a named owner, severity, due date, and remediation status tracked in our internal issue tracker.
• Risk acceptance — any finding that is not patched within the target window is documented with a written justification, a compensating control, and a review date.

8. Recognition

We do not currently operate a paid bug-bounty program. Researchers who report a confirmed vulnerability in good faith may be credited on a public acknowledgements list (with their permission) once the issue is remediated.

9. Contact

• Vulnerability reports — security@foundersarx.com
• See also — Security overview, Incident response, Infrastructure & dependency management

This page is the public summary of our vulnerability management procedures. Detailed runbooks live in our internal documentation and are available to assessors under NDA.