solid / process

A definition of the culture around how decisions are made about Solid and a record of how this has changed over time
MIT License
110 stars 45 forks source link

Repo security policies #310

Open edwardsph opened 2 years ago

edwardsph commented 2 years ago

It is good practice for every repo to have a security policy (such as SECURITY.md). This is particularly important if someone wanted to find a suitable channel in which to raise a security bug or vulnerability they have identified. For some repos, I imagine this wouldn't be relevant (e.g. panel discussions) but for any code in the https://github.com/solid or https://github.com/solid-contrib organizations which may be used by the community, I would suggest this is important. The questions arising are:

  1. Do we have a single policy pointed to by all repos?
  2. What is the process around managing this communication channel? a. A concern should not be raised as a GitHub issue if it is a vulnerability - it needs to be on a private communication channel b. Either every project needs to define its own communication channel - maintenance nightmare c. Or, there is a central channel e.g. security@solidproject.org but then whoever receives this needs to be able to identify the relevant person and pass the message on in a timely manner

Whilst there is nothing else in place, in the case of the Conformance Test Harness, I added https://github.com/solid-contrib/conformance-test-harness/blob/main/SECURITY.md. This currently points to the Inrupt security policy and communication channel on the basis that Inrupt was the initial contributor of the code and is still actively maintaining it.