Security disclosure policy

If you believe you have found a security vulnerability in any AssurePort property, we want to hear from you. This page is the canonical Policy URL referenced by /.well-known/security.txt (RFC 9116). Read it before you submit.

How to report

Send a single email to abuse@assureport.com with the following:

A description of the issue and its impact in your own words.
The exact URL or endpoint where the issue lives.
Step-by-step reproduction instructions (curl commands, payloads, screenshots).
Any account, header, or session data needed to reproduce — we will not penalise you for including credentials you used in testing.
Your preferred name for acknowledgment, or "anonymous".

For sensitive reports you may also CC legal@assureport.com. Reports submitted via X / Twitter / Mastodon DMs are not monitored — use email only.

PGP encryption (optional)

If your finding contains material you'd rather not send in plaintext, encrypt it to our disclosure key. Pin the fingerprint out-of-band (any two of: this page, /.well-known/security.txt's Encryption directive, a signed changelog entry, a signed blog post) before trusting it.

Disclosure key (rotated annually)

Fingerprint: 2026 ASSUREPORT DISCLOSURE — KEY ROTATION PENDING

Status: Publication queued for the Sprint 9 trust-anchor rotation. Until the ASCII-armoured block lands here, plaintext to abuse@assureport.com is acceptable — Resend forwards over TLS and the mailbox is monitored by the security on-call rotation.

In scope

Surface	Notes
`assureport.com`	Marketing surface, free intel APIs, public docs.
`app.assureport.com`	Console, tenant API, billing flows.
`api.assureport.com`	Public + tenant APIs.
The PDF / Markdown reports we generate	Findings rendering, data exposure across tenants.

Out of scope

Volumetric or denial-of-service testing of any AssurePort property.
Social engineering of AssurePort staff, contractors, or vendors (Polar.sh, Cloudflare, Anthropic, Fly.io).
Physical attacks against any AssurePort office, employee, or supplier.
Testing against tenants other than your own — including the platform's "self-pentest" target. Use the free intel toolkit if you want to look at the marketing surface without authentication.
Findings only reproducible in vulnerable client browsers we do not target (e.g. browsers older than 24 months, browsers without TLS 1.2 support).
Missing security headers on the marketing-only surface that does not handle authenticated data.
SPF / DMARC / DKIM policy nitpicks (we are aware; the corporate mail domain runs strict).

Safe harbor

AssurePort considers good-faith security research authorised under this policy to be:

Authorised under the Computer Fraud and Abuse Act (CFAA), if you are based in the United States.
Authorised under the Computer Misuse Act 1990, if you are based in the United Kingdom.
A legitimate purpose under Article 6(1)(f) GDPR (legitimate interests in operating a secure service) for any incidental processing of personal data that occurs while you reproduce a vulnerability.
Exempt from any terms of service breach claim we might otherwise raise.

"Good faith" means: you have a real belief in the vulnerability; you stop and report as soon as you confirm exploitability; you do not exfiltrate, modify, retain, or share customer data beyond the minimum needed to demonstrate the issue; and you give us reasonable time to fix before public disclosure.

Response timelines

Stage	Target
Acknowledge receipt	1 business day
Triage decision (in-scope / not-in-scope / dup)	2 business days
Critical / High remediation	Best effort within 14 days
Medium / Low remediation	Best effort within 60 days
Public disclosure	Coordinated; we publish accepted findings after the fix ships

If we miss a target, we will write to you with a status update before the deadline lapses. We do not pay bug bounties at this stage but we will credit you publicly (or keep you anonymous, your choice). Repeat valid reporters become trusted reporters and gain a faster channel.

Acknowledgments

We thank every researcher who reports a real issue here. The hall of fame is currently empty — AssurePort launched in May 2026 and we are early in our public disclosure history. Reports accepted under this policy will be listed below with the date, severity, and a short description of the class of issue.

How a report makes it into the hall

The report is in scope per the table above, and the safe-harbor conditions held.
We were able to reproduce it from your write-up, or after a reasonable clarification round.
A fix shipped to production. The hall entry links to the changelog row.
You opted in to public acknowledgment. Anonymous reports still get a fix and a private thank-you; they just don't appear in the table.

Entry format

Each row carries the date the fix shipped, the affected surface, the severity tier we triaged it at, a one-line class-of-issue description, your preferred attribution name, and the changelog cross-link.

Shipped	Surface	Severity	Class	Reporter	Changelog
No external reports accepted yet — first entry pending.

Internal findings from the platform's self-pentest (Sprint 6 onward) are published separately — this table is reserved for external researchers under this policy.

Legal basis

This policy is referenced by https://assureport.com/.well-known/security.txt under RFC 9116. It is binding on AssurePort with respect to good-faith researchers who follow it. It does not waive criminal liability for actions outside its scope (e.g. denial of service, accessing other tenants' data, harming customers). It does not create employment, agency, or contractor relationships.

Last updated 2026-05-14. Policy revisions will not retroactively withdraw safe-harbor protection for reports that were already in good-faith progress.