Security · Coordinated disclosure
Report a vulnerability.
Glacis sells verifiable evidence, so the way we handle a security finding has to be checkable too. This page is the whole policy: what is in scope, what protection you have while you look, and what we will actually do after you press send.
The short version
Mail [email protected]. A person reads it. We aim to acknowledge within three business days and to tell you what we think of it within ten. There is no bug bounty and no NDA. If you act in good faith under this policy, we will treat your testing as authorized and will not come after you for it.
The machine-readable version of this contact is at /.well-known/security.txt, in the RFC 9116 format.
Contents
1. What is in scope
These are the systems and artifacts Glacis operates or publishes, and therefore the ones we can authorize you to test:
- glacis.io and www.glacis.io — this website.
- app.glacis.io — the Console, including signup, authentication, and the receipt event stream.
- api.glacis.io — the public API surface.
- verify.glacis.io and the in-browser verifier — including any path by which a receipt under verification could reach a server.
- docs.glacis.io — the documentation site.
- overt.is — the OVERT standard site and its machine-readable feeds.
- Our published code — the SDKs and sample code at github.com/Glacis-io.
- The OVERT specification itself — the receipt schema, canonicalization, signing, hash chaining, inclusion proofs, and the verification procedure. See section 9.
Anything that lets an attacker read customer content, forge a receipt, break a verification result, escalate privilege, or reach data that is not theirs is worth reporting even if it does not fit the list neatly. When in doubt, send it.
2. What is out of scope
- Customer environments. Glacis controls run inside the customer’s own infrastructure. We cannot authorize you to test a system we do not operate, and we will not pretend otherwise. If you believe a customer deployment is affected, tell us and we will contact the operator.
- trust.glacis.io. Our Trust Center is run for us by a third-party portal provider. Send the finding to us anyway and we will route it to them.
- Third-party services we use for email, analytics, scheduling, or payments — unless the flaw is in how we have configured them, in which case it is ours and it is in scope.
- Scanner output with no demonstrated impact. A tool reporting a finding is a hypothesis. Show us the path.
- Hardening opinions with no exploit path on a static marketing site: header preferences, TLS cipher lists, cookie flags on non-session cookies, version disclosure, clickjacking with no state-changing action, missing rate limits without demonstrated abuse.
- Mail configuration — SPF, DKIM, or DMARC findings on domains and subdomains we do not send mail from.
- Self-inflicted findings — self-XSS, attacks requiring a compromised device, a stolen credential, or a rooted browser extension.
- Denial of service, volumetric or load testing, social engineering of our staff or our customers, and physical attacks. These are out of scope in every direction, including as a demonstration.
3. How to report
Mail [email protected]. There is no portal, no form, and nothing to sign before we read it.
A report we can act on quickly usually has:
- the URL, endpoint, package, or SDK version affected;
- what you did, step by step, in enough detail that we can reproduce it;
- what you observed, and what an attacker gets out of it;
- any proof-of-concept code or request captures;
- the accounts, source addresses, and user agents you used, so we can tell your traffic apart from a real attack while we investigate.
One issue per report, please. If you would rather send the detail encrypted, say so in a first message that contains no detail and we will arrange a channel. We do not publish an OpenPGP key today, which we would rather admit than fake.
4. What happens next
| Stage | Our target |
|---|---|
| Acknowledgement that a person has your report | 3 business days |
| Triage: in scope or not, our severity assessment, and whether we intend to fix | 10 business days |
| Progress update while a fix is open | At least every 14 days |
| Fix | No fixed deadline. We give you a target at triage and tell you when it moves. |
Those are targets, and they are deliberately conservative, because Glacis is a small company and a published number we miss is worse than an honest one we keep. They are not a contractual commitment and nothing here creates a service level. If we miss one, say so in the thread — that reply goes to the same people.
If we decide not to fix something, we will tell you that plainly, with the reasoning, rather than letting the thread go quiet.
5. Safe harbor
If you make a good-faith effort to follow this policy while researching a vulnerability, we will treat your activity as authorized. Specifically, we will not initiate or support legal action against you under the Computer Fraud and Abuse Act, the Washington State computer-crime statutes, or the anti-circumvention provisions of the Digital Millennium Copyright Act; we will not ask your employer to act against you; and if a third party brings a claim about research that followed this policy, we will make your authorization known to them and, if it helps, publicly.
Two limits, stated rather than buried. First, this authorization is only ours to give for systems we operate. It does not extend to a customer environment, to a hosting or infrastructure provider, or to any other third party. Second, if testing breaks the rules in section 6 — by reaching another person’s data, or by degrading the service — the safe harbor does not cover that part of the work.
If you are unsure whether something is in scope, or whether a particular test crosses a line, write to us first and ask. We would much rather answer that question in advance than argue about it afterwards.
6. What we ask of you
- Use your own test accounts and your own data. Do not access, modify, save, or exfiltrate anything belonging to anyone else.
- If you do encounter customer content, personal data, or credentials, stop at the point of proof. Do not keep a copy, tell us immediately, and delete what you have once we confirm receipt.
- Do not degrade the service. No load testing, no automated scanning heavy enough to affect other users, no persistent backdoors, and no changes to data that is not yours.
- Do not use the finding as leverage. A report conditioned on payment, or held over us, is extortion rather than research, and it forfeits the safe harbor.
- Give us a reasonable window before going public. Section 8 says what we think reasonable means.
- Obey the law. Nothing in this policy authorizes anything that is illegal where you are or where the system is.
7. What we do not offer
There is no bug bounty. Glacis does not pay for vulnerability reports today. That is a resourcing decision at our current size, not a judgment about the value of the work, and if it changes this page changes first.
We will not make you sign a non-disclosure agreement as a condition of reporting, and we will not ask you to stay quiet indefinitely. We do not run a leaderboard, a portal, or a triage vendor. What you get is a direct thread with the people who can fix the thing, and credit if you want it.
8. Publication and credit
We ask for 90 days from our acknowledgement before you publish, or until a fix is deployed, whichever comes first. If we need longer than that we will tell you why and propose a date, rather than expect open-ended silence. Coordinated disclosure is a negotiation between two parties, not an obligation you owe us.
Tell us how you want to be credited and we will use exactly that, including a link. Tell us you want none and we will name nobody. Either way, where we write a fix up publicly we will describe the class of issue rather than bury it, because a fix nobody can see is indistinguishable from no fix.
9. Findings in the OVERT standard
A receipt is worth exactly what its verification is worth, so findings in the standard itself carry more weight with us than most web bugs. Anything affecting the OVERT receipt schema, the canonicalization rules, Ed25519 signing, the SHA-256 commitments, hash-chain construction, transparency-log inclusion proofs, or the verification procedure is in scope even when no Glacis system is affected.
You do not need our permission, an account, or a license to test this. The specification is published at overt.is, the standard is documented here, and any receipt can be checked in your own browser at the verifier. Verification is free and open, and we do not meter it.
Where a finding requires a correction to the standard rather than to our implementation, the correction goes into the versioned OVERT feed with the rest of the normative changes. A standard that only its author can audit is not a standard.
10. Machine-readable contact
The same contact information is published as an RFC 9116 security.txt, so a scanner, a crawler, or a researcher’s tooling can find it without reading this page:
Contact: mailto:[email protected] Contact: https://www.glacis.io/security-disclosure Expires: 2027-02-13T23:59:59.000Z Preferred-Languages: en Canonical: https://www.glacis.io/.well-known/security.txt Canonical: https://glacis.io/.well-known/security.txt Policy: https://www.glacis.io/security-disclosure
The Expires field is a promise about freshness rather than a technical limit. If that date has passed, treat the file as stale, and mail us anyway.
11. What this page does not cover
This is a disclosure policy, not a security program summary. Certification status, the subprocessor register, the data processing agreement, penetration-test summaries, and the rest of the artifacts a procurement team asks for live in the Trust Center at trust.glacis.io. Our privacy policy covers personal information, and the terms of service set out the incident-notification and availability commitments that apply to customers under contract.
If a document you need for a security review is not in the Trust Center, ask us and we will tell you plainly whether it exists yet. An evidence company should not be vague about its own evidence.
12. Changes to this policy
Material changes get a new version number and a new date in the header of this page. The Expires date in security.txt is the deadline we hold ourselves to for reviewing both, so the two never drift apart for longer than six months.
13. Contact
Security reports: [email protected]
Everything else: [email protected]
GLACIS Technologies, Inc., Seattle, Washington, USA