[RFC] Stage 1- Introducing new fields in ECS Vulnerability fields by smriti0321 · Pull Request #2449 · elastic/ecs

smriti0321 · 2025-02-14T14:13:13Z

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 · 2025-04-01T00:14:55Z

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 · 2025-04-01T00:13:15Z

+      level: extended
+      type: keyword
+      description: >
+        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.


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 · 2025-04-01T00:20:25Z

+      level: extended
+      type: keyword
+      description: >
+        Title/Name/Short Description for vulnerability, to be used in flyout and dashboards.


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 · 2025-04-01T00:21:02Z

+      level: extended
+      type: text
+      description: >
+        Explains how to fix or mitigate the problem, could be used to store resolution from the scanner vendor or document mitigation in place.


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 · 2025-04-01T00:23:39Z

+      level: extended
+      type: date
+      description: >
+        The “published” field indicates the date when information about a specific vulnerability was publicly disclosed or made available. It represents the moment when details about the vulnerability were shared with the security community, vendors, and the public. This field helps security professionals track the timeline of vulnerability awareness, in ISO 8601 format - YYYY-MM-DD.


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 · 2025-04-01T00:25:26Z

+      level: extended
+      type: keyword
+      description: >
+        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.


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 · 2025-04-01T00:29:32Z

+      level: extended
+      type: date
+      description: >
+        Last time a vulnerability was found on the asset, in ISO 8601 format: 2016-05-23T08:05:34.853Z.


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 · 2025-04-01T00:46:05Z

+      level: extended
+      type: date
+      description: >
+        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.


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 · 2025-04-01T00:48:50Z

+      level: extended
+      type: keyword
+      description: >
+        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.


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 · 2025-04-01T00:50:59Z

+      description: >
+        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.
+
+    - name: age


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 · 2025-04-01T00:53:36Z

+          level: extended
+          type: text
+          description: >
+            Name of the patch.


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

github-actions · 2025-06-01T00:44:03Z

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!

github-actions · 2026-03-19T00:49:25Z

This PR has been automatically closed due to inactivity. If you'd like to
continue working on this, feel free to re-open the PR or create a new one.

Thank you for your contribution!

PR for stage 1 of new Vulnerability fields

f70cece

smriti0321 requested a review from a team as a code owner February 14, 2025 14:13

smriti0321 requested review from mjwolf and trisch-me February 14, 2025 14:13

smriti0321 self-assigned this Feb 14, 2025

smriti0321 changed the title ~~PR for stage 1 of new Vulnerability fields~~ [RFC] Stage 1- Introducing new fields in ECS for Vulnerability fields Feb 14, 2025

smriti0321 changed the title ~~[RFC] Stage 1- Introducing new fields in ECS for Vulnerability fields~~ [RFC] Stage 1- Introducing new fields in ECS Vulnerability fields Feb 14, 2025

andrewkroh requested a review from Copilot April 1, 2025 00:15

Copilot AI reviewed Apr 1, 2025

View reviewed changes

andrewkroh reviewed Apr 1, 2025

View reviewed changes

github-actions Bot added the stale Stale issues and pull requests label Jun 1, 2025

navnit-elastic mentioned this pull request Aug 4, 2025

[cloud_security_posture] vulnerability.published_date is keyword while all other packages use date elastic/integrations#14538

Closed

github-actions Bot closed this Mar 19, 2026

	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.

	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.

	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.

	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.

	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.

	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.

	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.

Conversation

smriti0321 commented Feb 14, 2025

Uh oh!

andrewkroh commented Apr 1, 2025

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Uh oh!

andrewkroh left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Jun 1, 2025

Uh oh!

github-actions Bot commented Mar 19, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants