detector: Add LayerID to detect vulns (#419)

* detector/alpine: Add LayerID to detect vulns Signed-off-by: Simarpreet Singh <[email protected]> * amazon: Add LayerID to DetectedVulns Signed-off-by: Simarpreet Singh <[email protected]> * debian: Add LayerID to DetectVulns + tests Signed-off-by: Simarpreet Singh <[email protected]> * oracle: Add LayerID to DetectVulns + tests Signed-off-by: Simarpreet Singh <[email protected]> * photon: Add LayerID to DetectVulns + tests Signed-off-by: Simarpreet Singh <[email protected]> * redhat: Add LayerID to DetectVulns + tests Signed-off-by: Simarpreet Singh <[email protected]> * suse: Add LayerID to DetectVulns + tests Signed-off-by: Simarpreet Singh <[email protected]> * ubuntu: Add LayerID to DetectVulns + tests Signed-off-by: Simarpreet Singh <[email protected]> * integration: Fix integration tests to include LayerID Signed-off-by: Simarpreet Singh <[email protected]> * fix(rpc): add layer_id * fix(rpc): insert layer_id to the struct * fix(extractor): add cleanup function * fix(library): add layer ID to detected vulnerabilities * test: update mocks * chore(mod): point to the feature branch of fanal * mod: Point to fanal/master Signed-off-by: Simarpreet Singh <[email protected]> * scan_test: Include LayerID as part of the assertion Signed-off-by: Simarpreet Singh <[email protected]> * docker_engine_test.go: Update an error message to conform with fanal/master. Signed-off-by: Simarpreet Singh <[email protected]> Co-authored-by: Teppei Fukuda <[email protected]>
aquasecurity · Mar 4, 2020 · aca31df · aca31df
1 parent 18b80e3
commit aca31df
Show file tree

Hide file tree

Showing 69 changed files with 3,565 additions and 271 deletions.
diff --git a/go.mod b/go.mod
@@ -3,7 +3,7 @@ module github.com/aquasecurity/trivy
 go 1.13
 
 require (
-	github.com/aquasecurity/fanal v0.0.0-20200221125056-947c2a5bb130
+	github.com/aquasecurity/fanal v0.0.0-20200304162519-e868f4e5037b
 	github.com/aquasecurity/go-dep-parser v0.0.0-20190819075924-ea223f0ef24b
 	github.com/aquasecurity/trivy-db v0.0.0-20191226181755-d6cabf5bc5d1
 	github.com/caarlos0/env/v6 v6.0.0

diff --git a/go.sum b/go.sum
@@ -29,8 +29,12 @@ github.com/alecthomas/units v0.0.0-20151022065526-2efee857e7cf/go.mod h1:ybxpYRF
 github.com/anmitsu/go-shlex v0.0.0-20161002113705-648efa622239/go.mod h1:2FmKhYUyUczH0OGQWaF5ceTx0UBShxjsH6f8oGKYe2c=
 github.com/apache/thrift v0.12.0/go.mod h1:cp2SuWMxlEZw2r+iP2GNCdIi4C1qmUzdZFSVb+bacwQ=
 github.com/aquasecurity/fanal v0.0.0-20190819081512-f04452b627c6/go.mod h1:enEz4FFetw4XAbkffaYgyCVq1556R9Ry+noqT4rq9BE=
-github.com/aquasecurity/fanal v0.0.0-20200221125056-947c2a5bb130 h1:OAwolcJ+dj0hDbPh/jSQlOMXxDti0LoOKvgR7e+hzVA=
-github.com/aquasecurity/fanal v0.0.0-20200221125056-947c2a5bb130/go.mod h1:yPZqe/vMN0QDXBIl3kE9s793zU9NSQuEHGWLlL85bG8=
+github.com/aquasecurity/fanal v0.0.0-20200227190905-e6c70ea926f2 h1:JMl/GoKqP3IXC+Z7AcQoyvMJHTeFK6Jlx4b4I9OBvTY=
+github.com/aquasecurity/fanal v0.0.0-20200227190905-e6c70ea926f2/go.mod h1:yPZqe/vMN0QDXBIl3kE9s793zU9NSQuEHGWLlL85bG8=
+github.com/aquasecurity/fanal v0.0.0-20200304033950-dabfae104bf6 h1:jLdxIDH7wINkQuoFhEczREmBywXuNYNYWIHPHRVf8F0=
+github.com/aquasecurity/fanal v0.0.0-20200304033950-dabfae104bf6/go.mod h1:yPZqe/vMN0QDXBIl3kE9s793zU9NSQuEHGWLlL85bG8=
+github.com/aquasecurity/fanal v0.0.0-20200304162519-e868f4e5037b h1:OCBTZZNWA+O3NI5Ba99YYAy6h3nQUfU6eEgYJt9QI6I=
+github.com/aquasecurity/fanal v0.0.0-20200304162519-e868f4e5037b/go.mod h1:yPZqe/vMN0QDXBIl3kE9s793zU9NSQuEHGWLlL85bG8=
 github.com/aquasecurity/go-dep-parser v0.0.0-20190819075924-ea223f0ef24b h1:55Ulc/gvfWm4ylhVaR7MxOwujRjA6et7KhmUbSgUFf4=
 github.com/aquasecurity/go-dep-parser v0.0.0-20190819075924-ea223f0ef24b/go.mod h1:BpNTD9vHfrejKsED9rx04ldM1WIbeyXGYxUrqTVwxVQ=
 github.com/aquasecurity/trivy v0.1.6/go.mod h1:5hobyhxLzDtxruHzPxpND2PUKOssvGUdE9BocpJUwo4=

diff --git a/integration/docker_engine_test.go b/integration/docker_engine_test.go
@@ -230,7 +230,7 @@ func TestRun_WithDockerEngine(t *testing.T) {
 			name:          "sad path, invalid image",
 			invalidImage:  true,
 			testfile:      "badimage:latest",
-			expectedError: "unable to initialize a image struct: Error reading manifest latest in docker.io/library/badimage",
+			expectedError: "unable to initialize a image struct: failed to initialize source: Error reading manifest latest in docker.io/library/badimage",
 		},
 	}
 

diff --git a/integration/integration_test.go b/integration/integration_test.go
@@ -1,4 +1,4 @@
-// +build integration
+// +rbuild integration
 
 package integration
 

diff --git a/integration/testdata/alpine-310-ignore-cveids.json.golden b/integration/testdata/alpine-310-ignore-cveids.json.golden
@@ -7,6 +7,7 @@
         "PkgName": "openssl",
         "InstalledVersion": "1.1.1c-r0",
         "FixedVersion": "1.1.1d-r0",
+        "LayerID": "sha256:03901b4a2ea88eeaad62dbe59b072b28b6efa00491962b8741081c5df50c65e0",
         "Title": "openssl: side-channel weak encryption vulnerability",
         "Description": "Normally in OpenSSL EC groups always have a co-factor present and this is used in side channel resistant code paths. However, in some cases, it is possible to construct a group using explicit parameters (instead of using a named curve). In those cases it is possible that such a group does not have the cofactor present. This can occur even where all the parameters match a known named curve. If such a curve is used then OpenSSL falls back to non-side channel resistant code paths which may result in full key recovery during an ECDSA signature operation. In order to be vulnerable an attacker would have to have the ability to time the creation of a large number of signatures where explicit parameters with no co-factor present are in use by an application using libcrypto. For the avoidance of doubt libssl is not vulnerable because explicit parameters are never used. Fixed in OpenSSL 1.1.1d (Affected 1.1.1-1.1.1c). Fixed in OpenSSL 1.1.0l (Affected 1.1.0-1.1.0k). Fixed in OpenSSL 1.0.2t (Affected 1.0.2-1.0.2s).",
         "Severity": "LOW",

diff --git a/integration/testdata/alpine-310-ignore-unfixed.json.golden b/integration/testdata/alpine-310-ignore-unfixed.json.golden
@@ -7,6 +7,7 @@
         "PkgName": "openssl",
         "InstalledVersion": "1.1.1c-r0",
         "FixedVersion": "1.1.1d-r0",
+        "LayerID": "sha256:03901b4a2ea88eeaad62dbe59b072b28b6efa00491962b8741081c5df50c65e0",
         "Title": "openssl: information disclosure in fork()",
         "Description": "OpenSSL 1.1.1 introduced a rewritten random number generator (RNG). This was intended to include protection in the event of a fork() system call in order to ensure that the parent and child processes did not share the same RNG state. However this protection was not being used in the default case. A partial mitigation for this issue is that the output from a high precision timer is mixed into the RNG state so the likelihood of a parent and child process sharing state is significantly reduced. If an application already calls OPENSSL_init_crypto() explicitly using OPENSSL_INIT_ATFORK then this problem does not occur at all. Fixed in OpenSSL 1.1.1d (Affected 1.1.1-1.1.1c).",
         "Severity": "MEDIUM",
@@ -24,6 +25,7 @@
         "PkgName": "openssl",
         "InstalledVersion": "1.1.1c-r0",
         "FixedVersion": "1.1.1d-r0",
+        "LayerID": "sha256:03901b4a2ea88eeaad62dbe59b072b28b6efa00491962b8741081c5df50c65e0",
         "Title": "openssl: information disclosure in PKCS7_dataDecode and CMS_decrypt_set1_pkey",
         "Description": "In situations where an attacker receives automated notification of the success or failure of a decryption attempt an attacker, after sending a very large number of messages to be decrypted, can recover a CMS/PKCS7 transported encryption key or decrypt any RSA encrypted message that was encrypted with the public RSA key, using a Bleichenbacher padding oracle attack. Applications are not affected if they use a certificate together with the private RSA key to the CMS_decrypt or PKCS7_decrypt functions to select the correct recipient info to decrypt. Fixed in OpenSSL 1.1.1d (Affected 1.1.1-1.1.1c). Fixed in OpenSSL 1.1.0l (Affected 1.1.0-1.1.0k). Fixed in OpenSSL 1.0.2t (Affected 1.0.2-1.0.2s).",
         "Severity": "MEDIUM",
@@ -43,6 +45,7 @@
         "PkgName": "openssl",
         "InstalledVersion": "1.1.1c-r0",
         "FixedVersion": "1.1.1d-r0",
+        "LayerID": "sha256:03901b4a2ea88eeaad62dbe59b072b28b6efa00491962b8741081c5df50c65e0",
         "Title": "openssl: side-channel weak encryption vulnerability",
         "Description": "Normally in OpenSSL EC groups always have a co-factor present and this is used in side channel resistant code paths. However, in some cases, it is possible to construct a group using explicit parameters (instead of using a named curve). In those cases it is possible that such a group does not have the cofactor present. This can occur even where all the parameters match a known named curve. If such a curve is used then OpenSSL falls back to non-side channel resistant code paths which may result in full key recovery during an ECDSA signature operation. In order to be vulnerable an attacker would have to have the ability to time the creation of a large number of signatures where explicit parameters with no co-factor present are in use by an application using libcrypto. For the avoidance of doubt libssl is not vulnerable because explicit parameters are never used. Fixed in OpenSSL 1.1.1d (Affected 1.1.1-1.1.1c). Fixed in OpenSSL 1.1.0l (Affected 1.1.0-1.1.0k). Fixed in OpenSSL 1.0.2t (Affected 1.0.2-1.0.2s).",
         "Severity": "LOW",

diff --git a/integration/testdata/alpine-310-medium-high.json.golden b/integration/testdata/alpine-310-medium-high.json.golden
@@ -7,6 +7,7 @@
         "PkgName": "openssl",
         "InstalledVersion": "1.1.1c-r0",
         "FixedVersion": "1.1.1d-r0",
+        "LayerID": "sha256:03901b4a2ea88eeaad62dbe59b072b28b6efa00491962b8741081c5df50c65e0",
         "Title": "openssl: information disclosure in fork()",
         "Description": "OpenSSL 1.1.1 introduced a rewritten random number generator (RNG). This was intended to include protection in the event of a fork() system call in order to ensure that the parent and child processes did not share the same RNG state. However this protection was not being used in the default case. A partial mitigation for this issue is that the output from a high precision timer is mixed into the RNG state so the likelihood of a parent and child process sharing state is significantly reduced. If an application already calls OPENSSL_init_crypto() explicitly using OPENSSL_INIT_ATFORK then this problem does not occur at all. Fixed in OpenSSL 1.1.1d (Affected 1.1.1-1.1.1c).",
         "Severity": "MEDIUM",
@@ -24,6 +25,7 @@
         "PkgName": "openssl",
         "InstalledVersion": "1.1.1c-r0",
         "FixedVersion": "1.1.1d-r0",
+        "LayerID": "sha256:03901b4a2ea88eeaad62dbe59b072b28b6efa00491962b8741081c5df50c65e0",
         "Title": "openssl: information disclosure in PKCS7_dataDecode and CMS_decrypt_set1_pkey",
         "Description": "In situations where an attacker receives automated notification of the success or failure of a decryption attempt an attacker, after sending a very large number of messages to be decrypted, can recover a CMS/PKCS7 transported encryption key or decrypt any RSA encrypted message that was encrypted with the public RSA key, using a Bleichenbacher padding oracle attack. Applications are not affected if they use a certificate together with the private RSA key to the CMS_decrypt or PKCS7_decrypt functions to select the correct recipient info to decrypt. Fixed in OpenSSL 1.1.1d (Affected 1.1.1-1.1.1c). Fixed in OpenSSL 1.1.0l (Affected 1.1.0-1.1.0k). Fixed in OpenSSL 1.0.2t (Affected 1.0.2-1.0.2s).",
         "Severity": "MEDIUM",

diff --git a/integration/testdata/alpine-310.json.golden b/integration/testdata/alpine-310.json.golden
@@ -7,6 +7,7 @@
         "PkgName": "openssl",
         "InstalledVersion": "1.1.1c-r0",
         "FixedVersion": "1.1.1d-r0",
+        "LayerID": "sha256:03901b4a2ea88eeaad62dbe59b072b28b6efa00491962b8741081c5df50c65e0",
         "Title": "openssl: information disclosure in fork()",
         "Description": "OpenSSL 1.1.1 introduced a rewritten random number generator (RNG). This was intended to include protection in the event of a fork() system call in order to ensure that the parent and child processes did not share the same RNG state. However this protection was not being used in the default case. A partial mitigation for this issue is that the output from a high precision timer is mixed into the RNG state so the likelihood of a parent and child process sharing state is significantly reduced. If an application already calls OPENSSL_init_crypto() explicitly using OPENSSL_INIT_ATFORK then this problem does not occur at all. Fixed in OpenSSL 1.1.1d (Affected 1.1.1-1.1.1c).",
         "Severity": "MEDIUM",
@@ -24,6 +25,7 @@
         "PkgName": "openssl",
         "InstalledVersion": "1.1.1c-r0",
         "FixedVersion": "1.1.1d-r0",
+        "LayerID": "sha256:03901b4a2ea88eeaad62dbe59b072b28b6efa00491962b8741081c5df50c65e0",
         "Title": "openssl: information disclosure in PKCS7_dataDecode and CMS_decrypt_set1_pkey",
         "Description": "In situations where an attacker receives automated notification of the success or failure of a decryption attempt an attacker, after sending a very large number of messages to be decrypted, can recover a CMS/PKCS7 transported encryption key or decrypt any RSA encrypted message that was encrypted with the public RSA key, using a Bleichenbacher padding oracle attack. Applications are not affected if they use a certificate together with the private RSA key to the CMS_decrypt or PKCS7_decrypt functions to select the correct recipient info to decrypt. Fixed in OpenSSL 1.1.1d (Affected 1.1.1-1.1.1c). Fixed in OpenSSL 1.1.0l (Affected 1.1.0-1.1.0k). Fixed in OpenSSL 1.0.2t (Affected 1.0.2-1.0.2s).",
         "Severity": "MEDIUM",
@@ -43,6 +45,7 @@
         "PkgName": "openssl",
         "InstalledVersion": "1.1.1c-r0",
         "FixedVersion": "1.1.1d-r0",
+        "LayerID": "sha256:03901b4a2ea88eeaad62dbe59b072b28b6efa00491962b8741081c5df50c65e0",
         "Title": "openssl: side-channel weak encryption vulnerability",
         "Description": "Normally in OpenSSL EC groups always have a co-factor present and this is used in side channel resistant code paths. However, in some cases, it is possible to construct a group using explicit parameters (instead of using a named curve). In those cases it is possible that such a group does not have the cofactor present. This can occur even where all the parameters match a known named curve. If such a curve is used then OpenSSL falls back to non-side channel resistant code paths which may result in full key recovery during an ECDSA signature operation. In order to be vulnerable an attacker would have to have the ability to time the creation of a large number of signatures where explicit parameters with no co-factor present are in use by an application using libcrypto. For the avoidance of doubt libssl is not vulnerable because explicit parameters are never used. Fixed in OpenSSL 1.1.1d (Affected 1.1.1-1.1.1c). Fixed in OpenSSL 1.1.0l (Affected 1.1.0-1.1.0k). Fixed in OpenSSL 1.0.2t (Affected 1.0.2-1.0.2s).",
         "Severity": "LOW",

diff --git a/integration/testdata/alpine-39.json.golden b/integration/testdata/alpine-39.json.golden
@@ -7,6 +7,7 @@
         "PkgName": "musl",
         "InstalledVersion": "1.1.20-r4",
         "FixedVersion": "1.1.20-r5",
+        "LayerID": "sha256:f1b5933fe4b5f49bbe8258745cf396afe07e625bdab3168e364daf7c956b6b81",
         "Description": "musl libc through 1.1.23 has an x87 floating-point stack adjustment imbalance, related to the math/i386/ directory. In some cases, use of this library could introduce out-of-bounds writes that are not present in an application's source code.",
         "Severity": "HIGH",
         "References": [
@@ -19,6 +20,7 @@
         "PkgName": "openssl",
         "InstalledVersion": "1.1.1b-r1",
         "FixedVersion": "1.1.1d-r0",
+        "LayerID": "sha256:f1b5933fe4b5f49bbe8258745cf396afe07e625bdab3168e364daf7c956b6b81",
         "Title": "openssl: information disclosure in fork()",
         "Description": "OpenSSL 1.1.1 introduced a rewritten random number generator (RNG). This was intended to include protection in the event of a fork() system call in order to ensure that the parent and child processes did not share the same RNG state. However this protection was not being used in the default case. A partial mitigation for this issue is that the output from a high precision timer is mixed into the RNG state so the likelihood of a parent and child process sharing state is significantly reduced. If an application already calls OPENSSL_init_crypto() explicitly using OPENSSL_INIT_ATFORK then this problem does not occur at all. Fixed in OpenSSL 1.1.1d (Affected 1.1.1-1.1.1c).",
         "Severity": "MEDIUM",
@@ -36,6 +38,7 @@
         "PkgName": "openssl",
         "InstalledVersion": "1.1.1b-r1",
         "FixedVersion": "1.1.1d-r0",
+        "LayerID": "sha256:f1b5933fe4b5f49bbe8258745cf396afe07e625bdab3168e364daf7c956b6b81",
         "Title": "openssl: information disclosure in PKCS7_dataDecode and CMS_decrypt_set1_pkey",
         "Description": "In situations where an attacker receives automated notification of the success or failure of a decryption attempt an attacker, after sending a very large number of messages to be decrypted, can recover a CMS/PKCS7 transported encryption key or decrypt any RSA encrypted message that was encrypted with the public RSA key, using a Bleichenbacher padding oracle attack. Applications are not affected if they use a certificate together with the private RSA key to the CMS_decrypt or PKCS7_decrypt functions to select the correct recipient info to decrypt. Fixed in OpenSSL 1.1.1d (Affected 1.1.1-1.1.1c). Fixed in OpenSSL 1.1.0l (Affected 1.1.0-1.1.0k). Fixed in OpenSSL 1.0.2t (Affected 1.0.2-1.0.2s).",
         "Severity": "MEDIUM",
@@ -55,6 +58,7 @@
         "PkgName": "openssl",
         "InstalledVersion": "1.1.1b-r1",
         "FixedVersion": "1.1.1d-r0",
+        "LayerID": "sha256:f1b5933fe4b5f49bbe8258745cf396afe07e625bdab3168e364daf7c956b6b81",
         "Title": "openssl: side-channel weak encryption vulnerability",
         "Description": "Normally in OpenSSL EC groups always have a co-factor present and this is used in side channel resistant code paths. However, in some cases, it is possible to construct a group using explicit parameters (instead of using a named curve). In those cases it is possible that such a group does not have the cofactor present. This can occur even where all the parameters match a known named curve. If such a curve is used then OpenSSL falls back to non-side channel resistant code paths which may result in full key recovery during an ECDSA signature operation. In order to be vulnerable an attacker would have to have the ability to time the creation of a large number of signatures where explicit parameters with no co-factor present are in use by an application using libcrypto. For the avoidance of doubt libssl is not vulnerable because explicit parameters are never used. Fixed in OpenSSL 1.1.1d (Affected 1.1.1-1.1.1c). Fixed in OpenSSL 1.1.0l (Affected 1.1.0-1.1.0k). Fixed in OpenSSL 1.0.2t (Affected 1.0.2-1.0.2s).",
         "Severity": "LOW",

diff --git a/integration/testdata/amazon-1.json.golden b/integration/testdata/amazon-1.json.golden
@@ -7,6 +7,7 @@
         "PkgName": "curl",
         "InstalledVersion": "7.61.1-11.91.amzn1",
         "FixedVersion": "7.61.1-12.93.amzn1",
+        "LayerID": "sha256:984fe1509738f6f00f34d9be7398b07ebeb8b98dda077ff6be2cdb87111b73cf",
         "Title": "curl: double free due to subsequent call of realloc()",
         "Description": "Double-free vulnerability in the FTP-kerberos code in cURL 7.52.0 to 7.65.3.",
         "Severity": "HIGH",
@@ -23,6 +24,7 @@
         "PkgName": "curl",
         "InstalledVersion": "7.61.1-11.91.amzn1",
         "FixedVersion": "7.61.1-12.93.amzn1",
+        "LayerID": "sha256:984fe1509738f6f00f34d9be7398b07ebeb8b98dda077ff6be2cdb87111b73cf",
         "Title": "curl: heap buffer overflow in function tftp_receive_packet()",
         "Description": "Heap buffer overflow in the TFTP protocol handler in cURL 7.19.4 to 7.65.3.",
         "Severity": "HIGH",
@@ -40,6 +42,7 @@
         "PkgName": "libcurl",
         "InstalledVersion": "7.61.1-11.91.amzn1",
         "FixedVersion": "7.61.1-12.93.amzn1",
+        "LayerID": "sha256:984fe1509738f6f00f34d9be7398b07ebeb8b98dda077ff6be2cdb87111b73cf",
         "Title": "curl: double free due to subsequent call of realloc()",
         "Description": "Double-free vulnerability in the FTP-kerberos code in cURL 7.52.0 to 7.65.3.",
         "Severity": "HIGH",
@@ -56,6 +59,7 @@
         "PkgName": "libcurl",
         "InstalledVersion": "7.61.1-11.91.amzn1",
         "FixedVersion": "7.61.1-12.93.amzn1",
+        "LayerID": "sha256:984fe1509738f6f00f34d9be7398b07ebeb8b98dda077ff6be2cdb87111b73cf",
         "Title": "curl: heap buffer overflow in function tftp_receive_packet()",
         "Description": "Heap buffer overflow in the TFTP protocol handler in cURL 7.19.4 to 7.65.3.",
         "Severity": "HIGH",
@@ -73,6 +77,7 @@
         "PkgName": "libnghttp2",
         "InstalledVersion": "1.21.1-1.4.amzn1",
         "FixedVersion": "1.31.1-2.5.amzn1",
+        "LayerID": "sha256:984fe1509738f6f00f34d9be7398b07ebeb8b98dda077ff6be2cdb87111b73cf",
         "Title": "HTTP/2: large amount of data requests leads to denial of service",
         "Description": "Some HTTP/2 implementations are vulnerable to window size manipulation and stream prioritization manipulation, potentially leading to a denial of service. The attacker requests a large amount of data from a specified resource over multiple streams. They manipulate window size and stream priority to force the server to queue the data in 1-byte chunks. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both.",
         "Severity": "HIGH",
@@ -101,6 +106,7 @@
         "PkgName": "libnghttp2",
         "InstalledVersion": "1.21.1-1.4.amzn1",
         "FixedVersion": "1.31.1-2.5.amzn1",
+        "LayerID": "sha256:984fe1509738f6f00f34d9be7398b07ebeb8b98dda077ff6be2cdb87111b73cf",
         "Title": "HTTP/2: flood using PRIORITY frames results in excessive resource consumption",
         "Description": "Some HTTP/2 implementations are vulnerable to resource loops, potentially leading to a denial of service. The attacker creates multiple request streams and continually shuffles the priority of the streams in a way that causes substantial churn to the priority tree. This can consume excess CPU.",
         "Severity": "HIGH",