Table of Contents
- Definitions
- Introduction
- Terms of Service and Privacy Policy Documents
- Terms of Service and Privacy Policy Change Notification
- Process for Terms of Service Enforcement
- Transparency About Terms of Service Enforcement
- Identity Policy
- Security Oversight
- Third-Party Requests for User Data
- Data Control
- Data Collection
- Minimal Data Collection
- Data Use
- Data Retention and Deletion
- Threat Notification
- User Notification About Third-Party Requests for User Information
- Transparency Reporting
- Governance
- Open Source
- Interoperability
- Ownership
- Resale
- Functionality Over Time
- Privacy by Default
- Best Build Practices
- Authentication
- Encryption
- Known Exploit Resistance
- Vulnerability Disclosure Program
- Security Over Time
- Product Stability
- Personal Safety
- Open Innovation
- Business Model
- Repair Accessibility
- Repair Penalty
- Data Benefits
Vulnerability Disclosure Program
Criteria: The company is willing and able to address reports of vulnerabilities.
See this test in action:
Indicators
- The company has a mechanism (ex: a bug bounty program) through which security researchers can submit vulnerabilities they discover.
- The company discloses the timeframe in which it will review reports of vulnerabilities.
- The company commits not to pursue legal action against security researchers.
Methodology for Assessing Each Indicator
1) The company has a mechanism (ex: a bug bounty program) through which security researchers can submit vulnerabilities they discover.
- Obtain and review a copy of the product’s terms of service, review any other online documentation available.
- Look for language describing vulnerabilities, security research, or bug bounties.
- Look for an online submission form for bug reports.
- Review aggregator websites like Bug Crowd and HackerOne to see if programs are listed for the product or service.
- If a vulnerability submission mechanism exists, mark PASS.
- If a vulnerability submission mechanism does not exist, mark FAIL.
2) The company discloses the timeframe in which it will review reports of vulnerabilities.
- Obtain and review a copy of the product’s terms of service, review any other online documentation available.
- Look for language describing vulnerabilities, security research, or bug bounties.
- Look for an online submission form for bug reports.
- Review aggregator websites like Bug Crowd and HackerOne to see if programs are listed for the product or service.
- If such a mechanism exists, review the documentation for any information about timelines, deadlines, timeframes, etc. for submission review.
- If a company timeframe for reviewing reports of vulnerabilities exists, mark PASS.
- If a company timeframe for reviewing reports of vulnerabilities does not exist, mark FAIL.
3) The company commits not to pursue legal action against security researchers.
- Obtain and review a copy of the product’s terms of service, review any other online documentation available.
- Look for language describing vulnerabilities, security research, or bug bounties.
- Specifically review any terms of use or end user agreements and look for language like “access, tamper with, probe, scan, reverse-engineer, bypass, circumvent, interfere, etc.”
- Review the documents for any mention of specific legislation that penalizes security research, for example the United States Computer Fraud and Abuse Act (CFAA), or the United States Digital Millennium Copyright Act (DMCA).
- Review the documents for any mention of specific penalties for engaging in security research, ranging from disabling of the service or product to legal action against the researcher.
- Review the documents and potential vulnerability disclosure program information, looking for an explicit commitment not to pursue legal action for security research.
- If an explicit commitment not to pursue legal action against security researchers exists, mark PASS.
- If an explicit commitment not to pursue legal action against security researchers does not exist, mark FAIL.
- If the legal documents outline specific penalties or action that may be taken against security researchers, mark FAIL.