Various comments

[stephenkilbaneadi]

SMK01: Introduction, 3rd para, "being in the" should be "being used in the".

SMK02: Introduction, 4th para, spec refers to "companies". Should the spec refer to "companies" or "organisations", as a general matter?

SMK03: Introduction, 6th para: Section 1 also defines the scope, as well as the introduction.

SMK04: 1: Scope: in "comprised of Open Source Software", would "comprised of" be better as "incorporating", "including", etc? Not all the Supplied Software may be OSS, but the definition of OSS in this doc does merely say "subject to a license", so does actually work).

SMK05: 2.1: Component Records: Should it use "should" or "shall"?

SMK06: 2.12: SBOM: This paragraph describes the format, but the SBOM is information in that format. Also, does SPDX 5962:2021 allow exchange of Known Vulnerabilities?

SMK07: 2.14: Verification Materials, and elsewhere: Earlier parts of this doc have dropped "reference" from "this reference specification", but here and later, "reference" persists. Should be consistent. Here, it could simply be "this specification".

SMK08: 3.1: Program foundation and later: Inconsistent capitalisation of section titles.

SMK09: 3.1.1: Policy: Could remove "your" from "your Supplied Software" - we don't have second-person pronouns elsewhere.

SMK10: ibid: Should there be 3.1.1.3 a documented review process?

SMK11: 3.1.2: Competence and later: Should be consistent on punctuation for bulleted lists, in terms of whether each item ends in semi-colon/period, and whether the penultimate item ends "; and".

SMK12: ibid: Perhaps add "ensure Program Participants" to "Where applicable, take actions to acquire the necessary competence"?

SMK13: 3.1.3: Awareness: Participants are supposed to be aware of "Relevant Program objectives" - does the Program have objectives? They're not formally called out anywhere.

SMK14: 3.1.5: Standard Practice Implementation: "Organization" is capitalised, but is not a defined term in section 2. (It could be, though - see SMK02).

SMK15: ibid: I don't know what the first bullet is asking for, but it seems to be beyond the scope of just dealing with Known Vulnerabilities.

SMK15: ibid: 5th bullet: is "post release" referring to the release of the Supplied Software, or Known Vulnerabilities?

SMK16: 3.2.2: Effectively Resourced: Indent bullets 3 and 4.

SMK17: 3.1.1: Software Bill of Material: Should be "Materials".

SMK18: 3.3.1.1: I think "for" should be removed, in "for all Open Source Software".

SMK19: 3.3.2 Security assurance: Indent bullets 2-6.

SMK20: 3.3.2 Security Assurance and 2.2 Customer Agreement: Really? Get Customer Agreement? That seems implausible.

SMK21: ibid: "Software Component" is capitalised, but is not a defined term.

SMK22: ibid: does "their release to market" refer to the Supplied Software or the Software Components?

SMK23: ibid: Bullet the Rationale, or break into paras?

SMK24: 3.4.2.1: The 18m time limit is now consistent with the range of time limits given in 3.4.2.

[shanecoughlan]

Comments SMK01 to SMK012 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.

We need to review the following comments in the next call:

SMK13: 3.1.3: Awareness: Participants are supposed to be aware of "Relevant Program objectives" - does the Program have objectives? They're not formally called out anywhere.

SMK14: 3.1.5: Standard Practice Implementation: "Organization" is capitalised, but is not a defined term in section 2. (It could be, though - see SMK02).

SMK15: ibid: I don't know what the first bullet is asking for, but it seems to be beyond the scope of just dealing with Known Vulnerabilities.

SMK15: ibid: 5th bullet: is "post release" referring to the release of the Supplied Software, or Known Vulnerabilities?

SMK16: 3.2.2: Effectively Resourced: Indent bullets 3 and 4.

SMK17: 3.1.1: Software Bill of Material: Should be "Materials".

SMK18: 3.3.1.1: I think "for" should be removed, in "for all Open Source Software".

SMK19: 3.3.2 Security assurance: Indent bullets 2-6.

SMK20: 3.3.2 Security Assurance and 2.2 Customer Agreement: Really? Get Customer Agreement? That seems implausible.

SMK21: ibid: "Software Component" is capitalised, but is not a defined term.

SMK22: ibid: does "their release to market" refer to the Supplied Software or the Software Components?

SMK23: ibid: Bullet the Rationale, or break into paras?

SMK24: 3.4.2.1: The 18m time limit is now consistent with the range of time limits given in 3.4.2.

[stephenkilbaneadi]

My previous comment included both editorial and scope comments. Apologies for mixing them.

Editorial comments:

SMK01: [DONE] Introduction, 3rd para, "being in the" should be "being used in the".

SMK02: [PARTIALLY DONE] Introduction, 4th para, spec refers to "companies". Should the spec refer to "companies" or "organisations", as a general matter?

