OpenChain-Project / Security-Assurance-Specification

Other
21 stars 7 forks source link

[Improvement] Clarifying the "Get Customer" requirement in Section 3.3.2 to make the logic clearer #27

Closed shanecoughlan closed 1 year ago

shanecoughlan commented 1 year ago

Action

Changed "get Customer Agreement" to make it clearer and moved it into a more logical section of the workflow.

Old Language

(Please note this "old language" includes an improvement from Security Assurance Specification 1.1 that addresses the lack of a citation of "mitigation" in Section 3.3.2. You will find this improvement under this issue: https://github.com/OpenChain-Project/Security-Assurance-Specification/issues/26 )

3.3.2 - Security Assurance

New Language

3.3.2 - Security Assurance

Rationale

The "get Customer Agreement" was too specific and it was in the wrong place in the workflow for easy reading.

shanecoughlan commented 1 year ago

This issue is being closed as complete (for now). You can reopen it at any time to add new comments, ideas or concerns.

shanecoughlan commented 1 year ago

Further discussed on monthly North America / Europe call of 2023-03-07. Result was expanded wording of one line.

Changed:

Obtain Customer Agreement that the proposed resolution is acceptable if necessary;

To

obtain Customer Agreement that the proposed resolution is acceptable if necessary; at or above a previously determined level (i.e., all severity scores above 4.5 …).

Old Language

3.3.2 - Security Assurance

For each Open Source Software component in the bill of materials for the Supplied Software release under review; Apply method for detecting existence of Known Vulnerabilities; For each identified Known Vulnerability assign a risk/impact score; For each detection and assigned score determine and document necessary remediation or mitigation steps suitable for the use-case of the software Depending on the risk/impact score take the appropriate action (e.g., contact customers if necessary, upgrade software component, no further action, …); Obtain Customer Agreement that the proposed resolution is acceptable if necessary; If a Newly Discovered Vulnerability is present in previously distributed Supplied Software, depending on the risk/impact score take the appropriate action (e.g., contact customers if warranted); An ability to monitor Supplied Software after their release to market and to respond to Known Vulnerability or Newly Discovered Vulnerability disclosures.

New Language

3.3.2 - Security Assurance

For each Open Source Software component in the bill of materials for the Supplied Software release under review; Apply method for detecting existence of Known Vulnerabilities; For each identified Known Vulnerability assign a risk/impact score; For each detection and assigned score determine and document necessary remediation or mitigation steps suitable for the use-case of the software Depending on the risk/impact score take the appropriate action (e.g., contact customers if necessary, upgrade software component, no further action, …); Obtain Customer Agreement that the proposed resolution is acceptable if necessary; at or above a previously determined level (i.e., all severity scores above 4.5 …).; If a Newly Discovered Vulnerability is present in previously distributed Supplied Software, depending on the risk/impact score take the appropriate action (e.g., contact customers if warranted); An ability to monitor Supplied Software after their release to market and to respond to Known Vulnerability or Newly Discovered Vulnerability disclosures.