Introduce Hyperledger Foundation's security policy

[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.

[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