generated: '2026-08-26'
method: searched
source: https://getzipline.com/vulnerability-reporting/
summary: >-
  Retail Zipline publishes a dedicated vulnerability reporting page on its own
  domain. It is not advertised through a security.txt — no RFC 9116 document is
  served on any Zipline-controlled host (the two /.well-known/security.txt files
  that do return 200 belong to Atlassian Statuspage and Intercom, not Zipline).
program:
  published: true
  policy_url: https://getzipline.com/vulnerability-reporting/
  title: Reporting Security Vulnerabilities for Zipline
  security_page: https://getzipline.com/security/
  security_addendum: https://getzipline.com/security-addendum/
  bug_bounty: false
  bug_bounty_platform: null
  bug_bounty_note: No HackerOne, Bugcrowd or Intigriti program was found for Retail Zipline.
security_txt:
  served: false
  hosts_checked:
  - getzipline.com
  - api.retailzipline.com
  - status.retailzipline.com
  - support.retailzipline.com
  - trust.getzipline.com
  note: >-
    404 on getzipline.com and api.retailzipline.com. The 200s on
    status.retailzipline.com and support.retailzipline.com are vendor boilerplate
    from Atlassian and Intercom respectively (their Canonical: fields point at
    atlassian.com and app.intercom.com), served on Zipline-branded CNAMEs — they
    are not a Zipline disclosure policy and are not credited as one.
  gap: >-
    Publishing /.well-known/security.txt on getzipline.com pointing at the
    existing /vulnerability-reporting/ page would make an already-real program
    machine-discoverable.
practices:
- Annual penetration test by an independent third party
- SOC 2 Type II certified
- CSA STAR Level 1 self-assessment completed
x-evidence:
- url: https://getzipline.com/vulnerability-reporting/
  http_status: 403
  note: Cloudflare bot-management interstitial to non-browser clients; page is live and indexed
  fetched: '2026-08-26'
- url: https://getzipline.com/.well-known/security.txt
  http_status: 404
  fetched: '2026-08-26'