Trust · Responsible disclosure

Found a vulnerability? Tell us first.

Effective date · 1 June 2026

We welcome good-faith security research. Submit findings to security@pulsesignal.co and we will respond, fix, and credit you. This page is the canonical policy.

How to report

Email security@pulsesignal.co with:

  • A clear description of the vulnerability and the affected surface (URL, endpoint, parameter).
  • Steps to reproduce, with timestamps if relevant.
  • Proof of impact — what an attacker can read, change, or take over.
  • Your name (or a handle) and whether you want public credit.

If the report contains sensitive details, request our PGP key in the first email and we will reply with one. Do not include exploited customer data in your report — describe the path, not the payload.

Highest-priority classes

These are the classes of findings we treat as highest priority and acknowledge fastest:

  • Authentication / authorization bypass and account-takeover paths.
  • Server-side injection (SQL, command, template, deserialization).
  • Sensitive data exposure across customer accounts.
  • Server-side request forgery (SSRF) reaching internal services.
  • Privilege escalation to admin endpoints or other tenants.
  • Stored or persistent XSS on authenticated surfaces.
  • Logic flaws in billing, plan limits, or data-export endpoints.

Scope

In scope

  • pulsesignal.co (marketing site)
  • app.pulsesignal.co (authenticated dashboard)
  • api.pulsesignal.co (JSON API)
  • PulseSignal mobile clients (when published)
  • PulseSignal-controlled subdomains (status / docs / blog)

Out of scope

  • Social engineering, phishing, or physical attacks against PulseSignal staff or vendors
  • Denial of service (DoS / DDoS) or resource-exhaustion testing
  • Reports from automated scanners with no manual validation or proof-of-impact
  • Self-XSS and clickjacking on pages without sensitive actions
  • Missing best-practice headers without a demonstrated exploit chain
  • Reports about software versions without a working PoC
  • Vulnerabilities in third-party services we use (report to the vendor; cc us)

Safe harbor

We will not pursue legal action, including under the Computer Fraud and Abuse Act (CFAA) or equivalent statutes, against researchers who:

  • Make a good-faith effort to avoid privacy violations, data destruction, and interruption of service.
  • Only interact with accounts you own or have explicit written permission to test.
  • Do not exfiltrate any data beyond the minimum required to demonstrate impact.
  • Give us a reasonable time to remediate before any public disclosure (default: 90 days from acknowledgement, sooner by mutual agreement).
  • Do not access, modify, or destroy other users' data.
  • Do not run testing that degrades the service for other users.

If your testing follows this policy, we consider it authorised under the Computer Fraud and Abuse Act and we will work with you, not against you.

What you can expect from us

Acknowledgement of report
Within 2 business days
Triage decision (in-scope / out-of-scope / duplicate)
Within 5 business days
Status update cadence during remediation
At least every 7 days until resolved
Critical-severity remediation
Mitigation within 24 hours
High-severity remediation
Mitigation within 7 days
Medium-severity remediation
Mitigation within 30 days
Public credit (with researcher consent)
After fix is shipped

Recognition

We do not currently run a paid bounty program. Valid reports earn public credit (with your consent) on this page and a written thank-you. A formal HackerOne or Intigriti program is on the roadmap as we exit pre-launch beta.

Acknowledgements

No reports acknowledged yet. Be the first — and we will list you here with your consent.