Security & Responsible Disclosure

We take the security of DeployHQ and our customers seriously.

If you believe you've found a security vulnerability, we want to hear about it. This page describes how to report issues, what's in scope, and what to expect from us.

About this programme

DeployHQ operates a Vulnerability Disclosure Programme (VDP), not a paid bug bounty. We do not pay monetary rewards. Valid, in-scope reports are acknowledged on this page and, with your permission, credited in our hall of fame below.

We ask researchers to follow responsible disclosure, test only against their own accounts, never run denial-of-service or volumetric tests, and comply with all applicable laws. The only contact for security reports is security@deployhq.com. Please do not raise security issues through support, sales, or social channels.

In scope

We are interested in application vulnerabilities on the following surfaces, where you can demonstrate concrete security impact:

  • deployhq.com and its first-party subdomains, including customer account subdomains
  • The DeployHQ web application
  • The public DeployHQ REST API
  • The Deploy Agent

Issue classes we want to hear about:

  • Authentication bypass
  • Remote code execution
  • Server-side request forgery (SSRF) that reaches internal services
  • SQL injection
  • Stored XSS with demonstrated impact
  • Insecure direct object references (IDOR) that expose data across accounts
  • Privilege escalation with a demonstrated effect
  • Broken access control on customer data

Out of scope

The following issue classes are explicitly out of scope and will not be acknowledged or credited. We have made conscious risk decisions on most of these, and reports submitted against them will be closed without further investigation.

  • Hypothetical issues with no practical impact, including anything rated P5 (Informational) under the Bugcrowd VRT
  • Open redirects without a chained higher-impact vulnerability
  • User enumeration without further impact
  • Clickjacking without a defined security risk
  • Disclosure of software version numbers
  • Automated scanner output without a working proof of concept
  • Missing SSL/TLS best practices
  • Content spoofing or text injection that can't be leveraged for XSS or sensitive data disclosure
  • Host header injection without a working proof of concept
  • Self-XSS or XSS only affecting outdated browsers
  • Denial of Service, distributed DoS, or volumetric tests of any kind
  • Attacks requiring a man-in-the-middle position
  • Use of known-vulnerable libraries without proof of exploitation
  • Missing security headers (for example CSP, HSTS, X-Frame-Options) without a demonstrated exploit
  • Rate limiting issues on non-authentication endpoints
  • Missing cookie flags on non-session cookies
  • SPF, DKIM, DMARC, or MTA-STS configuration issues
  • Logout CSRF
  • Password complexity requirements
  • Vulnerabilities in third-party services we rely on (for example Stripe, PayPal, Postal, Mixpanel, Sentry) — please report those directly to the vendor's own disclosure programme. Misconfigurations on our side of the integration (such as leaked keys, permissive CORS, or exposed webhook secrets) remain in scope.
  • Reports that appear to be AI-generated, templated, or mass-distributed across multiple programmes without specific, verified findings on our systems

Submission requirements

Every report must include the following. Reports without a working proof of concept will be closed without further investigation.

  • A clear description of the vulnerability
  • The affected URL or API endpoint
  • Step-by-step reproduction instructions
  • A working proof of concept demonstrating the issue against your own test account or environment — not a hypothesis, theoretical attack, or unverified scanner finding
  • The behaviour you observed and the behaviour you would expect instead
  • Your name or handle if you would like credit in our hall of fame

Severity classification

We assess severity using the Bugcrowd Vulnerability Rating Taxonomy. You are welcome to include your own self-assessed rating, but the final classification — including whether a report is in or out of scope — is at DeployHQ's discretion based on the demonstrated impact and our internal threat model.

Rules of engagement

  • Use a test account that you create yourself for security research — do not test against real customer accounts, data, deployments, or repositories
  • Do not access, modify, or destroy data belonging to other users
  • Do not perform DDoS, volumetric, or load tests
  • Do not use social engineering, phishing, or physical attacks against staff or customers
  • Do not publicly disclose the issue until we've had a reasonable chance to fix it
  • Do not resubmit the same finding multiple times
  • Comply with all applicable laws

If you follow these rules, we won't pursue legal action for good-faith security research.

What we will not acknowledge

We will close a report without acknowledgement or credit in the following cases:

  • Duplicates — only the first valid report for a given issue is acknowledged
  • Issues already known to us internally at the time of submission
  • Reports targeting subdomains, sandboxes, or services that we have explicitly listed as out of scope or as test infrastructure
  • Reports that breach the rules of engagement above, including testing against other tenants' data, denial-of-service activity, or social engineering

Recognition

We are grateful to the researchers who have helped keep DeployHQ secure. With your permission, we credit valid, in-scope reports in our hall of fame:

  • Sujan Thapa Magar
  • Pragati Mahajan

Contact and response times

The only contact for security reports is security@deployhq.com.

We aim to acknowledge new reports within 10 business days of receipt, and to provide a full triage response — including our scope and severity assessment — within 20 business days. Complex reports may take longer; if so, we will keep you updated.