[RFC] Stage 1- Introducing new fields in ECS Vulnerability fields

[smriti0321]

• Have you signed the contributor license agreement?
• Have you followed the contributor guidelines?
• For proposing substantial changes or additions to the schema, have you reviewed the RFC process?
• If submitting code/script changes, have you verified all tests pass locally using make test?
• If submitting schema/fields updates, have you generated new artifacts by running make and committed those changes?
• Is your pull request against main? Unless there is a good reason otherwise, we prefer pull requests against main and will backport as needed.
• Have you added an entry to the CHANGELOG.next.md?

[andrewkroh]

I'm going to try a copilot review on this PR...

[Copilot]

Pull Request Overview

This pull request introduces a new vulnerability schema to support tracking and mitigating vulnerabilities in assets.

• Defines new vulnerability fields including vendor.id, title, mitigation, published, and several date fields.
• Adds a nested group for patch details with fields for existence, name, and code.
• Introduces an "age" field for dynamically calculating vulnerability age.

Comments suppressed due to low confidence (1)

rfcs/text/0045/vulnerbility.yml:1

• The file name 'vulnerbility.yml' appears to be misspelled; consider renaming it to 'vulnerability.yml' for clarity.

+- name: vulnerability

[andrewkroh]

I'm not a SME in vulnerability data, but I left some comments that hopefully improve the descriptions.

[andrewkroh]

Suggested change

	A vulnerability doesn't necessarily have a CVE associated with it. It makes sense to separate vulnerability ID (like CVEs) to the vendor/detection IDs.
	A vulnerability doesn't necessarily have a CVE associated with it. It makes sense to separate vulnerability ID (like CVEs) from the vendor/detection IDs.

[andrewkroh]

Suggested change

	Title/Name/Short Description for vulnerability, to be used in flyout and dashboards.
	Title, name, and short description for the vulnerability, to be used in flyout and dashboards.

I think an example: would be helpful here too.

[andrewkroh]

Suggested change

	Explains how to fix or mitigate the problem, could be used to store resolution from the scanner vendor or document mitigation in place.
	Explains how to fix or mitigate the problem. Could be used to store the resolution from the scanner vendor or document the mitigation in place.

[andrewkroh]

I don't think "in ISO 8601 format - YYYY-MM-DD" is needed given that we have said it is a type: date field.

[andrewkroh]

Suggested change

	The status field helps security teams track vulnerabilities, prioritize actions, and communicate their progress effectively. Examples: open/ignored/patched/mitigated/false_positive/risk_accepted/reopened.
	The status field helps security teams track vulnerabilities, prioritize actions, and communicate their progress effectively. Examples: open, ignored, patched, mitigated, false_positive, risk_accepted, reopened.

[andrewkroh]

Suggested change

	Last time a vulnerability was found on the asset, in ISO 8601 format: 2016-05-23T08:05:34.853Z.
	The last time a vulnerability was found on the asset.

[andrewkroh]

Suggested change

	Last time a scan was performed on the asset. It's important as some companies are scanning on a quarterly basis. If last_found and last_scanned are close, it means it's still an active vulnerability, in ISO 8601 format: 2016-05-23T08:05:34.853Z.
	The last time a scan was performed on the asset. If last_found and last_scanned are close, it suggests that the vulnerability is likely still active.

I'm not sure about added value of "It's important as some companies are scanning on a quarterly basis." section. Perhaps the additional context could be phrased in terms of it be in important indicator of staleness.

[andrewkroh]

Suggested change

	It's extremely important to be able to deduplicate different scans. It's often that we have different scanners showing the same vulnerability on the same asset.
	It's extremely important to be able to deduplicate different scans. It's common to have different scanners showing the same vulnerability on the same asset.

[andrewkroh]

Given that this is derived data, I think we should omit this field. Users of the data can calculate it on their own via the various means you mentioned if they need it.

[andrewkroh]

Can you give an example of a named patch? I'm not sure follow what would go into this field.

[github-actions]

Hi!

We just realized that we haven't looked into this PR in a while. We're
sorry!

We're labeling this PR as Stale to make it hit our filters and
make sure we get back to it as soon as possible. In the meantime, it'd
be extremely helpful if you could take a look at it as well and confirm its
relevance. A simple comment with a nice emoji will be enough :+1.

Thank you for your contribution!