Component Installs Require Paranoid Checks (DEPRECATED)

We understand the intent: component vulnerabilities are often not directly patchable by the customer and may require the parent vendor to release an update. However, from an operational risk-management perspective, suppressing these findings in default scans creates several challenges: 

• Reduced visibility for customers: Today, identifying outdated/bundled components is a keyway we assess exposure and drive remediation conversations with software vendors. If those findings disappear by default, it becomes harder to track and escalate vendor risk in a timely and measurable way.
• Over-reliance on vendors to self-report: In practice, many organizations depend on detection and verification because vendor disclosures (libraries/versions/SBOM completeness) can be inconsistent or delayed.
• “Paranoid” mode isn’t a clean substitute: While enabling paranoid mode preserves the detections, in many environments it can also increase noise/false positives and downstream triage overhead—making it difficult to use as the primary mechanism for routine scanning.
  
  

We expect many customers will only realize the impact after seeing a sudden reduction in findings for component software (OpenSSL, Curl/LibCurl, Apache HTTPD/Tomcat, SQLite, PHP, Python packages, Node.js modules, etc.). The post also notes this change affects a large set of plugins and is implemented within shared libraries, which suggests a broad behavioral shift rather than a narrow tuning. 

Request / recommendation:
Please consider pausing or phasing this rollout with clearer customer-facing guidance and impact examples and solicit feedback before changing defaults. If Tenable proceeds, we’d strongly prefer an explicit, dedicated scan policy option (e.g., “Enable Component Install Vulnerability Findings”) rather than requiring customers to switch to “paranoid” mode to retain this visibility.

- Ashman