Scope Suggestions from Expert RU/OP on OpenChain Security Assurance Specification 1.0 (WG3 N2348) 2022-09-17

[shanecoughlan]

Please see attached document for scope adjustment suggestions.

Source: Expert RU/OP on OpenChain Security Assurance (WG3 N2348) 2022-09-17

Editorial Suggestions from Expert RU:OP on OpenChain Security Assurance (WG3 N2348) 2022-09-17.docx

[stephenkilbaneadi]

RU/OP01 I don’t understand the proposed change. If it’s suggesting that there should be testing for other vulnerabilities beyond published Known Vulnerabilities, that goes beyond the scope defined in the Introduction. RU/OP02 I don’t understand what’s being asked for, with the addition of “bounds of operation”.

[jthDEV]

I would agree that our current definition of "Security Testing" in 2.11 falls a bit short by just focussing on matching for Known Vulnerabilities. I would support the ambition to extend the scope of security testing towards the searching for not known vulnerabilities. Maybe we could write instead of "A process for the analysis of software (or other components) that allows for understanding their current and potential future management in the context of Known Vulnerabilities." something like: "A process for the analysis of software (or other components) that allows to identify existing vulnerabilities or the identification of Known Vulnerabilities."

[stephenkilbaneadi]

The downside of including non-Known Vulnerabilities in the process is that any such discovered vulnerabilities then need propagating along with any Known Vulnerabilities (if not resolved). Does this mean that the process would also have to encompass reporting such discoveries to the component's project, logging a CVE, etc. and effectively converting the newly-discovered vulnerability into a Known Vulnerability?

The nice thing about the current scope is that it's analogous to license compliance - use of existing components, and identification of already-recognised material relating to the component. There is no analogy for identification of non-Known Vulnerabilities in the equivalent license-compliance space.

[jthDEV]

Good points! Our goal should be secure software and hence, building trust. If I provide software, I should take care for the security testing. If I do find a vulnerability before release, I may just fix it. If a vulnerability is reported to me or appears after release, capturing a CVE and public disclosure should be my responsibility. Yes, it widens the scope a bit and it raises a question that we did not address in the OpenChain spec so far. "What if my understanding of the truth changes after having published my "Software Artefact"? But I would assume it is in our all understanding that we will generate trust only, if we have a publication requirement.

[shanecoughlan]

These comments were reviewed on our work group call on 2022-09-27 and were either included as editorial feedback or marked out of scope for OpenChain Security Assurance Specification 1.0, with a memo to return to them when working on OpenChain Security Assurance Specification 2.0.

Rationale:

==

We will hold a special call to discuss ISO/IEC WG/SC27 comments on Tuesday the 27th of September 2022 at 08:00 UTC.

We are providing some guidance on the review of these comments and suggestions.

(1) Our specification was completed after a multi-month process in March 2022, and it was ratified by our board for ISO/IEC JTC-1 PAS submission on the 14th of September 2022 (2) Therefore OpenChain Security Assurance Specification 1.0 is functionally complete (3) We should review the ISO/IEC WG comments with this perspective (4) We are looking for editorial adjusts for clarity and errors (5) We are not looking to change the scope or function of OpenChain Security Assurance Specification 1.0 or any immediate clarity / error adjusted successor (6) This is because we want to proceed with our JTC-1 PAS submission as approved by the OpenChain Governing Board (7) But we can place any comments for scope and function adjustment into a deferred status (8) And we will return to them for discussion around inclusion in OpenChain Security Assurance Specification 2.0

[shanecoughlan]

All outstanding items moved to Spec 2.0 discussion.

[shanecoughlan]

This item was addressed on call 2024-06-18. Regarded as closed as per screenshot and file attached. CLOSED- Editorial.Suggestions.from.Expert.RU.OP.on.OpenChain.Security.Assurance.WG3.N2348.2022-09-17.docx