Based on user feedback, we're missing some fields in our ECS vulnerability fields and suggest the following additions.

• Mitigations and Solutions
  • This is a free-text field that explains to users how to fix or mitigate the problem, suggest vulnerability.mitigation?
• CWE
  • This should be an array to help future proof itself. There are reasons to use multiple CWE names. Right now the ECS definition of reference is a string, an array should be considered.
• id
  • We specify one id in ECS, which makes sense, but it's common for a CVE ID to also be mapped to various scanner IDs, I need another field, maybe alternate_id or secondary_id
• statement
  • This is different than the description. There are some CVE IDs that we will want to publish details about that include a statement such as "This library is not exposed to the external network in the container image"
• status
  • This is part of the statement data, so something could be a false positive, or future update, or whatever. It can have multiple statuses (is statuses a word?). For example something can be a false positive and also be getting a future update. Suggest vulnerability.status: open/fixed/ignored
• patch
• does a patch exist to resolve the vulnerability and is there a patch code associated. e.g. vulnerability.patch.exists (yes/no), vulnerability.patch.code (ESA-2020-13), vulnerrability.patch.name
• Dates
• vulnerability.discovered (first time detected), vulnerability.disclosed, vulnerability.closed
• Affected components: link to CPE ?
• Decomposition of vulnerability.score.temporal to include exploitability. It could be interesting to automatically calculate it based on entered elements, and share the script.
• Ownership - Might be through another field like service
• **vulnerability.category**