Founderpath Bug Bounty Program

At Founderpath, security is central to our mission of helping SaaS founders grow without dilution. We take the protection of our platform and customer data seriously and invite the security community to help us keep it safe.

Our Commitment

• We value and respect security researchers.
• We will not pursue legal action if you follow this program's rules.
• We will investigate, respond to, and remediate qualifying vulnerabilities promptly.
• With permission, we will publicly acknowledge valid contributions.

Permission Requirement ⚠️

All testing requires prior written approval from the Founderpath security team.

• You must email security@founderpath.com and receive approval before testing.
• Any unauthorized testing—even if non-destructive—may be disqualified.

Testing Environment

All testing must be performed exclusively against staging:

Prohibited:

• Testing production systems (founderpath.com or live subdomains) without explicit authorization.
• Creating fake, duplicate, or bulk accounts on production.

You may create test accounts on staging with the credentials provided after receiving permission.

Scope

In Scope

• Founderpath staging environment and APIs:
• ➡️ https://master.staging.founderpath.com

Out of Scope

• Denial-of-service (DoS) or brute-force attacks
• Social engineering against employees or customers
• Third-party services/platforms not owned by Founderpath
• Account creation abuse beyond approved test credentials

Rewards

We offer discretionary bounties based on severity, impact, and report quality (following CVSS standards).

Example tiers:

• Critical – RCE, authentication bypass, sensitive data exposure
• High – Privilege escalation, major business logic flaws
• Medium – Information disclosure with moderate impact
• Low – Best-practice gaps, minimal impact

Final decisions are at Founderpath's discretion and consider impact, exploitability, clarity, and quality of proof-of-concept.

Researcher Conduct

To maintain professionalism and effective collaboration:

• Permission first: Never test without explicit approval.
• One issue per email: Helps us triage and provide clear feedback.
• No spam: Allow at least 7 days between follow-ups unless requested otherwise.
• Be respectful: No harassment, threats, or pressure tactics (including social media shaming).
• Use approved channels only: Report via security@founderpath.com.
• Quality over quantity: Avoid automated/bulk submissions without demonstrated impact.

Violations may disqualify reports or result in removal from the program.

Response & Reward Timeline

• Initial triage: ~3 business days
• Rewards for valid reports: within 45 days of validation

Responsible Disclosure Rules

To qualify for a bounty, you must:

• Request and receive permission before testing.
• Test only on the staging environment.
• Report issues to security@founderpath.com with clear reproduction steps.
• Avoid accessing, modifying, or destroying data.
• Give Founderpath reasonable time to fix the issue before disclosure.
• Act in good faith to protect user data and system integrity.

How to Report

Send reports to security@founderpath.com.

When submitting, please:

• Use one email per issue (do not combine multiple findings).
• Include a detailed description of the vulnerability.
• Provide steps to reproduce (screenshots, PoC, or video encouraged).
• Add an impact assessment (what could realistically happen if exploited).

Non-Qualifying Issues

The following are not eligible for rewards:

• Missing security headers without exploitability
• DoS, brute-force, or rate-limiting issues
• CSRF on non-sensitive actions (e.g., logout)
• Username/email enumeration without account compromise
• Generic, missing, or verbose error messages
• Self-XSS of any kind (including requiring the victim to paste or enter malicious code/input)
• Clickjacking on non-sensitive pages
• Outdated software without a working exploit
• Vulnerabilities requiring unrealistic scenarios or physical access
• Spam or raw scanner output without proof-of-impact
• Any testing without prior permission or outside staging
• Timing attacks
• DNSSEC/DNS hardening gaps
• IP disclosure of blog servers
• WordPress user listings at /blog/wp-json/wp/v2/users
• SSRF without proven impact (e.g., only revealing internal IPs or ports)
• Reports that only show IP leakage or attempted port scanning without impact
• Open redirect without impact (no sensitive data leakage or auth bypass)
• Missing or "best practice" cookie flags (HttpOnly, Secure, SameSite) without exploit
• OPTIONS/TRACE or other non-exploitable HTTP methods enabled
• Non-exploitable CORS misconfigurations (e.g., wildcard origins on unauthenticated APIs)
• Disclosure of software/framework versions or stack banners
• Directory listing or robots.txt exposure without sensitive data
• Exposed API keys/tokens for non-sensitive services (e.g., analytics write keys, test creds)
• SPF/DKIM/DMARC misconfigurations without spoofing impact
• Password complexity or reuse policy complaints
• Autocomplete not disabled on input fields
• Social engineering or phishing attempts
• Password reset flows sending requests to trusted analytics/email providers (e.g., Postmark, SendGrid, GA) without actual token exposure to attackers

XSS Reporting Requirements

Valid XSS reports must include:

Final Notes ⚠️