BILL Vulnerability Disclosure Program

Introduction

Welcome to our Vulnerability Disclosure Program! We take security seriously at BILL and are deeply appreciative of the role that security researchers play in improving the security posture of our product and platform. Please review the program details below to learn how you can play a role in keeping BILL safe and secure for our customers. We appreciate your participation!

Program highlights

Open Scope — Accepts reports for all owned assets based on impact, even if not listed in scope.

Gold Standard Safe Harbor — Adheres to Gold Standard Safe Harbor.

Coordinated Vulnerability Disclosure — Undeclared

Program rules

• Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, it may not be accepted.

• Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.

• When duplicates occur, we only triage the first report that was received (provided that it can be fully reproduced).

• Multiple vulnerabilities caused by one underlying issue will be treated as one valid report.

• Social engineering (e.g. phishing, vishing, smishing) is prohibited.

• Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.

• In order to help us identify and validate security researcher activity, please do the following:

  • Register any applicable test accounts using your @wearehackerone.com email address
  • Include the following User Agent value in any testing-related activity: UA-BugBounty-{your H1 username}

Scope

Our core products/brands include the following:

• BILL AP/AR
• BILL Spend & Expense
• Finmark
• Invoice2go

Reports affecting the assets listed on our Scope page are generally considered eligible for submission. While we are primarily interested in reports affecting our core products, issues affecting other assets that are not explicitly listed may also be accepted. Report eligibility will ultimately be decided by the BILL security team based on internal review and investigation of asset ownership and security impact.

Exclusions

We are unable to grant authorization to test third-party assets that we do not host or that are otherwise outside of our control (e.g., SaaS products or other third-party platforms/tools that we use). Reports related to such assets will only be accepted if significant security impact to BILL is demonstrated. In many cases, reporting the issue directly to the vendor would be most appropriate. That said, issues within our control to fix or mitigate are generally considered valid, including security misconfigurations and vulnerabilities/patching relating to self-hosted assets.

Unless otherwise noted, reports for the following issues in HackerOne's Core Ineligible Findings list are considered invalid for our program and will generally not be accepted except in rare circumstances demonstrating clear security impact:

Theoretical vulnerabilities that require unlikely user interaction or circumstances. For example:

• Vulnerabilities only affecting users of unsupported or End-of-life browsers or operating systems
• Broken link hijacking
• Tabnabbing
• Content spoofing and text injection issues
• Attacks requiring physical access to a device
• Self-exploitation, such as self-XSS or self-DoS (unless it can be used to attack a different account)

Theoretical vulnerabilities that do not demonstrate real-world security impact. For example:

• Clickjacking on pages with no sensitive actions
• Cross-Site Request Forgery (CSRF) on forms with no sensitive actions (e.g., Logout)
• Permissive CORS configurations without demonstrated security impact
• Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors)
• Comma Separated Values (CSV) injection
• Open redirects (unless you can demonstrate additional security impact)
• Previously known vulnerable libraries without a working Proof of Concept

Optional security hardening steps / Missing best practices. For example:

• SSL/TLS Configurations
• Lack of SSL Pinning
• Lack of jailbreak detection in mobile apps
• Cookie handling (e.g., missing HttpOnly/Secure flags)
• Missing or misconfigured Content-Security-Policy
• Optional email security features (e.g., SPF/DKIM/DMARC configurations)
• Most issues related to rate limiting

Vulnerabilities that may require hazardous testing. This type of testing must never be attempted unless explicitly authorized:

• Issues relating to excessive traffic/requests (e.g., login brute-force, DoS, DDoS)
• Any other issues where testing may affect the availability of systems
• Social engineering attacks (e.g., phishing, opening support requests)
• Attacks that are noisy to users or admins (e.g., spamming notifications or forms)
• Attacks against physical facilities

Other expectations and clarifications

• Unless otherwise noted, we adhere to HackerOne's Platform Standards and Core Clarifications.

• Reports for publicly disclosed Zero-day vulnerabilities that have had an official patch for less than one month will be accepted only on a case-by-case basis.

Response targets

BILL will make a best effort to meet the following SLAs for hackers participating in our program:

We'll try to keep you informed about our progress throughout the process.

Disclosure policy

• At this time, our program does not allow public disclosure. Please do not publish or discuss any discovered vulnerabilities (even resolved ones) outside of the program without express consent from BILL.

• Please follow HackerOne's disclosure guidelines.

Safe harbor

We adhere to HackerOne's Gold Standard Safe Harbor. Please see https://hackerone.com/bill/safe_harbor for more details.

Thank you for helping keep BILL and our users safe!