Support distinct policies: bug bounty and external vuln disclosure

[vladionescu]

Is your feature request related to a problem? Please describe.
Some organizations have both a policy on what to do when they receive a report (bug bounty policy) and a separate policy on what the org will do when the org finds vulnerabilities in external products (vuln disclosure policy).

Facebook has both of these:

• Bug bounty aka whitehat policy: https://www.facebook.com/whitehat/info/
• External vulnerability disclosure policy: https://www.facebook.com/security/advisories/Vulnerability-Disclosure-Policy

I expect this trend to continue, with more organizations developing these policies which serve different purposes.

Currently security.txt supports a Policy: field which is ambiguously defined as

This field indicates a link to where the vulnerability disclosure policy is located. This can help security researchers understand the organization's vulnerability reporting practices.

This is open to interpretation, which is versatile, but leaves both creators of security.txt and readers of the file unclear what the policy is for (inbound bug reports, or outbound bug reports).

Describe the solution you'd like
Multiple Policy: types, for example Bug Bounty Policy: and Disclosure Policy:.

Describe alternatives you've considered
The RFC seems to support repeating fields, so a solution that is compliant today could be to do:

Policy: https://www.facebook.com/whitehat/info/
Policy: https://www.facebook.com/security/advisories/Vulnerability-Disclosure-Policy

Another option is to use the field for the bug bounty policy, which is what security.txt readers are probably looking for, and mention the external disclosure policy in a comment.

The downside is that neither of these are as clear as having dedicated fields.

[cqueern]

What percent of large organizations have more than one policy such as in the example above?

[santosomar]

I agree with @cqueern . This may not apply to the majority of organizations. However, it is still an interesting suggestion. There are also companies (such as Cisco, Google, etc.) that have security research teams that also report vulnerabilities externally and have a separate policy for that function. For example:

• The traditional Security Vulnerability Policy: https://tools.cisco.com/security/center/resources/security_vulnerability_policy.html
• and Cisco Talos Vendor Vulnerability Reporting and Disclosure Policy:
  https://tools.cisco.com/security/center/resources/vendor_vulnerability_policy.html

The problem may be differentiating between both (i.e., from a tool perspective, which one should I pick for the specific use case?). This is probably where a more well defined JSON schema may be better suited for this.

[vladionescu]

An updated example: Facebook's security.txt currently has both Policy fields, with a comment explaining each one.

Contact: https://www.facebook.com/whitehat/report/
Acknowledgments: https://www.facebook.com/whitehat/thanks/
Hiring: https://www.facebook.com/careers/teams/security/

# Found a bug? Our bug bounty policy:
Policy: https://www.facebook.com/whitehat/info/

# What we do when we find a bug in another product:
Policy: https://www.facebook.com/security/advisories/Vulnerability-Disclosure-Policy

Expires: Thu, 20 May 2021 10:35:20 -0700