This is an older essay or practical note. Its reference date is retained from the original entry; use current vendor guidance for product versions and security updates.
A useful vulnerability report explains what was checked, what the evidence supports, and what needs fixing. Nessus can collect that evidence; interpreting it still requires context.
Technical notes checked against the linked primary documentation on 6 October 2026. The original reference date is retained above.
Start with an agreed scan scope
Record the target assets, exclusions, scan window, and acceptable workload before choosing a policy. Use a lab or a small approved pilot to validate the configuration.
Tenable lists Basic Network Scan as a full-system template. Advanced Scan exposes additional configuration, but inappropriate settings can disrupt assets or saturate the network. More ports and faster checks do not automatically produce a better assessment. Choose the coverage needed for the engagement and document its limits. Tenable scan templates.
Verify credentialed coverage
Remote checks describe exposed services. Credentialed checks add local package, patch, and configuration evidence. Coverage depends on the account's permissions: Linux checks may need elevated access for some data, and Windows local checks require administrative access. Follow the platform-specific setup rather than assuming a successful login proves a complete scan.
Tenable distinguishes authentication from successful credentialed checks. Package or patch inventory must be retrieved; Windows checks also require appropriate registry and administrative-share or security-bulletin access. Inspect credential-status output and investigate login failures, including plugin 21745, before treating missing findings as reassurance. Tenable credentialed-check requirements.
Know what the report setting changes
Under Report → Processing, enabling Show missing patches that have been superseded includes superseded-patch information. Disabling it omits that information from the report. This controls reporting, not patch installation; it does not establish that the host is remediated. Record the setting when comparing reports. Tenable report settings.
Severity is an input to prioritisation
CVSS is not Base + Temporal + Environmental. In CVSS v3.1, the Base metrics produce a severity score; Temporal and Environmental metrics refine it using defined equations. Retain the score's version and vector so its assumptions can be checked. FIRST CVSS v3.1 specification.
CVSS v4.0 uses Base, Threat, Environmental, and Supplemental groups. Supplemental metrics add context without changing the calculated score. FIRST CVSS v4.0 specification.
Prioritise confirmed findings using exposure, exploitation evidence, asset importance, and existing controls. Explain those decisions separately instead of informally adding points to a vendor score.
Validate before closing a finding
A version banner alone can mislead. Red Hat backports security fixes to maintained packages, so an older upstream version does not necessarily mean the packaged software remains vulnerable. Check the installed package release against the applicable vendor advisory and the plugin's evidence. Red Hat's security backporting practice.
A practical handover should include the affected asset, plugin ID, evidence, advisory, owner, proposed fix, and verification plan. After remediation, repeat the relevant checks with comparable coverage and record the outcome. Retain unresolved access or coverage failures alongside the results.