Legal
Security
How we secure the service, and how to report a vulnerability.
Reporting a vulnerability
If you believe you have found a security vulnerability in fulcrumcode.app, the fulcrum CLI, the VS Code extension, or any other component we ship, please email security@fulcrumcode.app with:
- A clear description of the issue.
- Steps to reproduce, or a proof-of-concept (private link preferred over public Gist).
- Your assessment of impact, if you have one.
We acknowledge reports within 3 business days and aim to triage within 7 business days. We will keep you informed of our remediation progress.
We don't currently run a paid bug bounty programme but we will publicly credit researchers who report responsibly disclosed vulnerabilities (with your permission).
Safe-harbour
We will not pursue legal action against researchers who, in good faith and following responsible-disclosure practice:
- Test on accounts they own, with no impact on other users' data or service availability.
- Stop testing as soon as they confirm a vulnerability exists, and do not exfiltrate, modify, or destroy data.
- Don't publicly disclose the vulnerability before we've had a reasonable opportunity to fix it (typically 90 days).
What's in scope
- fulcrumcode.app and all its subdomains
- The
fulcrumCLI (latest published release) - The VS Code extension (latest published release)
- The release pipeline and build artefacts
What's out of scope
- Issues affecting only outdated browsers or unsupported operating systems.
- Social-engineering attacks on us, our staff, or our customers.
- Denial-of-service via brute traffic.
- Issues in third-party services we use (Stripe, Vercel, scx.ai, MailerSend) — please report those to the relevant vendor.
How we secure the service
- Transport encryption: TLS 1.3 with HSTS preloading on fulcrumcode.app.
- Authentication: passwordless magic-link sign-in with single-use tokens, 24h TTL, and a confirmation interstitial that resists corporate email-gateway pre-fetch attacks.
- Session storage: database-backed sessions that we can revoke server-side instantly.
- Secrets at rest: scx.ai API keys held in AES-256-GCM ciphertext with a master key from environment variables only.
- OS keychain on the client: the CLI stores session tokens in macOS Keychain, libsecret on Linux, or Windows DPAPI — never in a plaintext file.
- Pinned CA bundle: the bundled binary uses certifi's CA store so HTTPS verification works on minimal Linux containers.
Disclosure history
No security advisories yet. This section will list resolved issues, their CVE assignments (if any), and the researchers we credit for finding them.
security.txt
The machine-readable equivalent of this page lives at /.well-known/security.txt (RFC 9116).