Security claims — and what we won't claim
Every claim we make comes with a code path, a configuration file and a verification recipe. You can audit them without an NDA call.
What we claim
- Encryption at rest and in transit
- Identity enforced at the network edge, before application code
- Fail-closed egress
- Encrypted DNS end to end
- Tenant isolation at the database row level
- Provenance stamps on every row
- Audit logging of analyst actions
What we explicitly do NOT claim
- We do not claim FedRAMP, SOC 2 or ISO 27001. We hold none of them.
- We do not claim an air gap for the hosted service
- We do not claim defence against a nation-state adversary with simultaneous visibility across multiple networks
- We do not vouch for third-party policies we cannot audit
- We do not say "anonymous" about anything, because we cannot prove it
A CJIS v5.9.5 gap analysis is complete and available under NDA. A security questionnaire is available on request.
Why publish the limits
Because a buyer who catches one oversell correctly stops believing everything else. The fastest way to be trusted with the hard claims is to be visibly unwilling to make the easy ones.
A control, and the first thing it caught
We built an automated scan that reads our published spreadsheets before release and refuses any file containing identifiers that should not leave the estate. It clears roughly 1.6 million cells across the public datasets on every build.
The first thing it caught was us. An early build of one workbook carried full Bitcoin addresses belonging to parties no government has designated and no court has named. They are truncated now, and the incident is written up in the dataset's own README rather than quietly fixed.
A control that has never caught anything is a control nobody has tested.
Responsible disclosure
If you find a vulnerability in anything we publish or operate, we want to hear about it and we will not threaten you for telling us.
Write to [email protected]. Tell us what you found and how to reproduce it. We will acknowledge within two business days and keep you informed until it is closed.
Machine-readable details are at
/.well-known/security.txt (RFC 9116).
Encrypted correspondence
If you would rather not send it in the clear — a vulnerability report, a document, or anything a client considers sensitive — encrypt it to our PGP key and send it as an attachment to [email protected].
Fingerprint:
52CD 30AA 871C 39B7 C84F 8BB9 4057 B344 CA28 C89F
Public key: /pgp.asc
curl -sS https://quinndefensesystems.com/pgp.asc | gpg --import
gpg --list-keys 52CD30AA871C39B7C84F8BB94057B344CA28C89F
Check the full fingerprint above, not the short key ID. Short and long key IDs can be collided cheaply; a signature verified against one has not been verified. This is the same reason every address and hash on this site is set in monospace — these get transcribed by humans, and an ambiguous character in an identifier is an evidentiary problem rather than a typographic one.
We do not currently offer a web upload. Mail attachments are the supported route, which on our side means a ~25 MB ceiling. If you have something larger or more sensitive than that, say so in an encrypted message first and we will arrange a channel that fits.