generated: '2026-08-13'
method: searched
probe: true
source: https://close.com/security/submit-report
description: >-
  Close runs a public vulnerability-report intake at
  close.com/security/submit-report, linked from its security page as "Submit
  report". It publishes no security.txt on any host and names no bug-bounty
  platform (no HackerOne, Bugcrowd or Intigriti program was found), so the
  intake is a web form rather than a coordinated-disclosure program with
  published scope, safe-harbour language or reward terms.
policy:
  - https://close.com/security/submit-report
security_page: https://close.com/security
contact:
  - security@close.com
contact_provenance: >-
  security@close.com is published by Close itself in the iodef record of its DNS
  CAA policy for close.com (`0 iodef "mailto:security@close.com"`), captured in
  security/close-domain-security.yml. It is the address Close nominates to
  receive certificate-misissuance reports.
security_txt:
  present: false
  probed:
    - {url: 'https://www.close.com/.well-known/security.txt', status: 404}
    - {url: 'https://close.com/.well-known/security.txt', status: 404}
    - {url: 'https://api.close.com/.well-known/security.txt', status: 404}
    - {url: 'https://mcp.close.com/.well-known/security.txt', status: 404}
  note: >-
    RFC 9116 security.txt is the single cheapest fix available to Close here —
    the disclosure page and the security contact both already exist, they are
    just not machine-discoverable.
bug_bounty:
  program: null
  platform: null
  searched: [HackerOne, Bugcrowd, Intigriti]
evidence:
  - {source: 'https://close.com/security', kind: security-page, http_status: 200, fetched: '2026-08-13'}
  - {source: 'https://close.com/security/submit-report', kind: disclosure-intake, http_status: 200, fetched: '2026-08-13'}
  - {source: security/close-domain-security.yml, kind: dns-caa-iodef}