Security policy.
This policy defines how researchers can report vulnerabilities in BleedWatch, what assets are authorized, what is out of scope, how we triage reports, and the safe-harbor conditions we apply to good-faith research.
Scope, process, and expectations.
We welcome vulnerability reports that help protect customers. The program is intentionally bounded: use your own assets, minimize impact, report promptly, and coordinate disclosure with us.
Good reports are actionable.
A report should let us reproduce the issue, understand realistic impact, identify affected systems, and prioritize a fix. Clear reproduction beats volume.
Authorized assets and roles.
These assets are in scope when tested within the boundaries below. Do not target employee accounts, customer tenants, internal infrastructure, or assets not listed here.
bleedwatch.com
Marketing, trust center, public docs, pricing, public intel, and public contact routes.
Test only public unauthenticated routes unless BleedWatch gives explicit written authorization for another path.
app.bleedwatch.com
Authenticated dashboard for tenant assets, scans, findings, integrations, billing state, and remediation workflows.
Use only accounts and tenants you own. Do not attempt to access another customer's assets, findings, scans, or integrations.
api.bleedwatch.com
Public and authenticated API routes, status wiring, scan orchestration, integrations, and callback surfaces.
Respect rate limits. Avoid destructive actions. Include endpoint, request ID, timestamps, and expected versus actual behavior.
labs.bleedwatch.com
Sister practice site for expert audits, methodology notes, booking paths, and public research references.
Report site vulnerabilities here if they affect BleedWatch customers, booking flows, data handling, or trust claims.
Activities we do not authorize.
If a test could harm users, degrade service, cross tenant boundaries, or involve a third-party system, do not perform it without written authorization.
Third-party sub-processors
Issues in Cloudflare, Hetzner, Anthropic, OpenAI, Google, Stripe, GitHub, Slack, Atlassian, Linear, ServiceNow, or other providers must be reported to those providers unless the bug is caused by BleedWatch configuration.
Social engineering
Do not phish, pretext, impersonate employees, target customers, call support, or attempt to bypass internal process through human manipulation.
Denial of service
No stress testing, volumetric scans, resource exhaustion, queue flooding, cache busting, or tests likely to degrade availability.
Physical attacks
Office access, device tampering, mail interception, employee devices, and physical infrastructure are outside this program.
Brute force / credential stuffing
Do not test stolen credentials, password spraying, MFA fatigue, credential stuffing, or high-volume login attempts.
Customer data access
Stop immediately if you encounter another customer's data. Do not download, copy, alter, disclose, or continue exploration.
Email [email protected].
Send a concise report with enough detail to reproduce the issue. Use PGP when exploit material, sensitive screenshots, or logs are included.
PGP FINGERPRINT
BLDW 2026 FPR 8E2A 91B4 7D13 C0DE 138A 4F62 9C10 7BEEFETCH PUBLIC KEY
curl https://bleedwatch.com/.well-known/security.ascReport checklist.
Affected asset and exact URL or endpoint.
Concise impact statement in business and security terms.
Step-by-step reproduction using a test account or owned asset.
Timestamps, request IDs, response headers, logs, screenshots, or videos when useful.
Exploit preconditions, affected roles, tenant boundary assumptions, and whether customer data was exposed.
Suggested remediation if you have one, including references to standards or upstream fixes.
Triage and fix targets.
These targets guide our vulnerability handling. Complex issues, coordinated customer notification, upstream dependencies, or legal constraints may change timelines, but we keep reporters updated.
| Stage | Target | Detail |
|---|---|---|
| Acknowledgment | 48 business hours | We confirm receipt, assign an internal owner, and ask clarifying questions if the report is incomplete. |
| Initial triage | 5 business days | We validate scope, impact, severity, exploitability, and whether customer notification may be required. |
| Critical fix target | 14 calendar days | Remote code execution, tenant isolation bypass, plaintext secret exposure, auth bypass, or customer data compromise. |
| High fix target | 30 calendar days | Privilege escalation, sensitive metadata exposure, durable XSS, SSRF with impact, or integration-token abuse. |
| Medium fix target | 60 calendar days | Limited-impact access control issues, non-sensitive leakage, missing hardening with realistic exploit path. |
| Low fix target | 90 calendar days | Defense-in-depth improvements, low-impact misconfigurations, headers, and informational hardening gaps. |
Rewards are transparent about what exists today.
Current rewards are swag and acknowledgment in the hall of fame. Monetary bounties are not yet funded; budget is TBD. Severity is based on realistic impact to BleedWatch or customers, not only CVSS.
| Severity | Current reward | Examples |
|---|---|---|
| Critical | Swag + priority hall-of-fame acknowledgment; monetary bounty budget TBD | Cross-tenant data access, auth bypass, RCE in production, plaintext secret persistence, KMS boundary bypass. |
| High | Swag + hall-of-fame acknowledgment; monetary bounty budget TBD | Privilege escalation, exploitable SSRF, durable XSS with sensitive action, integration-token leakage. |
| Medium | Acknowledgment when opted in | Scoped access control bypass, useful information disclosure, missing validation with practical abuse path. |
| Low | Acknowledgment at our discretion | Header hardening, low-impact configuration issues, limited metadata exposure, non-sensitive UI bugs. |
Acknowledging good-faith research.
We publish acknowledgments only when the researcher opts in, the issue is remediated, and any customer notification obligations are complete.
Researcher A
December 2025
Workflow injection vector in Pulse onboarding
Remediated before public launchResearcher B
February 2026
Over-broad integration redirect allowlist in demo tenant
Fixed and regression-testedNo legal action for good-faith research within this policy.
BleedWatch will not pursue legal action against researchers who act in good faith, stay within scope, avoid privacy harm, avoid service disruption, and follow coordinated disclosure.
Stay within the in-scope assets and your own accounts, tenants, assets, repositories, packages, domains, and integrations.
Avoid privacy harm, data destruction, service degradation, spam, social engineering, and unauthorized access to third-party systems.
Stop testing and notify us immediately if you encounter customer data, secrets, non-public reports, or another tenant's metadata.
Do not publicly disclose the vulnerability before BleedWatch confirms remediation and any required customer notifications are complete.
Use only the minimum testing needed to prove impact, and do not attempt persistence, lateral movement, or broader exploitation.
Responsible-disclosure-first culture.
BleedWatch exists to make public exposure visible before attackers can convert it into incidents. We hold ourselves to the same disclosure standard: clear scope, real SLAs, safe harbor, and public acknowledgment when researchers help us improve.
If you are unsure whether a test is allowed, ask first and wait for written confirmation. We would rather answer a precise scope question than clean up avoidable customer or availability impact.
Report a vulnerability.
Use encrypted email for sensitive payloads, include reproduction steps, and keep disclosure coordinated until the fix is deployed.