My only comment here is whether or not it makes sense to have some of these be a CVSS specific attribute, particularly when I see things like score ranging from 0.0 to 10.0.

I like that this is based on the CVSS specification, what I can't tell as an outsider, what other standards can be mapped here. I'm waiting for more security folks to chime in on these to understand if this does, indeed, match expectations for how to communicate vulnerabilities via Events, etc.

@jsuereth - agreed. If using numbers this should be clearly defined (ie. CVSS).

Also, what examples of "score.version" exist? The other examples in this file assume CVSS (like score), but the classification attribute technically allows for others which may not 1:1 align.

I'd agree that there could be some challenges in having the score.version allow for other systems. Some of the fields we've got here are specific to CVSS scoring (e.g. environmental and temporal scores). If the intent is to allow for other scoring regimes (and I do think that makes sense), I'd be inclined to have a vulnerability.score value and not have the other CVSS specific items.

It's also worth noting that generally scanners can't/shouldn't provide values for environmental and temporal metrics as those require information about the working environment of the impacted system that scanners often don't have.

One example of the type of score someone might want to add is EPSS (https://www.first.org/epss/model) which expresses a score as a percentage.

@jsuereth and folks I agree with the idea that we must allow other standards to be taken into account though CVSS is probably the most widely used. We do have also notation about CVSS in comments.

I see here 2 ways of solving it

A

• introducing score.standard field, which could be used to define the actual standard.
• score.version and score.base will remain as is as common fields for all standards
• if any standard requires more fields, those could be added with sub-namespacing in the beginning such score.cvss.temporal etc
• as of now we will add only CVSS but the schema could be extended if needed

B

• use every standard under it's own sub-namespace. i.e. current score fields all go under score.cvss.*
• that way we will not have to define standard additionally.

I prefer the first option as it gives more flexibility in using any standard without updating schema, if we care only about score.base. But this will make base.score definition a bit vague, because different standards can define it using different measurements: 0.0 to 1.0, 0.0 to 10.0, 0.0 to 100.0 etc. But we can add it to the notes

Yep that sounds like a good idea to me, Option A you've outlined there should help clarify this area.

@trisch-me what I mean is that for example, in OCSF, they have Vulnerability Finding, which represents a specific vulnerability discovered in a specific resource with a timestamp, etc. This finding then references an object Vulnerability Details, which represents the vulnerability with its metadata but with no relation to an affected resource or specific instance/occurrence.

So the question, is whether we try to define here a finding or a vulnerability object.
In ECS (this definition) seems to represent just the vulnerability object and not the finding.

And why does this matter? Because if we want to define the object, then fields such as vulnerability.scanner.vendor and vulnerability.report.id might not be relevant.

hey @leykin-valeriy - thanks for detailed explanation, now I got your idea. So yes, there is a difference between use cases - dictionary of vulnerabilities and usage of them in particular scan or report. I think the ECS definition is compound. Semconv has similar approach - namespace contains all the fields and only use cases define which fields where would be used. So if someone wants to define a vulnerability object - he can use only relevant fields. The same applies for the finding.

@trisch-me could you provide a few examples for both cases, how would this schema satisfy both?

hey @leykin-valeriy sure, you just either use some of the fields or not. In Otel we have a notion of registry and use cases, where registry is just a list of all available fields where use case is concrete example - which fields are needed for this case, how they would be used, are they required or optional etc

"vulnerability": {
    "severity": "CRITICAL",
    "package": {
      "fixed_version": "1.21.11, 1.22.4",
      "name": "stdlib",
      "version": "v1.20.14"
    },
    "description": "The various Is methods (IsPrivate, IsLoopback, etc) did not work as expected for IPv4-mapped IPv6 addresses, returning false for addresses which would return true in their traditional IPv4 forms.",
    "title": "golang: net/netip: Unexpected behavior from Is methods for IPv4-mapped IPv6 addresses",
    "classification": "CVSS",
    "data_source": {
      "ID": "govulndb",
      "URL": "https://pkg.go.dev/vuln/",
      "Name": "The Go Vulnerability Database"
    },
    "reference": "https://nvd.nist.gov/vuln/detail/CVE-2024-24790",
    "score": {
      "version": "3.1",
      "base": 9.8
    },
    "report_id": 1740684490,
    "scanner": {
      "vendor": "Trivy",
      "version": "v0.35.0"
    },
    "id": "CVE-2024-24790",
    "enumeration": "CVE",
    "category": "lang-pkgs",
    "published_date": "2024-06-05T16:15:10.56Z",
    "cvss": {
      "bitnami": {
        "V3Vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
        "V3Score": 9.8
      },
      "redhat": {
        "V3Vector": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
        "V3Score": 6.7
      },
      "nvd": {
        "V3Vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
        "V3Score": 9.8
      }
    }

"wiz": {
    "vulnerability": {
      "first_detected_at": "2024-08-26T15:19:17.436Z",
      "remedation": "yum update glib2",
      "detection_method": "PACKAGE",
      "impact_score": 5.9,
      "portal_url": "https://app.wiz.io/explorer/vulnerability-findings#~(entity~(~'a9210ed6-71e2-5fc8-997c-9bcd766c7ec4*2cSECURITY_TOOL_FINDING))",
      "id": "a9210ed6-71e2-5fc8-997c-9bcd766c7ec4",
      "vendor_severity": "MEDIUM",
      "epss": {
        "severity": "CRITICAL",
        "percentile": 91.9,
        "probability": 3.8
      },
      "has_exploit": false,
      "vulnerable_asset": {
        "has_wide_internet_exposure": false,
        "has_limited_internet_exposure": false,
        "ip_addresses": [
          "18.184.18.41",
          "192.168.1.184"
        ],
        "subscription": {
          "external_id": "984186218765",
          "id": "12327889-2de2-581a-9263-24f9d2172a05"
        },
        "type": "VIRTUAL_MACHINE",
        "tags": {
          "name": " amzn2-linux-19"
        },
        "cloud": {
          "provider_url": "https://eu-central-1.console.aws.amazon.com/ec2/v2/home?region=eu-central-1#InstanceDetails:instanceId=i-00348c278384d353c"
        },
        "status": "Active"
      },
      "has_cisa_kev_exploit": false,
      "exploitability_score": 3.9,
      "status": "OPEN"
    }
  },
  "vulnerability": {
    "severity": "CRITICAL",
    "reference": "https://alas.aws.amazon.com/AL2/ALAS-2023-2107.html",
    "cwe": "CVE-2015-8390",
    "score": {
      "base": 9.8
    },
    "package": {
      "fixed_version": "2.56.1-9.amzn2.0.6",
      "name": "glib2",
      "version": "2.56.1-7.amzn2.0.1"
    },
    "description": "PCRE before 8.38 mishandles the [: and \\\\ substrings in character classes, which allows remote attackers to cause a denial of service (uninitialized memory read) or possibly have unspecified other impact via a crafted regular expression, as demonstrated by a JavaScript RegExp object encountered by Konqueror.",
    "id": "CVE-2015-8390"
  },
  "message": "The package `glib2` version `2.56.1-7.amzn2.0.1` was detected in `YUM package manager` on a machine running `Amazon 2 (Karoo)` is vulnerable to `CVE-2015-8390`, which exists in versions `< 2.56.1-9.amzn2.0.6`.\n\nThe vulnerability was found in the [Official Amazon Linux Security Advisories](https://alas.aws.amazon.com/AL2/ALAS-2023-2107.html) with vendor severity: `Medium` ([NVD](https://nvd.nist.gov/vuln/detail/CVE-2015-8390) severity: `Critical`).\n\nThe vulnerability can be remediated by updating the package to version `2.56.1-9.amzn2.0.6` or higher, using `yum update glib2`.",
  "tags": [
    "forwarded",
    "wiz-vulnerability"
  ],

here are some examples @leykin-valeriy

Would there be a future case where report would be moved to a namespace where things like url.full could be added to link to the report, or other attributes?

If this is the id of the scan, it would make sense to name scan.id

@adrielp as we have agreed during one of semconv on having id always in it's own namespace, I will update this field

Hey @leykin-valeriy, sorry for long radio-silence.
I think report is better option as it could be not only scan but some manual reviews or report might consist of multiple scans. But I can update the naming to reflect, that in simple case it could be equal to scan.id

Kind of related to the other thread we have here: do you mean by the report something OCSF would call Advisory? Which is part of Vulnerability Details.

no in this case report is just current report of found vulnerability from vulnerability management software such as elastic security agent for example. Did I got your question correctly?

I think an "alternative" would be EPSS which is 0 - 1 so this description wouldn't fit that If the classification changed.

The resolution for this field/discussion will depend on our decision on how represent different formats here

A vulnerability reported by a vendor might relate to multiple CVEs. Would it make sense to have the CVE enumeration as an array?
For example, https://security.snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-559094

good suggestion
I have misread it, it is not a a list of multiple CVEs, but the type of enumeration.

But regarding your input - we might add a new filed to represent this vulnerability in different formats
i.e. for vulnerability.id=SNYK-JAVA-COMFASTERXMLJACKSONCORE-559094 we will have field related = [CVE-xxx, CVE-xxx]. WDYT?

Ok, so this is intended to be just the type of the enumeration. Also here, it could be that the same vulnerability has multiple enumerations, right?
A more general question for this fields is, what use case does it serve?

It is a type of vulnerability so it could be for example used in metrics - breakdown severity per type or calculate number of vulnerabilities per type; it could be used for filtering or analysis

This field might include multiple values, similar to the possible multiple CVEs related to a vulnerability.

As pointed above this is direct link to the vulnerability itself

If it is a link to a vulnerability, so would you put here the reporting vendor ID as they identify the vulnerability in their products? I think a few examples of various products would explain this better.

this is a link to the vulnerability as defined in classification system depending on type of vulnerability, i.e.
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6111, https://alas.aws.amazon.com/AL2/ALAS-2023-2107.html, https://nvd.nist.gov/vuln/detail/CVE-2024-24790
I will update examples for this field

Do we always expect to have only one scoring system represented in the vulnerability?
For example, what if a vendor has its own scoring system and also adds the cvssv2 and cvssv3 info?
Should we allow to store all this information?

hey @leykin-valeriy I have provided 2 options in the comment above on how to include multiple standards into namespace, you can give you opinion there, which option do you like more (or maybe have another idea on how accomplish multiple standards)

We could come up with a namespace scan to include both the id, and the related vendor/product information.

wdyt about having both scan.id and report.id? vendor would go under scan.vendor

Report and scan are independent, it could be a situation where report consists of multiple scans or even no scans (manual audit). I propose to have them both and we could add a note for simple case where report.id == scan.id

Could you provide a few examples of how would those fields be filled in by various vendors?

The example is simple, it’s a vendor name who identified vulnerability, you can put any vendor here

   "scanner": {
      "vendor": "Trivy",
      "version": "v0.35.0"
    },

Since the terminology of base, temporal, environmental, are all from the CVSS-domain, would it make sense to put this under the corresponding namespace, for example: cvssv2 or cvssv3?

I defer this until we have a formal decision on how to support multiple domains.

My suggestion would be to go with a more generic field for score/severity (also following ideas from OCSF).

could you elaborate on generic field? what does it mean

The Qualys URL currently returns a 404, I believe this might be its current location: https://docs.qualys.com/en/vm/latest/knowledgebase/vulnerability_categories.htm

This field is relatively specific to CVSS 3.X. CVSS 4.0 was released November 2023, and temporal was simplified and renamed to threat, and supplemental metric groups were added. Should this standard be more explicit that it is designed around CVSS 3.1, or is there a way that it can be made more generic to support newer releases of these standards?

The CVSS URLs should likely be changed to point to the specific CVSS version they refer to (e.g., https://www.first.org/cvss/v3.1/specification-document)