Validic Vulnerability Disclosure

generated: '2026-08-15'
method: probed
source: live HTTPS probes of every Validic-controlled host + site search
program_published: false
description: >-
  Validic publishes NO vulnerability disclosure programme. There is no
  security.txt on any host it controls, no /security or /responsible-disclosure
  page, no security@ contact documented on the public site, and no listing on a
  bug-bounty platform. Recorded as an honest absence - this is a measurement,
  not a judgement about Validic's internal security posture.
security_txt:
  served_by_validic: false
  probes:
  - url: https://validic.com/.well-known/security.txt
    status: 404
  - url: https://validic.com/security.txt
    status: 404
  - url: https://developer.validic.com/.well-known/security.txt
    status: 404
  - url: https://developer.validic.com/security.txt
    status: 404
  - url: https://api.v2.validic.com/.well-known/security.txt
    status: 403
  - url: https://streams.v2.validic.com/.well-known/security.txt
    status: 403
  - url: https://dashboard.validic.com/.well-known/security.txt
    status: 403
  - url: https://api.dashboard.validic.com/.well-known/security.txt
    status: 403
  - url: https://help.validic.com/.well-known/security.txt
    status: 403
  - url: https://trust.validic.com/.well-known/security.txt
    status: 200
    credited: false
    owner: Atlassian
    detail: >-
      The one 200 in the whole sweep, and it is not Validic's. It is the
      Atlassian Statuspage platform's own PGP-signed RFC 9116 document, served
      because trust.validic.com is CNAME'd to
      qtyl0stcbvvr.stspg-customer.com. Its fields name Atlassian throughout -
      Contact https://www.atlassian.com/trust/security/report-a-vulnerability,
      Contact mailto:security@atlassian.com, Policy on atlassian.com, and an
      explicit Canonical: https://www.atlassian.com/.well-known/security.txt.
      Reporting a Validic vulnerability to that address would route it to
      Atlassian's security team, not Validic's. Not credited, not saved.
disclosure_page:
  published: false
  probes:
  - url: https://validic.com/security/
    status: 200
    detail: soft-404 - 200-redirects to https://validic.com/
  - url: https://validic.com/compliance/
    status: 200
    detail: soft-404 - 200-redirects to https://validic.com/
bug_bounty:
  platform: null
  hackerone: not found
  bugcrowd: not found
  intigriti: not found
contacts:
  security_email: null
  general_support: https://help.validic.com/portal/2
  note: >-
    Validic employs a CISO (David Hoover, profiled on the company blog) and
    asserts HITRUST and ISO 27001 certification, so a disclosure process
    certainly exists internally. It is simply not reachable from the public
    surface - a researcher who found a flaw would have to open a general
    support ticket.
recommendation: >-
  A single RFC 9116 security.txt at https://validic.com/.well-known/security.txt
  naming a security contact and a policy URL would close this. It is the
  cheapest unclosed gap on the profile, and for a HIPAA-regulated platform
  handling PHI from 700+ device integrations it is the one most out of step
  with the rest of Validic's compliance posture.
maintainers:
- FN: Kin Lane
  email: kin@apievangelist.com