Security
Report a vulnerability
If you have found a security issue in Scienter, we want it, and we will not come after you for finding it. This page sets out what is in scope, the protections you have when you test within it, how quickly we respond, and — plainly — the current state of the reporting channel.
Last updated: 2026-09-02
1
How to report
Send the report to [email protected].
We are not offering a second channel we cannot honour. The repository is private, so a GitHub security advisory link would 404 for you; there is no submission form and no ticketing integration in this application to route a report through. One address, honestly described, is what exists.
Include, if you can:
- The exact URL, endpoint or component, and the environment you tested against.
- Reproduction steps precise enough to follow without guessing, and the request or payload that triggers it.
- What an attacker gets. The impact statement is what sets severity, and a clear one is worth more than a long report.
- Whether you have shared it with anyone else, and any deadline you intend to hold us to.
Please do not open a public issue, post it, or include it in a write-up before it is fixed. Coordinated disclosure terms are in section 5.
2
Scope
In scope
- The application at scienter.xyz and its subdomains, including every public page and every route under
/api/. - The Telegram and Discord webhook endpoints, which are served by this deployment rather than by a separate bot host.
- The authentication, workspace and billing surfaces, including anything that lets one account observe or affect another.
- Integrity of published numbers. A way to make this site publish a scorecard, rank or verdict that the underlying data does not support is a security issue here, not merely a bug. It is the thing the product sells.
Out of scope
- Anything not deployed. The signal engine, the intelligence service and the
AlphaLedgercontract are in this repository and are not running on any public host. Findings against a local build of them are welcome as correspondence but are not in the programme, because we cannot verify an exploit against a deployment that does not exist. - Third-party services we merely use. Vercel, the exchanges and data providers we read, and the venues we link to. Report those to their own programmes.
- Findings from automated scanners with no exploit path, missing best-practice headers presented without impact, SPF, DKIM and DMARC observations, and rate-limit reports on unauthenticated public endpoints.
- The absence of MX records on scienter.xyz. We know. It is on this page, on the roadmap and on status.
- Social engineering, physical attacks, and denial of service. Do not attempt any of them. Volumetric testing against a small operation is indistinguishable from an attack and will be treated as one.
3
Safe harbour
If you make a good-faith effort to comply with this policy while researching a vulnerability, we will treat your research as authorised, we will not initiate or support legal action against you for it, and we will not report you to law enforcement. If a third party brings action against you for research conducted within this policy, we will make that authorisation known.
Good faith, in operative terms, means all of the following:
- You only accessed data that was yours, or that you needed to demonstrate the issue. The moment you can prove access, stop.
- You did not exfiltrate, retain, sell or publish anyone else’s data, and you deleted anything you incidentally obtained once the report was filed.
- You did not degrade the service, corrupt data, or interfere with anyone else’s use of it. No volumetric testing, no automated scanning at damaging rates.
- You reported promptly, gave us a reasonable chance to fix it, and complied with the disclosure terms in section 5.
- You complied with the law. This policy grants authorisation from us; it cannot and does not grant it from anybody else, and it is not legal advice.
Where a term of the Terms of Service would prohibit research that this policy permits, this policy governs for that research. That precedence is stated explicitly because an unaddressed conflict between the two is exactly what makes a safe harbour worthless.
4
Severity tiers and response times
Severity is set by demonstrated impact, not by scanner category. These are commitments about attention and are the part of this programme you can hold us to today.
- Remote code execution on any Scienter-operated host.
- Authentication bypass giving access to another account, workspace or tenant.
- Any path that could cause a user to sign a transaction they did not intend, or that introduces an order path into a product that has none by design.
- Disclosure of API credentials, database credentials or a signing key.
- Stored cross-site scripting on an authenticated surface.
- Server-side request forgery reaching internal services or cloud metadata.
- Injection into a data store, or into a rendered scorecard, from unauthenticated input.
- Privilege escalation within a workspace, or reading another workspace’s data.
- Reflected cross-site scripting, or cross-site request forgery on a state-changing route.
- Rate-limit bypass that enables enumeration or meaningful cost amplification.
- A published number that can be manipulated by an unauthenticated party — an integrity bug, and on this product a serious one.
- Information disclosure of non-public but non-credential data.
- Missing hardening headers with no demonstrated exploit path.
- Verbose errors, version disclosure, or an outdated dependency with no reachable sink.
- Issues requiring an already-compromised device, a physical attack, or an unrealistic degree of user interaction.
Every report gets a human answer, including the ones we decline, with the reason. A duplicate is credited to the first complete report that made the impact clear.
5
Coordinated disclosure
- We aim to remediate Critical and High findings within 30 days of acknowledgement, and Medium and Low within 90 days.
- Please hold publication until the fix is deployed, or until 90 days after acknowledgement, whichever comes first. If we need longer we will ask, explain why, and accept a refusal.
- We will credit you by whatever name you choose when the fix ships, or keep you anonymous. Tell us which.
- If we go quiet past the response times in section 4, publishing is reasonable and we will not treat it as a breach of this policy. A programme that can be used to silence a researcher through inaction is not a programme.
6
Rewards
There is no funded bounty pool, and we are not going to print a payout table we cannot honour. Scienter is operated by one person and no budget, escrow or payment rail exists for this programme today. Rewards are discretionary, decided case by case on demonstrated impact, and may be nothing.
What is not discretionary: the response times in section 4, the safe harbour in section 3, a human answer with a reason, and public credit if you want it. Those cost nothing to honour and they are the commitments this page is actually making.
If that changes, this page changes with it, and the effective date at the top moves.