From 7f1b4d6273dba2c44af5b65856bbfe0a171ae303 Mon Sep 17 00:00:00 2001 From: Christian Tramnitz Date: Wed, 27 Jul 2022 14:17:49 +0200 Subject: [PATCH 1/2] introduced numbering for classification and added 3.8 make clear that accessing public information is not considered a vulnerability Signed-off-by: Christian Tramnitz --- policy.txt | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/policy.txt b/policy.txt index 23c7caa..d61ce23 100644 --- a/policy.txt +++ b/policy.txt @@ -18,22 +18,24 @@ production systems at risk. We will consider a vulnerability report most likely as relevant if it reports one of the following problems: -- The vulnerability can be used to directly access non-public - information that either reveals further security relevant problems or - contains user data, credentials, or sensitive data in general. -- The vulnerability can be used to disrupt the orderly operation of a - service (Denial of Service). -- The vulnerability can be used to manipulate data within the service. -- XSS, CSRF, RCE, authentication/authorization bypass, SQL inections, - etc are considered relevant. + 1. The vulnerability can be used to directly access non-public + information that either reveals further security relevant problems or + contains user data, credentials, or sensitive data in general. + 2. The vulnerability can be used to disrupt the orderly operation of a + service (Denial of Service). + 3. The vulnerability can be used to manipulate data within the service. + 4. XSS, CSRF, RCE, authentication/authorization bypass, SQL inections, + etc are considered relevant. We will consider a vulnerability report most likely as NOT relevant if it reports one of the following problems: -- Missing security features, for example HTTP headers, if they are not - actually preventing a vulnerability. -- Publicly accessible version strings of used software. -- Security vulnerablities that can only be used within the scope of the - used account. + 5. Missing security features, for example HTTP headers, if they are not + actually preventing a vulnerability. + 6. Publicly accessible version strings of used software. + 7. Security vulnerablities that can only be used within the scope of the + used account. + 8. Publicly available information even when retrieved over usually non- + public channels (i.e. APIs). 4. Reporting Vulnerabilities -- 2.39.2 From b2f3adb496cac87a7d9ca33207c6a908b71d3efe Mon Sep 17 00:00:00 2001 From: Christian Tramnitz Date: Fri, 29 Jul 2022 13:11:23 +0200 Subject: [PATCH 2/2] as per suggested changes from review --- policy.txt | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/policy.txt b/policy.txt index d61ce23..9e87c68 100644 --- a/policy.txt +++ b/policy.txt @@ -16,7 +16,7 @@ production systems at risk. 3. Classification of Vulnerabilities -We will consider a vulnerability report most likely as relevant if it +A) We will consider a vulnerability report most likely as relevant if it reports one of the following problems: 1. The vulnerability can be used to directly access non-public information that either reveals further security relevant problems or @@ -27,15 +27,14 @@ reports one of the following problems: 4. XSS, CSRF, RCE, authentication/authorization bypass, SQL inections, etc are considered relevant. -We will consider a vulnerability report most likely as NOT relevant if +B) We will consider a vulnerability report most likely as NOT relevant if it reports one of the following problems: - 5. Missing security features, for example HTTP headers, if they are not + 1. Missing security features, for example HTTP headers, if they are not actually preventing a vulnerability. - 6. Publicly accessible version strings of used software. - 7. Security vulnerablities that can only be used within the scope of the + 2. Publicly accessible information such as version strings of used + software and previously publicly known information in general. + 3. Security vulnerablities that can only be used within the scope of the used account. - 8. Publicly available information even when retrieved over usually non- - public channels (i.e. APIs). 4. Reporting Vulnerabilities -- 2.39.2