Comments on the proposed Security Assurance Specification

[jeff-luszcz]

Issue with the pdf document: for some reason (MacOS 12.6) I was not able to select text, search for text, have the document spoken aloud or select text for copying. I'm on a brand new machine so it may be a software issue on my side, but might be something with the PDF. Tried viewing in Preview, Books and Safari

Section 2.12: A structured format such as SPDX ISO/IEC 5962:2021 that allows the exchange of information for a software package, including associated license, copyright information and Known Vulnerabilities.

(I don't think the current release of SPDX supports cve info yet, and we should support SBOM formats that don't embed vulnerability or copyright info)

I'd suggest changing this section to: A structured format such as SPDX ISO/IEC 5962:2021 that allows the exchange of information for a software package, including name and version and optionally including associated license, copyright information and Known Vulnerabilities information.

3.2.1 - Access

Should this section allow for a "non-response" from the organization? e.g. Should anyone be able to make a request for information about the vulnerability status of an organizations application and be guaranteed an answer?

I'd want to be sure I'm not setting my organization up for a Denial of Service Attack by having to respond to every request for information, especially from non-users or non-customers. Possibly change 3.2.1.2 text from 3.2.1.2: An internal documented procedure exists for responding to third party Known Vulnerability inquiries to 3.2.1.2: An internal documented procedure exists for responding to third party Known Vulnerability inquiries (as warranted)

[jthDEV]

I can confirm the issues you mention concerning copying etc. But on the similar system configuration. And it s specific to the PDF provided here. However, the md file is available and does not suffer from these issues.

Thank you for your suggestion, I would support your recommendation on 2.12. It helps to clarify the expectations.

[jthDEV]

Concerning your thoughts on 3.2.1.2 I would take your question as an indicator to sharpen the intro further. From my point of view It is just about the definition of the procedure (your org will act) whether your organisation will respond with an answer or not is not a requirement at all.

However, we might be more specific on the purpose, e.g instead "Maintain a process to effectively respond to Known Vulnerability external inquiries. Publicly identify a means by which a third party can inquire about a Known Vulnerability with respect to a given software offering."

"To allow external communication concerning vulnerabilities, maintain a process to effectively respond to external Known Vulnerability inquiries. Publicly identify a means by which a third party can learn or inquire about a Known Vulnerability with respect to a given software offering."

And in addition change 3.2.1.2 from "3.2.1.2: An internal documented procedure exists for responding to third party Known Vulnerability inquiries" to "3.2.1.2: An internal documented procedure exists for responsible handling of third party Known Vulnerability inquiries" Then we do neither require a public response, nor do we need to enter the warranty turf (which might be very product specific)

[shanecoughlan]

Comments on Section 2.12 reviewed and included via work group call on 2022-09-27.

Comments on 3.2.1 deferred to next review call due to time limitations.

[shanecoughlan]

3.2.1 discussed. In this revision of the spec we leave it ambiguous (and therefore implicitly self-determined) how entities will elect to respond or not to security questions.

We decided to swing back and add (or not add) explicit guidance as part of the Spec 2.0 discussion.

[shanecoughlan]

3.2.1 further discussed on Monthly Call 2022-11-15 as we opened new editing cycle for Gen 2 Security Assurance Specification (for the Security Assurance Specification 2.0).

There was a proposed change: 3.2.1.2: An internal documented procedure exists for responding to third party Known Vulnerability inquiries to 3.2.1.2: An internal documented procedure exists for responding to third party Known Vulnerability inquiries (as warranted)

Justification was to avoid Denial of Service attacks by non-users, non-customers etc. overwhelming a team.

The parties on the call saw this as a valid concern but raised three counter-concerns that lead to the ultimate decision to leave the language ambiguous. They were:

1. Challenge of fast moving legislation
2. Issue of potentially introducing loopholes to hinder useful disclosure
3. Suitability of commercial contracts to address the concern

This issue is being closed as an outcome of this call but can be reopened if parties disagree with the decision reached.