generated: '2026-08-27'
method: searched
probe: true
source: https://www.opensanctions.org/docs/security/
policy:
  - https://www.opensanctions.org/docs/security/
contact:
  - security@opensanctions.org
bug_bounty:
  program: none
  platform: null
  note: >-
    No HackerOne/Bugcrowd/Intigriti program. The policy explicitly discourages
    automated scanning "for merch chasing".
disclosure_policy:
  type: coordinated vulnerability disclosure
  researcher_obligations:
    - Report findings to security@opensanctions.org
    - Provide enough information to reproduce the issue
    - Do not exploit the vulnerability or reveal it to others until it is resolved
    - Do not run automated scans in pursuit of swag
  provider_commitments:
    - Respond within days
    - Handle reports with strict confidentiality
    - Credit the discoverer on publication, with permission
evidence:
  - source: https://www.opensanctions.org/docs/security/
    kind: security-policy-page
    status: 200
  - source: 'DNS CAA record on opensanctions.org'
    kind: caa-iodef
    value: '0 iodef "mailto:security@opensanctions.org"'
    note: >-
      The same security contact is published in DNS via the CAA iodef record —
      corroborating evidence, captured independently by
      security/opensanctions-domain-security.yml.
gaps:
  - >-
    No /.well-known/security.txt (RFC 9116) on either api.opensanctions.org or
    www.opensanctions.org — both 404. The policy and contact already exist and are
    stable; publishing them as a security.txt is a ten-line fix that would make an
    existing posture machine-discoverable.
x-evidence:
  fetched: '2026-08-27'
  probes:
    - {url: 'https://www.opensanctions.org/docs/security/', status: 200}
    - {url: 'https://www.opensanctions.org/.well-known/security.txt', status: 404}
    - {url: 'https://api.opensanctions.org/.well-known/security.txt', status: 404}