Introduce Hyperledger Foundation's security policy

[arsulegai]

No description provided.

[tkuhrt]

There is no red text in this document. Do we need to add formatting to allow for the red text to show? Or is there another way to represent this text in markdown?

[arsulegai]

Thanks for catching that. I made the texts highlighted. Possible options in markdown are either to highlight text, bold text or italicize text. I am choosing to highlight these sections, please suggest.

[hartm]

It looks like colored text is complicated in markdown, unfortunately.

[tkuhrt]

Agree. In other templates, I use tags.

[tkuhrt]

Suggested change

	process for reporting bugs, available <where your project has regular bug reports>.
	process for reporting bugs, available \<where your project has regular bug reports\>.

Not sure if this is the correct formatting. The portion in the brackets do not show up in the markdown.

[arsulegai]

I will make them highlighted.

[tkuhrt]

Should the see below for more github information be a link to another section in this document? Or is it referring to this link given here?

[hartm]

I think it's referring to more stuff below in the document, so yes, it should probably be a link.

[arsulegai]

This part should have been pointers suggesting the possible options to report a security issue. The first one is the security mailing list, the other option is to use github's security reporting framework (the link following the text has more information on that). This section is acting as a template for project maintainers to define what they follow in their case.

[tkuhrt]

Can we provide a link to where we are referring when we say see below?

[arsulegai]

Sure, done.

[denyeart]

OpenSSF advise at https://github.com/ossf/oss-vulnerability-guide/blob/main/maintainer-guide.md:
"If your project is on GitHub, we recommend enabling privately reporting a security vulnerability"

It appears that most if not all Hyperledger projects have private reporting enabled.

With private reporting enabled, any public user can report a security vulnerability directly to the project:
https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/privately-reporting-a-security-vulnerability

I therefore think we need some more clarification in this section. Should users "Report a security vulnerability" via GitHub, or should they use the email? Which method is preferred and why?

I think the deciding factor will be who we want to see the initial reports. Do we want it to be the specific project maintainers? Or do we want it to be a cross-project Hyperledger security team? If the former we should guide towards the GitHub security advisory reporting. If the latter we should guide towards the email. Regardless of the decision here, we should make this document clear about the preferred method. (Note, I am open to either approach).

[hartm]

I think we need to let the individual projects decide. Either one would be fine as long as it is clearly specified. Is there a reason why it should be one or the other?

Besu, for instance, has a very complicated security intake system (because they get bugs reported through a bunch of Ethereum channels).

[hartm]

I should also note: the OpenSSF vulnerability disclosure WG did review this document and didn't have a problem with this part of the text.

[denyeart]

My preference (at least for Fabric) would be to use GitHub vulnerability reporting.

• Keep everything in one place.
• Leverage the existing and well-known GitHub process flow from report through private fork through publish.
• No need to email representatives of every project for an issue with a single project.

A valid reason to use the security email would be so that Hyperledger staff can easily monitor incoming issues and help route/escalate. I thought @hartm might prefer the email for this reason.

All this being said, I'm still fine letting each project decide. I would simply ask that we make the option more clear in this section.

[arsulegai]

Comments from the TOC meeting on 3rd August 2023:

1. To define and publish guidelines for embargo list membership. I added a paragraph letting the project team to define an intake process. As TOC we could provide a reference framework. This can be the next TODO activity.
2. To suggest project teams to keep the embargo list discussions out of their regular contributor or maintainer calls. This sounds like an instruction for the project team than a policy. I added a pointer in the project incubation exit criteria.
3. I see @denyeart has already brought up the topic of GitHub security reporting vs choosing to send an email.

[swcurran]

Overall, I like the document. However, I find the mix of project guidance and the document being a template for a SECURITY.MD file project difficult. As a maintainer, I think starting the project/repository specific document from this document will be hard to maintain. I recommend either a second document that is the template for a project, or putting the template at the bottom of the document, clearly delineated from the policy text. The advantage of a separate document is that as the template evolves, it is relatively easy to compare a projects current policy from the Hyperledger Foundation’s recommend template.

I think the template itself should be relatively short, have a pointer to the Hyperledger Foundation policy, and (as is used here) the highlighting to indicate where a project must make choices in their application of the secrity policy options.

[swcurran]

Maintaining a private repo for the long term seems like a lot of overhead. Would it be better to document how to create a private repo for when it is needed? Not sure exactly how to do that, but I’m thinking this could be generic guidance, that a project could dry run and customize for their repo if deemed important to have ready ahead of time. E.g. create private fork of repo, change X, Y, Z in the pipeline to produce private artifacts.

[ryjones]

@swcurran this is done automagically by GitHub on a per-patch basis.

[denyeart]

@arsulegai I can make the edits I proposed above, but I think you first need to update the PR to "Allow edits from maintainers".

[arsulegai]

@arsulegai I can make the edits I proposed above, but I think you first need to update the PR to "Allow edits from maintainers".

Done @denyeart. I keep it disabled by default because it also shares the access to secrets.

[swcurran]

Per the discussion last week, I've created a draft PR in the Aries ACA-Py repository that I think is an appropriate basis for a "template" project SECURITY.md file. Note that in each section the discussion of options has been removed, and only the reasonable default for all projects is given. For Aries, there is no reason not to follow the defaults. As can be seen, I did leave in a description of the roles and responsibilities of the security team, along with a few other high level "security vulnerability reporting" notes.

To turn this into a template, I would:

• Convert all Hyperledger Aries references to Hyperledger PROJECT
• Add a Markdown note pointing to the policy document section that describes the alternatives to the default available to projects such that they still adhere to the policy.

For the policy document, I suggest changing the tone (where necessary) to be a policy document not a template, and having for each section of the template a discussion of the alternatives available for projects not wanting to follow the default.

[denyeart]

Per the discussion last week, I've created a draft PR in the Aries ACA-Py repository that I think is an appropriate basis for a "template" project SECURITY.md file. Note that in each section the discussion of options has been removed, and only the reasonable default for all projects is given. For Aries, there is no reason not to follow the defaults. As can be seen, I did leave in a description of the roles and responsibilities of the security team, along with a few other high level "security vulnerability reporting" notes.

To turn this into a template, I would:

• Convert all Hyperledger Aries references to Hyperledger PROJECT
• Add a Markdown note pointing to the policy document section that describes the alternatives to the default available to projects such that they still adhere to the policy.

For the policy document, I suggest changing the tone (where necessary) to be a policy document not a template, and having for each section of the template a discussion of the alternatives available for projects not wanting to follow the default.

Thanks @swcurran , I agree your Aries SECURITY.md with some of the background discussion paragraphs removed is a more clear starting point for project visitors and a good basis for the SECURITY.md template. And I agree that the additional background discussion paragraphs should be included in a separate document that is linked from the SECURITY.md template. This will make the SECURITY.md more streamlined for project visitors, and easier for project maintainers to create based on the template with a simple copy/paste.

The more streamlined SECURITY.md also resolves my prior comments about making the use of Github vulnerability reporting clear. Specifically your version of the SECURITY.md template makes it clear that there are two equal options for reporting vulnerabilities - the security email and the use of Github vulnerability reporting.

[tkuhrt]

Reworked in #167

[tkuhrt]

@arsulegai - we should get the changes here into a separate PR.