Simple OSS Project Security Policy

[SecurityCRob]

I'd like to use this issue to talk about what elements we'd like to see in a security policy that could be easily used by open source projects and maintainers that describes their security practices.

At a minimum it would be useful to have the following things documented so that collaborators, researchers, and consumers can understand how the project works with security:

• Description of how the project manages security flaws
• Method to report vulnerabilities that is confidential
• Expectations and timeline that Finder/Researchers should have when reporting a flaw

What other items should we put into a template?

[JasonKeirstead]

If applicable to the project - what is in-scope of the policy, and what is out-of-scope of the policy.

[david-a-wheeler]

Method to report vulnerabilities that is confidential

Not all projects agree that vulnerabilities should be reported confidentially. So "Method to report vulnerabilities" should briefly note that.

There should be some easily-selected options for reporting. For private reporting, an easy approach is to provide email addresses with services that support STARTTLS or MTA-STS based encryption (such as GMail and runbox). We hope that GitHub will someday support private reporting of vulnerabilities to projects (GItHub supports private discussions, but not private reporting).

Under "expectations", note that "We (the OSS project) will gladly give you (the vulnerability reporter) public credit for the report unless you request otherwise". Many people fail to give a simple thank you with credit, which is weird because it costs nothing & that failure can be deeply offending.

You might want to look at some existing policies. Here is GitLab's: https://about.gitlab.com/security/disclosure/

[lirantal]

Hi folks, I started watching this repository a bit, hoping to find some time to get involved :-)

Noticing this issue, and wanted to raise that we have done something simlilar in the Node.js Security working group with proposing that projects adapt a SECURITY.md and proposed a policy such as this one: https://github.com/nodejs/security-wg/blob/master/processes/responsible_disclosure_template.md

[msmeissn]

Yes, first things that come to mind is:

• clearly and easily be found means of contacting for security issues
  • email / bugform / whatever
  • direct link to encryption keys for emails if desired

What i found useful as i created SECURITY.md for libexif to set expectations, what actually are considered valid security issues. ( see here https://github.com/libexif/libexif/blob/master/SECURITY.md ) (toplevel SECURITY.md is actually known and linked by github even)

Perhaps from our side we can offer same simple or more complex examples as cross reference to chose from.

[lirantal]

Agree on the criteria of what is a valid security issue. Maybe we can even provide a closed list of those, as probably most (?) maintainers won't know what to write.

[annabellegoth2boss]

A link to the SECURITY.md templates we created for the CVD for OSS guide. Ended up making a couple depending on what intake method projects were going to use.

[ericcornelissen]

I wanted to bring Trewaters/security-README to this group's attention as it relates to SECURITY.md templates.

[infojg9]

how about basic cybersecurity hygienes?

1. https://www.usaa.com/.well-known/security.txt ?
2. https://www.nist.gov/system/files/documents/2021/07/13/Developer%20Verification%20of%20Software.pdf
3. https://github.com/usnistgov/IoT-Device-Cybersecurity-Requirement-Catalogs/blob/main/_Nontechnical/manufacturer_documentation.md
4. https://github.com/usnistgov/IoT-Device-Cybersecurity-Requirement-Catalogs/blob/main/_Technical/security.md

[david-a-wheeler]

@infojg9 - that would be an increase in scope for this project from just reporting & processing vulnerability repotrs. It's not wrong but we should discuss it first. If we do add this, there are many other things that could be added, including the CII Best Practices badge, Scorecard, Allstar, and SLSA.

[infojg9]

@david-a-wheeler - indeed, just not very sure, at the time of solarwinds/colonial/codecov/eo-14028, without any clearly defined and enforced project security policy, "reporting & processing" would be like another chicken and egg situation, as many cots/gots likely unaware of security policies for "reporting & processing" at the very first place, e.g: https://www.politico.com/news/2021/08/17/blackberry-qnx-vulnerability-hackers-505649.

[EdOverflow]

Please feel free to use material from https://hackerone.com/ed and https://hackerone.com/liberapay's security policies. Both are CVD policies for (F)OSS projects.