Forum Discussion
Component Installs Require Paranoid Checks (DEPRECATED)
The salient difference is that recasting the plugin id would also suppress all non-component detections, i.e. those that are actually within the user's power to remediate. These are basically two different classes of detections: one that can and should be remediated and one that cannot be without 3rd party vendor intervention. Treating them the same way is counterproductive and that is what this feature addresses. I don't disagree with Ashman's take on it, but I feel you've may have missed the point of this change.
Exactly. You may not be aware that the new recasting feature in Tenable allows you to specify a filter on the "Plugin Output". Taking your point "These are basically two different classes of detections: one that can and should be remediated and one that cannot be without 3rd party vendor intervention" and building on it to explain that you should use the plugin output to filter out those that can't be fixed without 3rd party intervention.... i.e. anything that you don't want to fix, you add as a plugin output filter, then re-cast. Hope that helps!
- niko_thome1 month agoConnect Contributor II
That is however only true for situations with exact one file path in the plugins output. If you have multiple openssl or multiple sqlite installations on one system and one of it comes as part of another software, you can either recast the entire finding or not. But that's part of a larger problem which leads to this whole mess: multiple vulnerable paths lead to a single finding. The world would be so much easier if we could get single findings per vulnerable path...
- dominik_raum1 month agoConnect Contributor II
I agree with niko_thome
Tenable should really change their plugin output to have a single finding per vulnerability path.
It's a full mess when it comes to delegate vulnerabilities to the correct team.