Security

Vulnerability Disclosure Policy

Found a security problem in Spodus? Here's how to tell us, and what we promise in return.

Effective July 28, 2026

We’d rather hear about a vulnerability from you than from an attacker. If you’ve found one, email [email protected]. You don’t need permission to start, and you don’t need to know whether it’s serious; tell us and we’ll work it out.

Spodus does not currently run a paid bug bounty. We say that up front rather than letting you find out after the work. What we do offer is a fast, human response, credit where you want it, and the safe harbour in clause 5.

1. How to report

Email [email protected]. A useful report usually includes:

the affected URL, endpoint or feature;
a description of the issue and why you think it matters;
steps to reproduce, ideally the minimum needed;
any proof-of-concept, screenshot or request/response capture; and
how you’d like to be credited, or that you’d rather not be.

Write in English if you can. If encryption matters for what you’re sending, say so in a first email and we’ll arrange a channel.

2. What we commit to

Acknowledgement within 3 business days that a human has read your report.
An initial assessment within 10 business days, telling you whether we’ve reproduced it and how we’ve rated it.
Progress updates at least every 15 business days until it’s closed.
Notification when it’s fixed, and credit on request.
No legal action against you for research conducted under clause 5.

3. In scope

spodus.com and its subdomains
app.spodus.com, the Spodus Cloud application
Our public API endpoints

We’re most interested in authentication and session handling, authorisation and tenant isolation (anything that lets one workspace reach another’s data), injection, remote code execution, server-side request forgery, and exposed secrets or credentials.

4. Out of scope

Third-party services we don’t operate, including our sub-processors. Report those to the provider directly.

Also out of scope, and generally not something we’ll act on:

findings from automated scanners without a demonstrated, exploitable impact;
missing security headers or cookie flags with no proven exploit path;
rate limiting on non-authentication endpoints;
self-XSS, or attacks requiring a fully compromised victim device;
social engineering of our staff or customers;
denial of service, volumetric or otherwise;
outdated browser or TLS version support, absent a working attack;
email configuration findings (SPF, DKIM, DMARC) without a demonstrated spoofing path.

5. Safe harbour

If you make a good-faith effort to comply with this policy during your research, we will consider that research authorised. We will not initiate or support legal action against you in connection with it, including under the Computer Fraud and Abuse Act or the Digital Millennium Copyright Act, and if a third party brings action against you for research that complied with this policy, we will make it known that your work was authorised.

To stay inside that protection, please:

use only your own test accounts and data;
stop as soon as you’ve confirmed a vulnerability, and don’t pivot further into our systems;
never access, modify, exfiltrate or retain data belonging to anyone else, and delete anything you encounter incidentally;
avoid degrading the service for others, so no denial-of-service or destructive testing;
give us a reasonable chance to fix the issue before disclosing it publicly, 90 days as a default; and
don’t use the finding as leverage for payment. See the note at the top about our lack of a bounty.

If you’re unsure whether something is permitted, ask first at [email protected]. Asking never counts against you.

6. Credit

We’re happy to publicly credit researchers who report valid issues, once a fix has shipped and with your agreement on wording and timing. Tell us how you’d like to be named, or that you’d prefer to stay anonymous, and we’ll respect it.

Olum LLC8206 Louisiana Blvd NESte A #8845Albuquerque NM 87113