Introduce vulnerability component

[trisch-me]

Introduce a new security namespace Vulnerability.

Fields are taken from ECS Vulnerability namespace

Note: if the PR is touching an area that is not listed in the existing areas, or the area does not have sufficient domain experts coverage, the PR might be tagged as experts needed and move slowly until experts are identified.

Merge requirement checklist

• [x] CONTRIBUTING.md guidelines followed.
• [x] Change log entry added, according to the guidelines in When to add a changelog entry.
  • If your PR does not need a change log, start the PR title with [chore]
• [ ] schema-next.yaml updated with changes to existing conventions.

[adrielp]

@trisch-me Following up on this PR from this weeks SemConv meeting.

In practice I've noticed that vendors don't always support the convention 1:1. In the OTEL collector we've had to do mappings of attributes for metrics. We currently define a git.repository.cve.count metric. This metric will probably eventually change to vcs.repository.cve.count (or maybe just cve.count with attribute of vcs.repository.url.full). cve.severity is the attribute I'm referring to that doesn't always map. We enum the attribute, but have to remap the value here.

Just wanted to provide this information for additional context. Love seeing these pr's come up.

[github-actions[bot]]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[sachinmalanki]

Hi, is this PR good now? Can we have this merged I'm looking to add vulnerabilities metric.

[leykin-valeriy]

@trisch-me, a more generic question to this pull request:

• Since there are the OCSF standard security findings of vulnerability type, would it make sense to closer align to it?
• What benefits would this new standard have in addition to the OCSF?
• Can we state better the expected use cases of this object?

[ms-jcorley]

I agree with the comment below: Are there good reasons not to align with the OCSF schema?

@trisch-me, a more generic question to this pull request:

• Since there are the OCSF standard security findings of vulnerability type, would it make sense to closer align to it?
• What benefits would this new standard have in addition to the OCSF?
• Can we state better the expected use cases of this object?

[trisch-me]

@leykin-valeriy @ms-jcorley

I am adding this namespace as a part of donation process. We previously discussed the idea of collaborating with OCSF on creating a unified schema about a year ago, but unfortunately, no agreement was reached at that time.

OCSF has a different structure in general, and aligning the two without further discussions on the fields would be challenging. However, if those working on OCSF are interested in adding or updating fields in this namespace to suit their needs, we would be happy to collaborate and explore possible solutions together.

[trask]

We previously discussed the idea of collaborating with OCSF on creating a unified schema about a year ago, but unfortunately, no agreement was reached at that time.

I'm interested to learn more, especially since OCSF is also under the Linux Foundation now. I've added the topic to Monday's semconv SIG agendra.

[trask]

I'm interested to learn more, especially since OCSF is also under the Linux Foundation now. I've added the topic to Monday's semconv SIG agendra.

pushing this agenda topic to the April 28 meeting

[trask]

pushing this agenda topic to the April 28 meeting

pushing (again) to the May 5 meeting

[adrielp]

pushing this agenda topic to the April 28 meeting

pushing (again) to the May 5 meeting

Any objections to starting the conversation on the 28th and continuing the conversation on the 5th? The sooner we can at least start having the conversations the sooner we can make progress on these things.