OpenChain-Project / Security-Assurance-Specification

Other
21 stars 7 forks source link

[Improvement] Comments on the Known Vulnerability in the proposed Security Assurance Specification #19

Closed szlin closed 1 year ago

szlin commented 1 year ago

Section 3.2.1 describes the process to respond to Known Vulnerability external inquiries that shall be maintained, as shown below.

3.2.1 - Access Maintain a process to effectively respond to Known Vulnerability external inquiries. Publicly identify a means by which a third party can inquire about a Known Vulnerability with respect to a given software offering.

In my opinion, the response is one of the decisions. Therefore, I think the word "receive" is more suitable being the first step, as used in "ETSI TR 103 838 Cyber Security; Guide to Coordinated Vulnerability Disclosure [1]". In addition, it provides more flexibility to the organization to evaluate whether to respond.

[1] https://www.etsi.org/deliver/etsi_tr/103800_103899/103838/01.01.01_60/tr_103838v010101p.pdf

Aside from that, it typically has the below steps in handling vulnerability in many cybersecurity standards.

  1. Receiving notifications of security-related issues
  2. Reviewing security related issues
  3. Assessing security related issues
  4. Addressing security related issues
  5. Disclosing Security Related issues
  6. Periodic review of security defect management practice

Does it make sense to add to the current specification?

shanecoughlan commented 1 year ago

Conversation on 2023-03-07 indicated that our interpretation of the suggestion could veer into "how" rather than staying with "what", so we need to think carefully here about what we add or not.

stephenkilbaneadi commented 1 year ago

I would prefer to leave 3.2.1 as it is. "Receive" would make sense if the first sentence talks about the mechanism, but the first sentence is talking about a process, and the outcome of that process is a response - whatever that response happens to be. The point here is that there's a means for external parties to raise concerns, and that there's a process to respond to those raised concerns.

shanecoughlan commented 1 year ago

Note from Chris Wood based on discussion 2023-03-07: I think after listening to the discussion that it [this section?] should be to establish a 2 way communication to receive input of a vulnerability in your software as well as responding to known vulnerabilities (remediation) in the software that you create.

Note from Mary Wang based on discussion 2023-03-07: Each company will define their own process for how to respond to it.

shanecoughlan commented 1 year ago

On the call 2023-03-21 we revisited the first part of SZ's suggestion for changing respond to receive, and concluded that the language needed improvement to deal with both, but with making response optional. The conclusion is that we will use the following language (pending overall spec improvements to language clarity and compactness):

3.2.1 - Access Maintain a process to effectively respond to Known Vulnerability external inquiries. Publicly identify a means by which a third party can inquire about a Known Vulnerability with respect to a given software offering.

3.2.1 - Access Maintain a process to effectively receive and if appropriate respond to Known Vulnerability external inquiries. Publicly identify a means by which a third party can inquire about a Known Vulnerability with respect to a given software offering.