OpenSanctions · Vulnerability Disclosure

Opensanctions Vulnerability Disclosure

Vulnerability disclosure

OpenSanctions runs a coordinated vulnerability disclosure program on Hackerone. A dedicated security contact is published.

Sanctions ScreeningAnti-Money LaunderingPolitically Exposed PersonsComplianceFinancial CrimeKnow Your CustomerEntity ResolutionOpen DataRisk DataDue DiligencePublic APIsagent-native
Program: Hackerone

Disclosure Policy

Policy

Security Contact

Contact
security@opensanctions.org

Source

Vulnerability Disclosure

Raw ↑
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}

Work with this as data

Every security artifact here is available over the APIs.io API and to AI agents over MCP.

MCP server

One button, every client — Claude, Cursor, VS Code and the rest.

https://apis.io/mcp

Tools for security posture

4 MCP tools reach this
  • find_securityBrowse and filter every security artifact in the catalog.
  • apis_io_searchSTART HERE — APIs, providers and tags for one query, each with its total.
  • resolveTurn a domain, URL or GitHub org into the provider it belongs to.
  • find_cohortsEvery scored population of providers in the catalog.
All 92 tools →

Call it yourself

curl for this page
This security artifact
curl "https://apis.io/api/v1/security/opensanctions-vulnerability-disclosure"
All security posture
curl "https://apis.io/api/v1/security?limit=25"

Discovery needs no key. Ratings and market analysis are Pro.

Get an API key

Free tier, no email required.

A second provider on the same verified email joins the account you already have.