Duplicates and copies of security issues

TRON.ASOC uses mechanisms to identify copies and deduplicate security issues. These mechanisms help find duplicate records and reduce redundant information in the results.

Difference between a copy and a duplicate

A copy is a vulnerability whose hash completely matches the hash of an already recorded vulnerability (the hash fields are described in the Hash-based copy identification section). Because you can configure the set of fields included in the hash through a configuration file, a matching hash doesn't necessarily mean that both vulnerabilities were detected by the same scanning tool: if the Tool_Type_name field is excluded from the hash, a vulnerability found by another tool can also be identified as a copy.

When the hashes match, the system doesn't create a new record. It doesn't save the copy and only updates the last detected date for the existing vulnerability. For example, if you upload the same report with the same vulnerability 50 times, the system saves the vulnerability during the first upload and only updates its last detected date during each of the following 49 uploads. It doesn't create additional records.

A duplicate is a vulnerability whose hash differs from the hash of another vulnerability in at least one field but is grouped with it according to Deduplication rules or manually marked as a duplicate by a user. The concept of a duplicate isn't related to the scanning tool. For example, the same tool can find two duplicate vulnerabilities. Duplicates aren't copies.

Hash-based copy identification

The system uses a hash-based mechanism to identify copies of vulnerabilities. The hash consists of the following vulnerability fields:

• Tool_Type_name—scanning tool type;
• CVE—CVE identifier;
• CWE—CWE identifier;
• Source_file—source file path;
• Lib_name—library name;
• Lib_version—library version;
• Category—vulnerability category;
• Source_object—source object;
• Line—line number;
• Matched_Code—matching code fragment.

Because you can configure these fields through a configuration file, you can, for example, exclude Tool_Type_name. The system then identifies matching vulnerabilities as copies regardless of the tool that detected them.

The system identifies copies as follows:

1. When you start TRON.ASOC with hashing enabled, the system recalculates the hash for all existing vulnerabilities.
2. The system identifies and deletes copies, keeping the earliest record from each set of copies.
3. The system determines the status of the remaining vulnerability according to the following rule:
   • New—if at least one of the copies had an open status;
   • Fixed—if none of the copies had an open status.

The system applies the same logic to each new report upload: if the hash of a newly detected vulnerability matches the hash of an already saved vulnerability, the system only updates the last detected date of the existing vulnerability and doesn't create a new vulnerability record.

warning

You can change hash parameters only through the configuration file. You can't manage them through the user interface.

note

The system displays the number of vulnerabilities in the scan results with hashing taken into account.

Issue deduplication

Deduplication automatically finds and merges duplicate security issue records.

tip

For more information about configuring global Deduplication rules, see Deduplication rules.

Finding duplicate security issues

To view duplicate security issues, follow these steps:

1. Go to the Issues section.
2. Open the security issue that deduplication may apply to.
3. Select Find and deduplicate similar issues from the Actions drop-down list.

4. In the window that opens on the right, set the required filters.

5. Select Continue.

6. Select vulnerabilities from the list in the new window on the right.

7. Select Mark as duplicate.

After you complete these steps, the system marks the issues as duplicates and links them to the new issue. A notification appears in the system interface.