Add triage entry to specific situations where vulnerability not appliable

[Helio Chissini de Castro]

Describe the improvement

There's should be a process to determine if a reported vulnerability affects the component used
< refer to section 3.3.2 >

Additional context

• Behavior is not presented in different platfoms / libraries
• CVE reporting where there are disputing over, presume no action need to be taken by user CVE-2005-1754
• Library affects specific operating system, i.e. Linux but not affect similar Unix system i.e AIX

Expected behavior

• No user action needed on remediation and mitigation
• Document the evidence and research performed in order to make this determination

[JTH]

Section 3.3.2 currently is the only section in the document not carrying an introductory sentence. Following our conversation form WG meeting, I would suggest to rephrase the paragraph as follows:

3.3.2 Security Assurance
For each (Open Source) Software component in the bill of materials for the Supplied Software released to the market along the whole lifespan of this software, it should be assured that a method for detecting existence of Known Vulnerabilities is continuously applied and that:

• For each identified Known Vulnerability or Newly Discovered Vulnerability disclosures, whether by internal review procedures or external notification, an analysis is performed to determine the impact on the use of the Supplied Software;
• The result of this analysis will be documented and/ or should result in an assignment of a risk/impact score;
• For each assigned score / identified Known Vulnerability appropriate measures to remediate or mitigate the finding will be initiated;
• A procedure ensures that customers will be notified about the measures taken, or to take from their side, to prevent damage from this Known Vulnerability or Newly Discovered Vulnerability disclosures, even in case the vulnerability has been identified as not impacting the Supplied Software (negative confirmation)

---

I have been able to reduce the amount of requirements with the intro sentence. Please check, whether it still is comprehensive.

[Shane Coughlan]

As per Jan:

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

Proposed New Language

3.3.2 Security Assurance
For each (Open Source) Software component in the bill of materials for the Supplied Software released to the market along the whole lifespan of this software, it should be assured that a method for detecting existence of Known Vulnerabilities is continuously applied and that:

• For each identified Known Vulnerability or Newly Discovered Vulnerability disclosures, whether by internal review procedures or external notification, an analysis is performed to determine the impact on the use of the Supplied Software;
• The result of this analysis will be documented and/ or should result in an assignment of a risk/impact score;
• For each assigned score / identified Known Vulnerability appropriate measures to remediate or mitigate the finding will be initiated;
• A procedure ensures that customers will be notified about the measures taken, or to take from their side, to prevent damage from this Known Vulnerability or Newly Discovered Vulnerability disclosures, even in case the vulnerability has been identified as not impacting the Supplied Software (negative confirmation)
  ...

[Shane Coughlan]

Total New Language Proposed

3.3.2 Security Assurance

For each (Open Source) Software component in the bill of materials for the Supplied Software released to the market along the whole lifespan of this software, it should be assured that a method for detecting existence of Known Vulnerabilities is continuously applied and that:

• For each identified Known Vulnerability or Newly Discovered Vulnerability disclosures, whether by internal review procedures or external notification, an analysis is performed to determine the impact on the use of the Supplied Software;
• The result of this analysis will be documented and/ or should result in an assignment of a risk/impact score;
  For each assigned score / identified Known Vulnerability appropriate measures to remediate or mitigate the finding will be initiated;
• A procedure ensures that customers will be notified about the measures taken, or to take from their side, to prevent damage from this Known Vulnerability or Newly Discovered Vulnerability disclosures, even in case the vulnerability has been identified as not impacting the Supplied Software (negative confirmation)
• 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.

[Shane Coughlan]

Call on 2023-03-21 concluded that @jthDEV's proposal made the workflow clearer, and the combined text captures more of the intended outcome. That said, we want to review the language to make it simpler or clearer if possible.

[Dr-wood]

3.3.2 - Security Assurance
For each (Open Source) Software component in the development cycle, a method (process using necessary tools), should be in continuously in use to detect, identify, and document the existence of Known Vulnerabilities to facilitate:

• Creation of an action or task assigned to the developer or security personnel as applicable;
• For each identified Known Vulnerability assign a risk/impact score using a valid process such as NIST SP 800-30;
• For each detection and assigned score determine and document necessary remediation or mitigation steps suitable for the use-case of the software;
• Depending on risk/impact score take the appropriate action (i.e. contact customer, upgrade software, no further action) ;
• If required, obtain Customer Agreement that the proposed resolution is acceptable if necessary; at or above a previously determined level (e.g. severity scores above 4.5....);
• If a Newly Discovered Vulnerability is present in previously distributed Software, depending on the risk/impact score take the appropriate action (e.g., contact customer if applicable);

[Mary Hardy]

In our monthly meeting, we discussed a couple of things to keep in mind for this one: 1) focus on an introductory sentence for Section 3.3.2 - Security Assurance and 2) minimal changes to the section bullets, where possible. Something like:

"A process shall exist to detect, identify, and document the existence of Known Vulnerabilities in each Open Source Software component on the Software Bill of Materials (SBOM) for the Supplied Software."

And delete the first bullet.

[Dr-wood]

@copernicat Your proposal would look more like this:
3.3.2 - Security Assurance
"A process shall exist to detect, identify, and document the existence of Known Vulnerabilities in each Open Source Software component on the Software Bill of Materials (SBOM) for the Supplied Software."

• --------This line deleted-----
  

• For each identified Known Vulnerability assign a risk/impact score using a valid process such as NIST SP 800-30;
  

• For each detection and assigned score determine and document necessary remediation or mitigation steps suitable for the use-case of the software;
  

• Depending on risk/impact score take the appropriate action (i.e. contact customer, upgrade software, no further action) ;
  

• If required, obtain Customer Agreement that the proposed resolution is acceptable if necessary; at or above a previously determined level (e.g. severity scores above 4.5....);
  

• If a Newly Discovered Vulnerability is present in previously distributed Software, depending on the risk/impact score take the appropriate action (e.g., contact customer if applicable);
  

[Shane Coughlan]

This looks good to me, in that it seems to cover the same ground, reduce complexity, and align with other parts of the spec.

[Dr-wood]

I agree @shanecoughlan @heliocastro @copernicat , if this looks good to you lets close this open issue, integrate the new section, and move on.

[Shane Coughlan]

Proposal on 2024-04-02 to use the new language to replace old. Issue being closed with this actioned.

== 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; 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.

== New Language ==

3.3.2 - Security Assurance
A process shall exist to detect, identify, and document the existence of Known Vulnerabilities in each Open Source Software component on the Software Bill of Materials (SBOM) for the Supplied Software.

• For each identified Known Vulnerability assign a risk/impact score using a valid process such as NIST SP 800-30;
• For each detection and assigned score determine and document necessary remediation or mitigation steps suitable for the use-case of the software;
• Depending on risk/impact score take the appropriate action (i.e. contact customer, upgrade software, no further action) ;
• If required, obtain Customer Agreement that the proposed resolution is acceptable if necessary; at or above a previously determined level (e.g. severity scores above 4.5....);
• If a Newly Discovered Vulnerability is present in previously distributed Software, depending on the risk/impact score take the appropriate action (e.g., contact customer if applicable).