Shall CSAF v2.0 keep the CW ID only refs or add longer descriptions?

[sthagen]

@tschmidtb51 suggests to revisit the CWE referencing in the CSAF. Should we allow place for the longer descriptions or should we stay with the CVRF v1.2 wa of clearly going for the CWE-ID matching the pattern CWE-[1-9]\d{0,5} only?

Cf. section 6.9 of CVRF v1.2

6.9 Vulnerability – CWE
Element vuln:CWE
« The vuln:CWE element MUST be present zero or one time in any vuln:Vulnerability and if present it contains the MITRE standard Common Weakness Enumeration (CWE) and this value MUST match the pattern documented in section 2.2.13 Vulnerability CWE Type Model. » [CSAF-6.9-1]
Non-normative comment:
The CWE domain value type is described in section 2.2.13 Vulnerability CWE Type Model.
Example 57:

<CWE ID="CWE-601">URL Redirection to Untrusted Site ('Open Redirect')</CWE>

Example 58:

<CWE ID="CWE-602">Client-Side Enforcement of Server-Side Security</CWE>


and the referenced model section 2.2.13 of CVRF v1.2:

2.2.13 Vulnerability CWE Type Model
Vulnerability measures given as defined in the Common Weakness Enumeration (CWE) model are expected to be in a specific form to enhance interoperability.
« Any CWE value MUST be completely matched by the following regular expression:
CWE-[1-9]\d{0,5}

» [CSAF-2.2.13-1]
Non-normative comment:
The CWE number for weakness enumeration provides improved tracking of weaknesses over time across different reporting sources. For more information about CWE cf. [CWE].
Citing from these MITRE CVE pages: 
“[CWE] is a formal list of software weakness types created to: 
-   Serve as a common language for describing software security weaknesses in architecture,
    design, or code. 
-   Serve as a standard measuring stick for software security tools targeting these weaknesses. 
- Provide a common baseline standard for weakness identification, mitigation, and 

  prevention efforts.”


[tschmidtb51]

I like the idea of having the textual description in it (mostly because I can't remember which number is which type...). However, I think we should provide a clear statement which type of description should be used.

Example: CWE-79 I've see different names for this number:

• Abbreviation: XSS
• Short: Cross-site Scripting
• Long: Improper Neutralization of Input During Web Page Generation
• Complete: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

The same happens with CWE-89, CWE-352, CWE-78, CWE-22, CWE-94, ...

Maybe, we could add a comment that the issuing authority should use the (full) name as given in the specification.

[tolim]

We should also think about allowing references to other databases that support the evaluation of vulnerabilities, such as e.g. for MITRE ATT&CK (https://attack.mitre.org/).

[sthagen]

I second the proposal of @tschmidtb51 using SHOULD for the full description.

• As a matter of fact all these condensed knowledge items (CERT IDs, CWEs) have a life cycle on their own.
• When we strongly encourage producers of SAs to use the full name as given by the authority (CWE issuer here, i.e. Mitre)
  • chances are high, that we have less variation and less false matches for consumers of these SAs.
• I also think one important advantage of CSAF schema is providing a place for the authoritative naming organization
  • this enables the exchanging communities to agree on the workflow / expectations when to follow name changes in the upstream "code" issuing organization and when to keep the naming stable.
  • similar as we have a place to note the TLP semantics source with the default of first.org's model

[santosomar]

This issue was addressed in pull request https://github.com/oasis-tcs/csaf/pull/135

[santosomar]

As discussed in the CSAF TC September 2020 monthly meeting, since this was addressed in #135 , we are closing this issue.