Project Idea - OpenSSF Inbound Vulnerability Reporting Policy

[luigigubello]

Idea: Publish an org-level security policy for OpenSSF repositories, projects, services, and infrastructure.

Proposal

• Open Source Security Foundation Inbound Vulnerability Reporting Policy. Comments and feedback are welcome 🙌

Note. This draft policy is trying to meet the following requirements:

• Scalable for the entire organization: it should be a good enough policy for every new project, but every project can overwrite it if necessary
• Not directly dependent on a "centralized" email address: even if OpenSSF should have a generic security email address to be reached by security researchers for every kind of security report, we can use GitHub to receive security reports for every project. This should help to have a segregation of duties (maintainers cannot read others’ reports) and every project can manage its own security reports autonomously.
• Based on wg-vulnerability-disclosures template: https://github.com/ossf/oss-vulnerability-guide/blob/main/templates/security_policies/email_intake.md
• Not in conflict with other policies (e.g. Alpha/Omega policy to disclose vulnerabilities)
• Concise, short: no reason to have a long document, researchers want to just report the vulnerability.

[ran-dall]

+1 I agree with the idea of publishing an org-level security policy for OpenSSF repositories, projects, services, and infrastructure.

[ljharb]

An org-level security policy should indeed go in the org's .github repo in a SECURITY.md file.

[david-a-wheeler]

Please change the document title. This is NOT a general-purpose security policy, this is a vulnerability disclosure policy. The title of the document should reflect that, so that people understand what they're going to be reading.

[david-a-wheeler]

Proposal "Inbound Vulnerability Disclosure Policy" - that is, add "inbound" to distinguish from "outbound".

[david-a-wheeler]

For clarification: a proposed outbound vulnerability disclosure policy is here: https://github.com/ossf/wg-vulnerability-disclosures/issues/122

[luigigubello]

Hi 👋 I think we have version 1.0 ready for the final review and approval, I share the doc in OpenSSF channels #wg-vulnerability-disclosures and #tac.

Important checks before publishing the policy:

• Review and approve the In-Scope list
• Double-check if the security contact security@openssf.org exists and give access to the right people (otherwise no one can read the emails, temp owner might be someone from @ossf/wg-vulnerability-disclosures)

Next steps for v1.1

• Add a PGP key to the policy

[luigigubello]

We have temporarily removed the Safe Habor section because the Linux Foundation Counsel advised that the text as written has serious problems. Before releasing anything by making legal claims, we need a review and formal approval by Linux Foundation Counsel. In the meantime, we have edited the doc as they recommended. cc @david-a-wheeler (thank you 🙌 )

[david-a-wheeler]

@luigigubello - yes, security @ openssf.org exists. It's currently an alias to operations @ openssf.org, who can then redirect to the specific project.

[JLLeitschuh]

We have temporarily removed the Safe Habor section because the Linux Foundation Counsel advised that the text as written has serious problems.

We need to find a solution to keep this language in the document somehow.

Here are some example safe harbor policies we can pull from. If we come up with one that's international, we should work with the LF legal team to contribute it back here as well:

• https://github.com/disclose/policymaker/tree/main/static/templates
• One document: https://github.com/disclose/policymaker/blob/main/static/templates/disclose-io-safe-harbor/en-US.md

[luigigubello]

Another example of Safer Harbor could be that of U.S. Department of Agriculture. It is quite generic to work for us - we need to adapt the text a bit - and it should be written in a (U.S.-oriented probably) legal language good for LF.

[JLLeitschuh]

Solid find and a good candidate!

[NicoleSchwartz]

As per meeting May 1

Existing safe harbors in thread https://www.usda.gov/vulnerability-disclosure-policy https://github.com/disclose/policymaker/tree/main/static/templates https://github.com/disclose/policymaker/blob/main/static/templates/disclose-io-safe-harbor/en-US.md

Additional Safe Harbors https://docs.bugcrowd.com/researchers/reporting-managing-submissions/disclosure/disclose-io-and-safe-harbor/ [more we could look at those using bug crowd and their safe harbors] https://hackerone.com/security/safe_harbor?type=team https://www.microsoft.com/en-us/msrc/bounty-safe-harbor https://proton.me/security/safe-harbor https://docs.tosdr.org/sp/Security-Vulnerability-Safe-Harbor.125926922.html

And here are the common elements i see

1. setting the purpose (we want people to disclose without legal consequence because of good faith attempts)
2. terms/definitions
3. scope/limits of what is covered (boundaries)
4. promise not to go after legal action

not in all but in many

1. third party provisions
2. What they dont' want researchers to do (spamming content etc)
3. how to handle pii (report immidiatly, stop do not continue, delete all data)

Also disclose.io inccludes safe harbor in their VDP suggestions... any reason not to collab and suggest using theirs? https://disclose.io/docs/recipients/

[NicoleSchwartz]

@david-a-wheeler is there a current status or additional things to action on this?