Introduce vulnerability component #1295
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,22 @@ | ||
| # Use this changelog template to create an entry for release notes. | ||
| # | ||
| # If your change doesn't affect end users you should instead start | ||
| # your pull request title with [chore] or use the "Skip Changelog" label. | ||
|
|
||
| # One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix' | ||
| change_type: new_component | ||
|
|
||
| # The name of the area of concern in the attributes-registry, (e.g. http, cloud, db) | ||
| component: vulnerability | ||
|
|
||
| # A brief description of the change. Surround your text with quotes ("") if it needs to start with a backtick (`). | ||
| note: Introduce `vulnerability.*` attribute namespace | ||
|
|
||
| # Mandatory: One or more tracking issues related to the change. You can use the PR number here if no issue exists. | ||
| # The values here must be integers. | ||
| issues: [1295] | ||
|
|
||
| # (Optional) One or more lines of additional information to render under the primary note. | ||
| # These lines will be padded with 2 spaces and then inserted directly into the document. | ||
| # Use pipe (|) for multiline entries. | ||
| subtext: |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,43 @@ | ||
| <!--- Hugo front matter used to generate the website version of this page: | ||
| ---> | ||
|
|
||
| <!-- NOTE: THIS FILE IS AUTOGENERATED. DO NOT EDIT BY HAND. --> | ||
| <!-- see templates/registry/markdown/attribute_namespace.md.j2 --> | ||
|
|
||
| # Vulnerability | ||
|
|
||
| ## Vulnerability | ||
|
|
||
| The vulnerability fields describe information about a vulnerability. | ||
|
|
||
| | Attribute | Type | Description | Examples | Stability | | ||
| | ----------------------------------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- | ---------------------------------------------------------------- | | ||
| | `vulnerability.category` | string[] | The type of system or architecture that the vulnerability affects. These may be platform-specific (for example, Debian or SUSE) or general (for example, Database or Firewall). For example [Qualys vulnerability categories](https://qualysguard.qualys.com/qwebhelp/fo_portal/knowledgebase/vulnerability_categories.htm). | `["Firewall"]` |  | | ||
| | `vulnerability.classification` | string | The classification of the vulnerability scoring system. For example, [CVSS](https://www.first.org/cvss/specification-document). | `CVSS` |  | | ||
| | `vulnerability.description` | string | The description of the vulnerability that provides additional context of the vulnerability. For example [Common Vulnerabilities and Exposure CVE description](https://www.cve.org/ResourcesSupport/FAQs). | `A vulnerability in the firewall allows an attacker to bypass security controls.` |  | | ||
| | `vulnerability.enumeration` | string | The type of identifier used for this vulnerability. For example, [Common Vulnerabilities and Exposure CVE enumeration](https://www.cve.org/ResourcesSupport/FAQs). | `CVE` |  | | ||
| | `vulnerability.id` | string | The number portion of a vulnerability entry. It includes a unique identification number for the vulnerability. For example, [Common Vulnerabilities and Exposure CVE ID](https://www.cve.org/ResourcesSupport/FAQs). | `CVE-2021-44228` |  | | ||
| | `vulnerability.reference` | string | A resource that provides additional information, context, and mitigations for the identified vulnerability. | `https://www.cve.org/CVERecord?id=CVE-2021-44228` |  | | ||
| | `vulnerability.report_id` | string | The report or scan identification number. | `20191018.0001` |  | | ||
| | `vulnerability.scanner.vendor` | string | The name of the scanner vendor that identified the vulnerability. | `Tenable` |  | | ||
| | `vulnerability.score.base` | double | The base score of the vulnerability. [1] | `7.5` |  | | ||
| | `vulnerability.score.environmental` | double | The environmental score of the vulnerability. [2] | `7.5` |  | | ||
| | `vulnerability.score.temporal` | double | The temporal score of the vulnerability. [3] | `7.5` |  | | ||
| | `vulnerability.score.version` | string | The version of the scoring system used to calculate the vulnerability score. | `3.0` |  | | ||
| | `vulnerability.severity` | string | The severity of the vulnerability. | `Low`; `Medium`; `High` |  | | ||
|
|
||
| **[1]:** Scores can range from 0.0 to 10.0, with 10.0 being the most severe. Base scores cover an assessment for exploitability metrics (attack vector, complexity, privileges, and user interaction), impact metrics (confidentiality, integrity, and availability), and scope. For example, [CVSS](https://www.first.org/cvss/specification-document). | ||
| The National Vulnerability Database (NVD) provides qualitative severity rankings of "Low", "Medium", and "High" for CVSS v2.0 base score ranges in addition to the severity ratings for CVSS v3.0 as they are defined in the CVSS v3.0 specification. | ||
|
|
||
| **[2]:** Scores can range from 0.0 to 10.0, with 10.0 being the most severe. Environmental scores cover an assessment for any modified base metrics, confidentiality, integrity, and availability requirements. For example, [CVSS](https://www.first.org/cvss/specification-document). | ||
|
|
||
| **[3]:** Scores can range from 0.0 to 10.0, with 10.0 being the most severe. Temporal scores cover an assessment for code maturity, remediation level, and confidence. For example, [CVSS](https://www.first.org/cvss/specification-document). | ||
|
|
||
| `vulnerability.severity` has the following list of well-known values. If one of them applies, then the respective value MUST be used; otherwise, a custom value MAY be used. | ||
|
|
||
| | Value | Description | Stability | | ||
| | ---------- | ------------------------------ | ---------------------------------------------------------------- | | ||
| | `Critical` | Critical severity (9.0 - 10.0) |  | | ||
| | `High` | High severity (7.0 - 8.9) |  | | ||
| | `Low` | Low severity (0.1 - 3.9) |  | | ||
| | `Medium` | Medium severity (4.0 - 6.9) |  | | ||
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -0,0 +1,120 @@ | ||||||
| groups: | ||||||
| - id: registry.vulnerability | ||||||
| prefix: vulnerability | ||||||
| type: attribute_group | ||||||
| display_name: Vulnerability | ||||||
| brief: > | ||||||
| The vulnerability fields describe information about a vulnerability. | ||||||
| attributes: | ||||||
| - id: category | ||||||
| type: string[] | ||||||
| stability: experimental | ||||||
| brief: > | ||||||
| The type of system or architecture that the vulnerability affects. These may be platform-specific | ||||||
| (for example, Debian or SUSE) or general (for example, Database or Firewall). For example | ||||||
| [Qualys vulnerability categories](https://qualysguard.qualys.com/qwebhelp/fo_portal/knowledgebase/vulnerability_categories.htm). | ||||||
| examples: ['Firewall'] | ||||||
| - id: classification | ||||||
| type: string | ||||||
| stability: experimental | ||||||
| brief: > | ||||||
| The classification of the vulnerability scoring system. For example, [CVSS](https://www.first.org/cvss/specification-document). | ||||||
| examples: ['CVSS'] | ||||||
| - id: description | ||||||
| type: string | ||||||
| stability: experimental | ||||||
| brief: > | ||||||
| The description of the vulnerability that provides additional context of the vulnerability. | ||||||
| For example [Common Vulnerabilities and Exposure CVE description](https://www.cve.org/ResourcesSupport/FAQs). | ||||||
| examples: ['A vulnerability in the firewall allows an attacker to bypass security controls.'] | ||||||
| - id: enumeration | ||||||
| type: string | ||||||
|
There was a problem hiding this comment. A vulnerability reported by a vendor might relate to multiple CVEs. Would it make sense to have the CVE enumeration as an array? |
||||||
| stability: experimental | ||||||
| brief: > | ||||||
| The type of identifier used for this vulnerability. For example, [Common Vulnerabilities and Exposure CVE enumeration](https://www.cve.org/ResourcesSupport/FAQs). | ||||||
| examples: ['CVE'] | ||||||
| - id: id | ||||||
| type: string | ||||||
| stability: experimental | ||||||
| brief: > | ||||||
| The number portion of a vulnerability entry. It includes a unique identification number for the vulnerability. | ||||||
| For example, [Common Vulnerabilities and Exposure CVE ID](https://www.cve.org/ResourcesSupport/FAQs). | ||||||
| examples: ['CVE-2021-44228'] | ||||||
| - id: reference | ||||||
| type: string | ||||||
|
There was a problem hiding this comment. This field might include multiple values, similar to the possible multiple CVEs related to a vulnerability. |
||||||
| stability: experimental | ||||||
| brief: > | ||||||
| A resource that provides additional information, context, and mitigations for the identified vulnerability. | ||||||
| examples: ['https://www.cve.org/CVERecord?id=CVE-2021-44228'] | ||||||
| - id: report_id | ||||||
|
There was a problem hiding this comment. Would there be a future case where There was a problem hiding this comment. If this is the id of the scan, it would make sense to name There was a problem hiding this comment. @adrielp as we have agreed during one of semconv on having |
||||||
| type: string | ||||||
| stability: experimental | ||||||
| brief: > | ||||||
| The report or scan identification number. | ||||||
| examples: ['20191018.0001'] | ||||||
| - id: scanner.vendor | ||||||
|
There was a problem hiding this comment. We could come up with a namespace |
||||||
| type: string | ||||||
| stability: experimental | ||||||
| brief: > | ||||||
| The name of the scanner vendor that identified the vulnerability. | ||||||
| examples: ['Tenable'] | ||||||
| - id: score.base | ||||||
|
There was a problem hiding this comment. 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? |
||||||
| type: double | ||||||
| stability: experimental | ||||||
| brief: > | ||||||
| The base score of the vulnerability. | ||||||
| note: > | ||||||
| Scores can range from 0.0 to 10.0, with 10.0 being the most severe. Base scores cover an assessment | ||||||
|
There was a problem hiding this comment. I think an "alternative" would be EPSS which is |
||||||
| for exploitability metrics (attack vector, complexity, privileges, and user interaction), | ||||||
| impact metrics (confidentiality, integrity, and availability), and scope. For example, [CVSS](https://www.first.org/cvss/specification-document). | ||||||
|
|
||||||
| The National Vulnerability Database (NVD) provides qualitative severity rankings of "Low", "Medium", | ||||||
| and "High" for CVSS v2.0 base score ranges in addition to the severity ratings for CVSS v3.0 as they are | ||||||
| defined in the CVSS v3.0 specification. | ||||||
| examples: [7.5] | ||||||
| - id: score.environmental | ||||||
| type: double | ||||||
| stability: experimental | ||||||
| brief: > | ||||||
| The environmental score of the vulnerability. | ||||||
| note: > | ||||||
| Scores can range from 0.0 to 10.0, with 10.0 being the most severe. Environmental scores cover an assessment | ||||||
| for any modified base metrics, confidentiality, integrity, and availability requirements. For example, [CVSS](https://www.first.org/cvss/specification-document). | ||||||
| examples: [7.5] | ||||||
| - id: score.temporal | ||||||
| type: double | ||||||
| stability: experimental | ||||||
| brief: > | ||||||
| The temporal score of the vulnerability. | ||||||
| note: > | ||||||
| Scores can range from 0.0 to 10.0, with 10.0 being the most severe. Temporal scores cover an assessment for | ||||||
| code maturity, remediation level, and confidence. For example, [CVSS](https://www.first.org/cvss/specification-document). | ||||||
| examples: [7.5] | ||||||
| - id: score.version | ||||||
|
There was a problem hiding this comment. Do we always expect to have only one scoring system represented in the vulnerability? There was a problem hiding this comment. 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) |
||||||
| type: string | ||||||
| stability: experimental | ||||||
| brief: > | ||||||
| The version of the scoring system used to calculate the vulnerability score. | ||||||
| examples: ['3.0'] | ||||||
| - id: severity | ||||||
| brief: > | ||||||
| The severity of the vulnerability. | ||||||
| type: | ||||||
| members: | ||||||
| - id: low | ||||||
| value: 'Low' | ||||||
| brief: 'Low severity (0.1 - 3.9)' | ||||||
|
There was a problem hiding this comment.
Suggested change
There was a problem hiding this comment. in the latest cvss versions (3.x, 4.x) severity is scored from 0.1, because 0.0 means no vulnerability |
||||||
| stability: experimental | ||||||
| - id: medium | ||||||
| value: 'Medium' | ||||||
| brief: 'Medium severity (4.0 - 6.9)' | ||||||
| stability: experimental | ||||||
| - id: high | ||||||
| value: 'High' | ||||||
| brief: 'High severity (7.0 - 8.9)' | ||||||
| stability: experimental | ||||||
| - id: critical | ||||||
| value: 'Critical' | ||||||
| brief: 'Critical severity (9.0 - 10.0)' | ||||||
| stability: experimental | ||||||
| stability: experimental | ||||||
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My only comment here is whether or not it makes sense to have some of these be a
CVSSspecific 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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd agree that there could be some challenges in having the
score.versionallow 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 avulnerability.scorevalue 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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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
score.standardfield, which could be used to define the actual standard.score.versionandscore.basewill remain as is as common fields for all standardsscore.cvss.temporaletcB
scorefields all go underscore.cvss.*standardadditionally.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 makebase.scoredefinition 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 notesThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep that sounds like a good idea to me, Option A you've outlined there should help clarify this area.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe there are two things that need to be considered:
A decision to make: Are we defining a vulnerability object that can later be referenced from a finding, or are we defining a vulnerability finding reported by a vendor on a vulnerable artifact?
Depending on the purpose, it could go in one or another direction.
For 1. - we would need to have a separate severity/score for the finding, and potentially an array of scores defined by various standards.
For 2. - we would still need a score used by the vendor as the base score, and potentially an array of additional scores that were considered by that vendor.
See this example of Snyk:
Here is an example of a possible OCSF representation generated from a vulnerability finding: