§ Security
Security and coordinated disclosure
Where to send a vulnerability, what we will do and by when — and what belongs in the content-advisory path instead.
Reporting a vulnerability
Send it to security@scellis.com. Please include what you did, what happened, and what you expected — a short reproduction is worth more than a long description. If you have a proof of concept, attach it; if it needs a specific account state, say so rather than creating one on someone else's account.
You do not need permission to look. Testing against your own account and your own content is welcome, and we will not pursue a researcher who stays inside the boundaries below. You may report anonymously; we will still answer if you give us any channel to answer on.
This file's machine-readable counterpart is at /.well-known/security.txt (RFC 9116). It carries an expiry date, so a stale copy announces itself instead of quietly misdirecting your report.
What belongs in this channel — and what does not
This channel is for vulnerabilities in the PLATFORM: the API worker, the relay, the browser sandbox, the authentication and authorization surface, the billing webhook, the object store, and the way any of them can be made to do something they should refuse.
It is NOT the channel for compromised CONTENT. A malicious block, a pack whose bytes changed, a dataset with an embedded payload, a listing that is not what it claims — those travel the in-product report path (every publicly visible entity, release, listing, note and profile can be reported from the surface it appears on) and, once triaged, the advisory path that reaches the catalog and everyone who installed it. Sending content problems here routes them to the people who cannot act on them fastest.
Also out of scope: missing security headers with no demonstrated impact, volumetric denial of service, reports produced solely by an automated scanner, and social engineering of anyone involved with Scellis.
Boundaries we ask you to keep
Use your own accounts and your own data. Do not access, modify, or exfiltrate another person's content; if a flaw gives you access to someone else's data, stop, record only what you need to demonstrate it, and tell us.
Do not degrade the service for other people: no volumetric load testing, no mass account creation, no automated scanning that changes state. Do not use a vulnerability to keep access, and do not leave anything behind.
Do not publish before we have had a chance to fix it (see the timeline below). If you believe a fix is being delayed unreasonably, tell us that — it is a conversation, not a rule we apply to you unilaterally.
What we will do, and when
We acknowledge every report within 3 working days, and tell you within 10 working days whether we have reproduced it and how we have assessed its severity.
We aim to fix a critical vulnerability within 30 days of reproduction, and a high-severity one within 90 days. Lower severities are scheduled and we will tell you where. If a fix slips, we tell you why rather than going quiet — a missed date you know about is workable; silence is not.
We disclose after the fix ships, and we credit you by the name you choose (including not at all). We will agree the wording with you before publishing. Scellis is pre-launch and runs no bug-bounty programme, so there is no payment; we say that plainly rather than leaving you to discover it after the work.
If personal data was affected
A vulnerability that exposed personal data is also a personal-data breach, and it triggers the GDPR Article 33/34 path in parallel with the fix: notification to the competent supervisory authority within 72 hours of us becoming aware, and direct communication to affected people where the risk to them is high.
That process runs whether or not the report came through this channel, and it does not depend on the reporter following any part of this policy.