Closed heliocastro closed 5 months ago
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:
I have been able to reduce the amount of requirements with the intro sentence. Please check, whether it still is comprehensive.
As per Jan:
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:
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:
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.
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:
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.
@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 looks good to me, in that it seems to cover the same ground, reduce complexity, and align with other parts of the spec.
I agree @shanecoughlan @heliocastro @copernicat , if this looks good to you lets close this open issue, integrate the new section, and move on.
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
== 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.
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
Expected behavior