SMK03: [IGNORE] Introduction, 6th para: Section 1 also defines the scope, as well as the introduction.

SMK06: [DONE] 2.12: SBOM: This paragraph describes the format, but the SBOM is information in that format. Also, does SPDX 5962:2021 allow exchange of Known Vulnerabilities?

SMK07: [DONE] 2.14: Verification Materials, and elsewhere: Earlier parts of this doc have dropped "reference" from "this reference specification", but here and later, "reference" persists. Should be consistent. Here, it could simply be "this specification".

SMK08: [PARTIALLY DONE] 3.1: Program foundation and later: Inconsistent capitalisation of section titles.

SMK09: [DONE] 3.1.1: Policy: Could remove "your" from "your Supplied Software" - we don't have second-person pronouns elsewhere.

SMK11: [TBD] 3.1.2: Competence and later: Should be consistent on punctuation for bulleted lists, in terms of whether each item ends in semi-colon/period, and whether the penultimate item ends "; and".

SMK12: [DONE] ibid: Perhaps add "ensure Program Participants" to "Where applicable, take actions to acquire the necessary competence"?

SMK14: 3.1.5: Standard Practice Implementation: "Organization" is capitalised, but is not a defined term in section 2. (It could be, though - see SMK02).

SMK15: ibid: 5th bullet: is "post release" referring to the release of the Supplied Software, or Known Vulnerabilities?

SMK16: 3.2.2: Effectively Resourced: Indent bullets 3 and 4.

SMK17: 3.1.1: Software Bill of Material: Should be "Materials".

SMK18: 3.3.1.1: I think "for" should be removed, in "for all Open Source Software".

SMK19: 3.3.2 Security assurance: Indent bullets 2-6.

SMK21: ibid: "Software Component" is capitalised, but is not a defined term.

SMK22: ibid: does "their release to market" refer to the Supplied Software or the Software Components?

SMK23: ibid: Bullet the Rationale, or break into paras?

[stephenkilbaneadi]

Scope comments:

SMK04: 1: in "comprised of Open Source Software", would "comprised of" be better as "incorporating", "including", etc? Not all the Supplied Software may be OSS, but the definition of OSS in this doc does merely say "subject to a license", so does actually work).

SMK10: 3.1.1: Should there be 3.1.1.3 a documented review process?

SMK13: 3.1.3: Awareness: Participants are supposed to be aware of "Relevant Program objectives" - does the Program have objectives? They're not formally called out anywhere.

SMK15: 3.1.5: Standard Practice Implementation: I don't know what the first bullet is asking for, but it seems to be beyond the scope of just dealing with Known Vulnerabilities.

SMK20: 3.3.2 Security Assurance and 2.2 Customer Agreement: Really? Get Customer Agreement? That seems implausible.

SMK24: 3.4.2.1: The 18m time limit is now consistent with the range of time limits given in 3.4.2.

[shanecoughlan]

All editorial item reviewed and either included or deferred. These items are closed. We will swing back to scope items for Spec 2.0.

[shanecoughlan]

Talked on Monthly call 2022-11-01 around:

SMK20: 3.3.2 Security Assurance and 2.2 Customer Agreement: Really? Get Customer Agreement? That seems implausible.

3.3.2 needs to be explored to see if it is a little difficult in certain markets and if we could or should explore options such as referring to public security stances as a requirement instead.

[shanecoughlan]

The Scope Suggestions have been moved into individual issues to make editing easier. See below for map to current locations:

SMK04: 1: in "comprised of Open Source Software", would "comprised of" be better as "incorporating", "including", etc? Not all the Supplied Software may be OSS, but the definition of OSS in this doc does merely say "subject to a license", so does actually work). https://github.com/OpenChain-Project/Security-Assurance-Specification/issues/12

SMK10: 3.1.1: Should there be 3.1.1.3 a documented review process? https://github.com/OpenChain-Project/Security-Assurance-Specification/issues/13

SMK13: 3.1.3: Awareness: Participants are supposed to be aware of "Relevant Program objectives" - does the Program have objectives? They're not formally called out anywhere. https://github.com/OpenChain-Project/Security-Assurance-Specification/issues/14

SMK15: 3.1.5: Standard Practice Implementation: I don't know what the first bullet is asking for, but it seems to be beyond the scope of just dealing with Known Vulnerabilities. https://github.com/OpenChain-Project/Security-Assurance-Specification/issues/15

SMK20: 3.3.2 Security Assurance and 2.2 Customer Agreement: Really? Get Customer Agreement? That seems implausible. https://github.com/OpenChain-Project/Security-Assurance-Specification/issues/16

SMK24: 3.4.2.1: The 18m time limit is now consistent with the range of time limits given in 3.4.2. https://github.com/OpenChain-Project/Security-Assurance-Specification/issues/17