Signsealship Vulnerability Disclosure

generated: '2026-09-01'
method: searched
source: https://signsealship.com/security
docs: https://signsealship.com/security
program:
  published: true
  type: direct-email responsible disclosure
  contact: security@signsealship.com
  contact_method: email
  policy_url: https://signsealship.com/security
  policy_section: RESPONSIBLE DISCLOSURE
  probed: '2026-09-01'
  http_status: 200
safe_harbor:
  stated: true
  wording: >-
    "A human reads every report, we'll acknowledge yours, and we won't pursue action against
    good-faith security research."
acknowledgement: >-
  Committed -- "we'll acknowledge yours". No SLA on time-to-acknowledge is published.
submission_requirements:
  - Steps to reproduce, where the reporter can supply them.
bug_bounty:
  present: false
  platform: none
  note: >-
    No HackerOne, Bugcrowd or Intigriti program was found. No monetary reward is offered or
    implied.
security_txt:
  present: false
  probed_urls:
  - url: https://signsealship.com/.well-known/security.txt
    status: 404
  - url: https://docs.signsealship.com/.well-known/security.txt
    status: 404
  gap: >-
    THE PROGRAM EXISTS BUT IS NOT MACHINE-DISCOVERABLE. A researcher's or scanner's first stop is
    /.well-known/security.txt, which 404s on both hosts; the address and the safe-harbor
    statement live only in prose on an HTML page. A four-line RFC 9116 file naming Contact:
    mailto:security@signsealship.com, Policy: https://signsealship.com/security and an Expires
    date would make an already-real program findable, and is the cheapest security improvement
    available to this provider.
disclosure_posture_note: >-
  Framed by the provider as "No forms, no gatekeeping." Deliberately low-friction, which is a
  reasonable posture for a company of this size -- the gap is discoverability, not intent.