During license and vulnerability audits, automated scans may sometimes identify findings that aren’t accurate. These false positives can affect audit results, reporting, and remediation efforts if they aren’t handled correctly. This article explains best practices for identifying, correcting, and preventing false positives for both component/version/license findings and vulnerability findings, while keeping future scans consistent and reliable.

Handling Component, Version, and License False Positives

False positives related to components, versions, or licenses usually occur due to automated detection rules or ambiguous file matches. You have several options to correct these findings, depending on whether the fix is needed for a single project or across multiple projects.

Fix the False Positive Within a Project

When you identify a false positive in a specific project, update it directly by editing the affected inventory item. This ensures the project reflects the correct component, version, or license information.

Apply the Fix to Future Projects

To prevent the same false positive from reappearing, use one of the following approaches:

• Custom detection rules: Create a custom detection rule based on a file hash or file path and map it to the correct component, version, or license. Custom rules override automated detection rules and provide the most precise control for recurring false positives.
• Export and import inventory data: Once your inventory is in the desired state, export the inventory and import it into another project. This approach helps you:
  • Carry corrected inventory forward from one release to the next.
  • Maintain a unified export file with known corrections that you can apply to future projects.
• Adjust publish threshold criteria: You can adjust the auto-publish threshold criteria in the scan settings to control whether automated findings are published automatically. False positives are rarely classified as high confidence, so adjusting thresholds can reduce noise without hiding legitimate issues.
• File a Support case: If the false positive appears to be caused by product data or automated rules, file a Support case. Depending on the issue, the correction may be delivered through an electronic update or included in a future release.

Handling Vulnerability False Positives

Vulnerability false positives require a different approach, as they are managed separately from inventory detection.

Suppress the Vulnerability

Use the vulnerability suppression feature to suppress a false positive vulnerability globally. This prevents it from appearing in future scans and reports.

Report on Vulnerability Ignore List

Use the custom inventory field Vulnerability Ignore List to explain or annotate why a vulnerability was suppressed. Adding context helps with audits, reviews, and internal documentation.

You can then generate the Project Vulnerability Exclusion Report to see all suppressed vulnerabilities across the selected project.

File a Support Case

File a Support case so the issue can be reviewed and corrected at the source.