Forum Discussion
Component Installs Require Paranoid Checks (DEPRECATED)
Update - March 4, 2026
After considering customer feedback, we. have decided to re-evaluate these changes and come up with a better way of handling Component installs. For the latest information, please refer to the new release highlight: Improvement: Handling Component Installs for Vulnerability Assessment
Summary
With this update, products that are deemed to be components of another application, will now require the scan to be run in paranoid mode to trigger generic vulnerability detection plugins.
In this context, “generic vulnerability detection plugins” refers to plugins that cover advisories published by the component vendor (e.g., plugin ID 242325, SQLite < 3.50.2 Memory Corruption) rather than the operating system or “parent” application that distributes the component, either as a part of the operating system or a dependent tool of the parent application.
Overview
Tenable covers software that can be either installed as base level software, or be included as component software of a larger product installation. Base level software can be updated without any impact to the base product functionality. Component software is typically updated as part of the vendor update for the larger packaged product, and the individual components are not updatable.
Non-paranoid scans will report base software vulnerabilities that are actionable. Paranoid scans will report on base software vulnerabilities as well component software vulnerabilities that are not actionable, but still package a potentially vulnerable version of the component.
To enhance the accuracy of our vulnerability detection and provide users with greater control over scan results, we are implementing an update affecting how we flag vulnerabilities in software components.
Our detection plugins for OpenSSL, Curl, LibCurl, Apache HTTPD, Apache Tomcat, SQLite, PHP, Python packages and Node.js modules can now identify when these packages are installed as components of another parent application (e.g., SQLite bundled with Trend Micro’s Deep Security Agent), rather than as standalone installs.
Key Changes:
- Non-Paranoid Scans: Scans running in the default mode will no longer flag generic vulnerability detection plugins for these component installs. This is because vulnerabilities in components generally cannot be patched directly; users must wait for the parent application's vendor to issue an update.
- OS Vendor Advisories Unaffected: This change does not affect plugins for OS vendor security advisories that cover the same vulnerabilities (e.g., plugin ID 243452, RHEL 9 : sqlite (RHSA-2025:12522)).
- Paranoid Scans: For scans running in paranoid mode, generic vulnerability detection plugins will still trigger for component installs if the detected version is lower than the expected fixed version.
Expected Impact:
Customers running non-paranoid scans should anticipate seeing a reduction in potential vulnerability findings for OpenSSL, Curl, LibCurl, Apache HTTPD, Apache Tomcat, SQLite, PHP, Python packages and Node.js modules that are installed as components.
Technical Details:
The changes are entirely contained within two shared libraries, vcf.inc and vdf.inc, utilized by the affected plugins. This update impacts approximately 750 plugins specific to OpenSSL, Curl, LibCurl, Apache HTTPD, Apache Tomcat, and SQLite.
Targeted Release Date:
Friday, February 6, 2026
11 Replies
Hello all,
Thank you all for your feedback on this, it has been super helpful and very much appreciated!
The work on improving this functionality is nearing competition. For the latest information, please refer to the new release highlight: Improvement: Handling Component Installs for Vulnerability Assessment - once this is released, information here in this post will be obsolete.
Chiming in to agree with disagreeing with this change. Particularly with Ashman's point:
“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.
It would seem to me, in the world before this change, that customers that didn't want to see those vulnerabilities that are components of other applications could just re-cast them using the plugin id and the plugin output to accept those risk for the time being. Not sure how we can retain the same visibility we had before without introducing additional noise into our findings.
I also agree with Ashman. These vulnerabilities should be fully visible without adjusting scan settings. The only way I can know if a sqlite3.dll file is out of date is by looking at the plugin 171077 - SQLite Detection (Windows) and looking through the output for the version.
Just wanted to confirm current status and if this actually was released on the target of 2/6/2026
It sounds like it's being put on hold but does that mean it did not make it to released state?Lastly, If it did roll out is there a way to identify which plugins were impacted?
We assumed it had not been rolled out or the change reverted, but after checking with Tenable, due to the number of SQLite detections having dropped dramatically, they advised it is in place and paranoid mode is still required until they come up with a new solution.
This situation is quite frustrating, as I thought it had been paused. rmoody, could you please provide an update? This represents a significant disappointment from Tenable and reflects a lack of security vulnerability detection. With these changes, we are now placing complete trust in all software and vendors.
I fully agree here with Ashman.
While we talk about the Paranoid Mode, we found out recently that some vulnerabilties are not detected on other logical drives other than the systemdrive, even if thorough tests are enabled and without using "include filepath" override.
Some Plugins fire, others don't. The answer was we should explicit use "Include FIlepath" which is unpractiable or use Paranoid Mode 2.
Thorough tests should include all logical drives for all plugins by default and customers should receive better visibility about it. Right now many vulnerabilties might stay undetected just by a questionable design choice.Thank you Dominik. I am also aware of the ticket you have raised for this issue. I am discussing with the team at present and trying to figure out if this behaviour needs to be this way. I must admit that it seems more logical have detection of software installed in other logical drives (D: etc) controlled by "Thorough" tests as opposed to "Paranoid" test. The underlying code is quite old so we may not find a good answer for "why" it was written this way, but can certainly look into making some improvements in this regard. I can't make any promises one way or the other just yet, but it will be investigated.
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.
- AshmanThank you Ashman. You make some excellent point here and we will take them into consideration. We are not done with this initiative by any means!
