Status: the disclosure process is published here. The security.txt advertisement still needs mounting on signetauth.com. Written: 2026-08-08. Review by: the first report received, or 2026-11-08.
Why this document exists before the feature list
Signet's first cardinal is that security is the floor — it guards other people's users, and a discovered vulnerability obligates a response: fix, disclose to affected customers, re-certify. A product that says that and then offers no monitored way to tell us has a gap between its claim and its conduct. This closes that gap.
⚠ It is deliberately modest. Everything below is something we can actually do at current size. A published response window we miss is worse than no window at all, so the numbers here are ones a two-person operation can hold on a bad week.
How to report
Email security@signetauth.com. Encrypt if you like; a plaintext report is fine and is not a reason to delay.
Include, in whatever form you have it:
- what you found, and the impact you believe it has;
- how to reproduce it — a request, a sequence, a script; and
- the Signet version and deployment shape (hosted, self-hosted, sealed) if you know them.
If you cannot email, any channel that reaches us is better than silence.
Do not open a public issue, post it publicly, or include it in a support ticket through the ordinary channel — a support ticket is read by more people, sooner, than a security report should be.
What happens next, and when
| Stage | Our commitment |
|---|---|
| Acknowledgement | Within 2 business days, from a human, confirming we have it |
| First assessment | Within 7 business days — our reading of severity and whether we can reproduce |
| Fix or plan | For anything we assess as high or critical, a fix or a dated plan within 30 days |
| Disclosure to affected customers | As part of the fix, per the standing obligation — not at our convenience |
A report classified security is handled by a person. It is never auto-replied to, never auto-triaged by an agent, and never auto-closed. That is a property of the system, not a promise about intentions: the ticket lane refuses agent triage on a human-classified security ticket outright, and surfaces even a suspected one for immediate attention.
Scope
In scope: the Signet engine and its served surfaces (authentication flows, session and token handling, the OAuth/OIDC provider, SAML SSO, the admin API and dashboard, the served HTML pages), the licence-verification path, and our own hosted instances.
Out of scope, and please do not spend your time here:
- Findings from automated scanners with no demonstrated impact.
- Missing headers or TLS configuration with no exploitable consequence.
- Social engineering, physical access, or attacks on our staff.
- Denial of service through sheer volume. ⚠ Resource-exhaustion bugs — where a small, cheap request costs us disproportionately — are in scope and we want them.
- Anything requiring a compromised device or a malicious browser extension.
- Reports about a customer's own deployment configuration, unless our defaults caused it.
Safe harbour
If you make a good-faith effort to follow this document, we will not pursue or support legal action against you for your research. Good faith means: you stop at proof, you do not access, modify or retain data that is not yours, you do not degrade service for others, and you give us a reasonable chance to fix the issue before telling anyone else.
We will not ask you to sign an NDA as a condition of reporting, and we will not use a disclosure timeline as leverage.
What we do not offer
There is no bug bounty and no monetary reward. Saying so plainly is more respectful of your time than leaving it ambiguous. What we do offer: credit in the release notes and the changelog if you want it, a named acknowledgement here, and an honest account of what we changed.
We are a small operation. If that trade is not worth your time, we understand.
Publishing security.txt
RFC 9116 places the advertisement at /.well-known/security.txt on the organisation's domain — signetauth.com — not on each customer's instance. Serve this content as plain text:
Contact: mailto:security@signetauth.com
Policy: https://signetauth.com/security
Preferred-Languages: en
Expires: <one year out, ISO-8601 — this field is REQUIRED by RFC 9116>⚠ Expires is mandatory and it is a live liability: an expired security.txt reads to a researcher as an abandoned channel. Whoever mounts it should also decide how it gets renewed — a calendar reminder is sufficient and better than nothing, but a generated value with a check is better. Do not mount this with a hand-typed date nobody owns.
Two things must be true before it is mounted, or the advertisement is a lie:
security@signetauth.comexists and reaches a human inbox that is actually read.- Someone has agreed to the acknowledgement window above. Two business days is the promise; it is not automatic.
Filing a report into the console
Once received, a security report becomes a ticket so it acquires a status walk and an audit trail rather than living in an inbox:
curl -X POST "$CONSOLE/api/ingest/ticket" \
-H "x-ingest-secret: $CONSOLE_INGEST_SECRET" \
-H 'content-type: application/json' \
--data '{"subject":"<short summary>","body":"<the report>","source":"security@","reporter_email":"<reporter>"}'Then classify it security in the console immediately. That classification is what locks agents out of it and what raises it on the needs-attention band — until a human sets it, an agent may still suspect security (which also raises it), but the hard refusal only attaches to the human call.