Statsig Vulnerability Disclosure

generated: '2026-09-17'
method: searched
source: https://www.statsig.com/legal/security
description: >-
  Statsig publishes a substantive security policy page and names a Bug Bounty Program among its
  SDLC testing controls, but publishes no machine-readable or public intake for a vulnerability
  report: no /.well-known/security.txt on any of the seven hosts probed, no HackerOne or Bugcrowd
  program (both probed, 404), no /legal/vulnerability-disclosure page (the URL returns HTTP 200
  with a "Page not found" body — a soft 404), and no security@ contact on the policy page.
policy:
  url: https://www.statsig.com/legal/security
  http_status: 200
  published: true
  covers:
    - risk management against AICPA SOC 2 guidance, reviewed by a Security Governance Board
    - access controls, OIDC SSO, session management, password hashing
    - encryption in transit (TLS) and at rest (AES-256)
    - IDS/SIEM monitoring, retained access logs, incident response plan
    - SDLC controls including threat modeling, static analysis, peer review, annual third-party assessment
    - OWASP-aligned design and testing
bounty:
  named: true
  name: Bug Bounty Program
  evidence: https://www.statsig.com/legal/security
  public_program_url: null
  platform: null
  probed:
    - {url: 'https://hackerone.com/statsig', status: 404}
    - {url: 'https://bugcrowd.com/statsig', status: 404}
security_txt:
  present: false
  probed_hosts: [statsig.com, www.statsig.com, api.statsig.com, statsigapi.net, docs.statsig.com, events.statsigapi.net, console.statsig.com]
  see: well-known/statsig-well-known.yml
contact:
  disclosure_email: null
  general: https://www.statsig.com/contact
gaps:
  - >-
    An RFC 9116 /.well-known/security.txt naming a Contact and a Policy would make an existing
    program discoverable in one fetch. Today a researcher has to read a marketing page to learn
    the program exists, and then has no address to send to.