Deduplicate findings, closed findings getting deleted

[italvi]

Be informative Using the dedupe function a closed finding, which is the original one, gets closed even though I would expect that it is preserved.

Steps to reproduce Steps to reproduce the behavior:

1. Go to system settings and activate deduplication and the deletion of those when there are more than 2
2. Use the following json as an example and import the scan results as type "Jfrog Xray Unified Scan": { "total_rows" : 4, "rows" : [ { "cves": [ { "cve": "CVE-2021-44228", "cvss_v3_score": 10 } ], "cvss3_max_score": 10, "summary": "Apache Log4j2 \u003c=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. In previous releases (\u003e2.10) this behavior can be mitigated by setting system property "log4j2.formatMsgNoLookups" to ?true? or by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-.jar org/apache/logging/log4j/core/lookup/JndiLookup.class). Java 8u121 (see https://www.oracle.com/java/technologies/javase/8u121-relnotes.html) protects against remote code execution by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".", "severity": "Critical", "severity_source": "CVSS V3 from NVD", "vulnerable_component": "gav://org.apache.logging.log4j:log4j-core:2.11.1", "impacted_artifact": "generic://generic/generic-42.jar", "impact_path": [ "generic://generic/generic-42.jar" ], "path": "tools-generic", "fixed_versions": [ "2.15.0" ], "published": "2021-12-10T13:52:51+01:00", "artifact_scan_time": "2021-08-05T14:27:03+02:00", "issue_id": "XRAY-191654", "package_type": "maven", "provider": "JFrog", "description": "Apache Log4j2 \u003c=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. In previous releases (\u003e2.10) this behavior can be mitigated by setting system property "log4j2.formatMsgNoLookups" to ?true? or by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-.jar org/apache/logging/log4j/core/lookup/JndiLookup.class). Java 8u121 (see https://www.oracle.com/java/technologies/javase/8u121-relnotes.html) protects against remote code execution by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".", "references": [ "https://logging.apache.org/log4j/2.x/security.html" ], "project_keys": [] } ,{ "cves": [ { "cve": "CVE-2021-44228", "cvss_v3_score": 10 } ], "cvss3_max_score": 10, "summary": "Apache Log4j2 \u003c=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. In previous releases (\u003e2.10) this behavior can be mitigated by setting system property "log4j2.formatMsgNoLookups" to ?true? or by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-.jar org/apache/logging/log4j/core/lookup/JndiLookup.class). Java 8u121 (see https://www.oracle.com/java/technologies/javase/8u121-relnotes.html) protects against remote code execution by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".", "severity": "Critical", "severity_source": "CVSS V3 from NVD", "vulnerable_component": "gav://org.apache.logging.log4j:log4j-core:2.11.1", "impacted_artifact": "generic://generic/generic-42.jar", "impact_path": [ "generic://generic/generic-42.jar" ], "path": "tools-generic", "fixed_versions": [ "2.15.0" ], "published": "2021-12-10T13:52:51+01:00", "artifact_scan_time": "2021-08-05T14:27:03+02:00", "issue_id": "XRAY-191654", "package_type": "maven", "provider": "JFrog", "description": "Apache Log4j2 \u003c=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. In previous releases (\u003e2.10) this behavior can be mitigated by setting system property "log4j2.formatMsgNoLookups" to ?true? or by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-.jar org/apache/logging/log4j/core/lookup/JndiLookup.class). Java 8u121 (see https://www.oracle.com/java/technologies/javase/8u121-relnotes.html) protects against remote code execution by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".", "references": [ "https://logging.apache.org/log4j/2.x/security.html" ], "project_keys": [] } ,{ "cves": [ { "cve": "CVE-2021-44228", "cvss_v3_score": 10 } ], "cvss3_max_score": 10, "summary": "Apache Log4j2 \u003c=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. In previous releases (\u003e2.10) this behavior can be mitigated by setting system property "log4j2.formatMsgNoLookups" to ?true? or by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-.jar org/apache/logging/log4j/core/lookup/JndiLookup.class). Java 8u121 (see https://www.oracle.com/java/technologies/javase/8u121-relnotes.html) protects against remote code execution by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".", "severity": "Critical", "severity_source": "CVSS V3 from NVD", "vulnerable_component": "gav://org.apache.logging.log4j:log4j-core:2.11.1", "impacted_artifact": "generic://generic/generic-42.jar", "impact_path": [ "generic://generic/generic-42.jar" ], "path": "tools-generic", "fixed_versions": [ "2.15.0" ], "published": "2021-12-10T13:52:51+01:00", "artifact_scan_time": "2021-09-06T13:55:02+02:00", "issue_id": "XRAY-191654", "package_type": "maven", "provider": "JFrog", "description": "Apache Log4j2 \u003c=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. In previous releases (\u003e2.10) this behavior can be mitigated by setting system property "log4j2.formatMsgNoLookups" to ?true? or by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-.jar org/apache/logging/log4j/core/lookup/JndiLookup.class). Java 8u121 (see https://www.oracle.com/java/technologies/javase/8u121-relnotes.html) protects against remote code execution by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".", "references": [ "https://logging.apache.org/log4j/2.x/security.html" ], "project_keys": [] } ,{ "cves": [ { "cve": "CVE-2021-44228", "cvss_v3_score": 10 } ], "cvss3_max_score": 10, "summary": "Apache Log4j2 \u003c=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. In previous releases (\u003e2.10) this behavior can be mitigated by setting system property "log4j2.formatMsgNoLookups" to ?true? or by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-.jar org/apache/logging/log4j/core/lookup/JndiLookup.class). Java 8u121 (see https://www.oracle.com/java/technologies/javase/8u121-relnotes.html) protects against remote code execution by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".", "severity": "Critical", "severity_source": "CVSS V3 from NVD", "vulnerable_component": "gav://org.apache.logging.log4j:log4j-core:2.11.1", "impacted_artifact": "generic://generic/generic-42.jar", "impact_path": [ "generic://generic/generic-42.jar" ], "path": "tools-generic", "fixed_versions": [ "2.15.0" ], "published": "2021-12-10T13:52:51+01:00", "artifact_scan_time": "2021-09-06T13:55:02+02:00", "issue_id": "XRAY-191654", "package_type": "maven", "provider": "JFrog", "description": "Apache Log4j2 \u003c=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. In previous releases (\u003e2.10) this behavior can be mitigated by setting system property "log4j2.formatMsgNoLookups" to ?true? or by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-.jar org/apache/logging/log4j/core/lookup/JndiLookup.class). Java 8u121 (see https://www.oracle.com/java/technologies/javase/8u121-relnotes.html) protects against remote code execution by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".", "references": [ "https://logging.apache.org/log4j/2.x/security.html" ], "project_keys": [] } ]}
3. Now wait till the dedupe algorithm marks the original one and finds the duplicates
4. Go to the finding, which is marked as original and choose close finding and add some notes, e.g. "false positive"
5. After that the vulnerability should have the state "mitigated" and it should be visible that a note is attached to it
6. Repeat step 2 and wait till the dedupe was done. The already mitigated finding was deleted now

Expected behavior As the close findings is a feature that is useful for false positives, it should have the same behavior as for risk acceptance (using risk acceptance for closing the finding will not produce this bug) that the original finding is preserved.

Deployment method (select with an X)

• [ ] Docker Compose
• [ X ] Kubernetes
• [ ] GoDojo

[italvi]

@devGregA could you reproduce this bug?

[italvi]

@devGregA I still think that this is a huge issue and should be checked if reproduceable by others.