generated: '2026-08-30'
method: probed
source: live probes of /.well-known/security.txt on every TextQL host, plus https://textql.com/security
published: false
program: none-found
evidence:
- url: https://textql.com/.well-known/security.txt
  status: 404
- url: https://app.textql.com/.well-known/security.txt
  status: 404
- url: https://docs.textql.com/.well-known/security.txt
  status: 404
- url: https://textql.com/security
  status: 200
  note: >-
    A substantive security page, but it documents the product's security ARCHITECTURE (isolation,
    encryption, identity, authorization, network, key management) and links a Drata trust center. It
    names no security contact, no disclosure policy, no reporting address and no safe-harbour terms.
- url: https://trust.textql.com/
  status: 403
  note: Drata-hosted trust center; unreadable this run, so any disclosure policy it may carry was not observed.
findings:
  security_txt: absent
  disclosure_policy: not-found
  bug_bounty: not-found
  bounty_platforms_checked: [HackerOne, Bugcrowd, Intigriti]
  security_contact: not-found
  note: >-
    No RFC 9116 security.txt on any host, and no vulnerability disclosure policy, security contact or
    bug bounty found on the public site. The only published contact of any kind is
    support@textql.com, which is a general support address, not a security one. For a vendor whose
    pitch is enterprise data security — SOC 2 Type II, HIPAA BAAs, air-gapped deployment — the absence
    of a published route for a researcher to report a vulnerability is a conspicuous gap, and a
    security.txt is the cheapest possible fix.
remedy: >-
  Serve /.well-known/security.txt on textql.com and app.textql.com with Contact, Policy, Preferred-Languages
  and Expires fields (RFC 9116), and link a disclosure policy from the security page.