Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling vulnerabilities with multiple CWEs #530

Open
achrinza opened this issue May 13, 2022 · 4 comments
Open

Handling vulnerabilities with multiple CWEs #530

achrinza opened this issue May 13, 2022 · 4 comments
Assignees
Labels
csaf 2.1 csaf 2.1 work editor-revision already worked on in the editor revision

Comments

@achrinza
Copy link

achrinza commented May 13, 2022

Currently CSAF 2.0 only permits a single CWE entry per-vulnerability. This is in contrast to vulnerability databases (e.g. GitHub Advisory Database, OSV) where each entry represents a single vulnerability, of which permits attaching multiple CWEs.

Although #385 clarifies that historically, the CVRF spec did not permit mulitple CWEs on paper, I was not able to find the rationale for the design choice.

In these cases, what would be the best way to represent multiple CWEs for a vulnerability?

Edit:
The CVE Schema GitHub issue for reference: CVEProject/cve-schema#171

@santosomar
Copy link
Contributor

This is a great point. In some cases multiple CWEs could be applied to a single vulnerability. There was no true rationale behind this in CVRF. This could be a good suggestion and enhancement for the next version of CSAF. Thank you 🙏

@tschmidtb51
Copy link
Contributor

I always thought a vulnerability should have only one CWE ("the one that matches best") 🤔
Some additional questions:

  • What does CVE allow/require?
  • Could somebody provide a real-world example where I would assign more than one CWE?

@rselph-tibco
Copy link

CVE allows multiple CWEs under the container's "problemTypes" array.

@santosomar
Copy link
Contributor

santosomar commented Nov 29, 2023

Thomas Schmidt proposed a motion, as detailed in this OASIS mailing list archive, to change the schema in CSAF 2.1 to allow multiple CWE entries per vulnerabilities. Stefan Hagen seconded the motion. There were no discussions or objections raised, and consequently, the motion was automatically passed on November 1, 2023, at 20:00 UTC.

@tschmidtb51 tschmidtb51 added csaf 2.1 csaf 2.1 work and removed question email To be sent via email to the TC tc-discussion-needed labels Nov 29, 2023
tschmidtb51 added a commit to tschmidtb51/csaf that referenced this issue May 25, 2024
- addresses parts of oasis-tcs#530
- wrap CWE into a list to allow multiple CWEs per vulnerability
tschmidtb51 added a commit to tschmidtb51/csaf that referenced this issue May 25, 2024
- addresses parts of oasis-tcs#530, oasis-tcs#154
- adopt prose to reflect schema
- remove conversion rule for CVRF CSAF converter
- reorder CVRF CSAF converter rules regarding CWEs
- clarify warning regarding conversion of CWE category and view
tschmidtb51 added a commit to tschmidtb51/csaf that referenced this issue May 25, 2024
- addresses parts of oasis-tcs#530
- adopt test 6.1.11 to reflect schema
tschmidtb51 added a commit to tschmidtb51/csaf that referenced this issue May 25, 2024
- addresses parts of oasis-tcs#530
- adopt examples to reflect schema
- adopt testdata to reflect schema
tschmidtb51 added a commit to tschmidtb51/csaf that referenced this issue May 25, 2024
- addresses parts of oasis-tcs#530, oasis-tcs#660
- add `/vulnerabilities[]/cwes[]/version` to guidance on size
- add `/vulnerabilities[]/cwes` to guidance on size
- adopt pathes to match schema
@tschmidtb51 tschmidtb51 added the editor-revision already worked on in the editor revision label May 25, 2024
tschmidtb51 added a commit to tschmidtb51/csaf that referenced this issue May 25, 2024
- addresses parts of oasis-tcs#530
- add invalid example for 6.1.11
- add valid example for 6.1.11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
csaf 2.1 csaf 2.1 work editor-revision already worked on in the editor revision
Projects
None yet
Development

No branches or pull requests

5 participants