... | @@ -28,6 +28,8 @@ Extending this to DNS and DNS servers, scoring should assume that: |
... | @@ -28,6 +28,8 @@ Extending this to DNS and DNS servers, scoring should assume that: |
|
|
|
|
|
[We could assume, as OpenSSL does, that any **feature/configuration we deem is rarely used, by definition cannot trigger a high or critical severity issue**]
|
|
[We could assume, as OpenSSL does, that any **feature/configuration we deem is rarely used, by definition cannot trigger a high or critical severity issue**]
|
|
|
|
|
|
|
|
bconry: exempting things because of our assessment of them being "rarely used" is counter to the "CVSS Base Score Measures Severity, not Risk" principle above. This document is about scoring, not about how we handle incidents. If we want to treat vulnerabilities as lower priority when we feel that the feature/configuration is "rarely used" then that is something that should go in our incident handling policy as it doesn't affect the scoring of those vulnerabilities.
|
|
|
|
|
|
## By CVSS Section
|
|
## By CVSS Section
|
|
|
|
|
|
### Attack Vector (AV)
|
|
### Attack Vector (AV)
|
... | | ... | |