In Nessus, what is a plugin, and what do its plugin ID, family and type tell you about a finding?
answer
- the unit Nessus detects with
- Tenable research, its own scripting language
- numeric ID, family for selection
- remote, local, combined, settings, summary
basics
~20 sA Nessus plugin is a NASL program from Tenable, usually testing for one issue. Its numeric ID names the finding, its family groups it for selection in a policy, and its type says how it gathered evidence.
solid answer
~40 sA plugin is the unit Nessus detects with: a NASL program from Tenable's research team that carries the vulnerability description, a generic remediation and the test itself. Every finding in a Nessus report is a plugin result on a host, so the **plugin ID** is the stable name you track, exclude or search for. The **family** (for example `Denial of Service`) is how a policy enables or disables plugins in bulk. The **type** tells you how much to trust the result: `remote` collects over the network without host credentials, `local` logs in through a service such as SSH or SMB, `combined` uses both, while `settings`, `summary`, `third party` and `reputation` plugins support the scan rather than test for a flaw. Standalone Nessus refreshes the plugin set every 24 hours by default.
go deeper
Recall that a plugin is one NASL detection program, that the plugin ID names a finding and that families group plugins for selection.
Explain the plugin types, especially remote against local against combined, and how a family's enabled, disabled or Mixed state scopes a policy.
Read the type and the evidence note before trusting a finding, and talk about tracking, excluding and filtering results by plugin ID.
Frame plugin IDs as the stable key between Nessus and the rest of a vulnerability programme, and say where CVE-keyed reporting will disagree with them.
## What a plugin is Tenable Nessus does not ship one monolithic scanner engine with hard-coded tests. Tenable's research staff write a separate program for each issue they want Nessus to detect, and the Nessus 10.12 user guide calls each of these programs a **plugin**. Plugins are written in Tenable's proprietary **Nessus Attack Scripting Language (NASL)**. Each one carries three things: - the **vulnerability information** shown in the report (synopsis, description, references); - a **generic set of remediation actions** (the Solution section); - the **algorithm** that tests the target for the issue. Nessus also uses plugins to collect configuration information from authenticated hosts for configuration audits, so not every plugin reports a vulnerability. When Nessus is registered it downloads the plugins and compiles them into an internal database. While that compilation runs you cannot create or launch scans, or create or view policies. A standalone scanner checks for updated plugins every **24 hours** by default; `nessuscli update --plugins-only` forces a plugin-only update from the command line. ## The fields that identify a plugin Open any finding and the **Plugin Information** block names the plugin precisely: | Field | What it tells you | |---|---| | `ID` | The plugin's numeric identifier, stable across scans and reports | | `Version` | The plugin's current version; the `Modified` date shows when it last changed | | `Type` | How the plugin operates when a scanner runs it | | `Published` / `Modified` | When the plugin first appeared and last changed | The ID is the handle every other Nessus feature uses: you search for it in a policy's Plugins tab, filter results by it, and some plugins exist only to report on the scan itself. Plugin **19506** (Nessus Scan Information), for example, summarises how the scan ran rather than reporting a flaw. ## Plugin families Plugins are grouped into **families**. A family is a selection unit, not a severity tier: in a policy's Plugins tab you enable a whole family (green), disable it (gray), or open it and pick individual plugins, which turns the family purple and marks it **Mixed**. Two family names appear in the 10.12 guide itself: - `Denial of Service`, which Tenable warns contains plugins that could cause outages unless **Safe Checks** is enabled; - `ESX Local Security Checks`, whose checks use ESXi package details collected with VMware credentials. ## Plugin types: how the evidence was gathered The `Type` field is the one that matters when you judge a finding: 1. `remote` — does not require local host credentials; collects information over the network through banner checks, testing for a patch, or exploiting a vulnerability. Some remote plugins sign in to a service, but they do not require local host credentials. 2. `local` — authenticates to the target through a service such as SMB or SSH and extracts information. 3. `combined` — uses both, and still reports what it can from the remote part when local checks are unavailable. 4. `settings` — defines settings other plugins use during the scan. 5. `summary` — summarises data other plugins collected. 6. `third party` — runs a third-party application. 7. `reputation` — uses a third-party reputation service. Some plugin pages on the Tenable plugins site carry the note "Nessus has not tested for this issue but has instead relied only on the application's self-reported version number". That note marks a finding inferred from a version string; why such inferences go wrong is a general scanning question, not a Nessus one. ## What else a plugin result carries Below the Plugin Information block, a result shows **Risk Information** (VPR, EPSS, Risk Factor and CVSS v2.0, v3.0 and v4.0 base scores and vectors), **Vulnerability Information** (CPE, whether an exploit is available, patch and vulnerability publication dates) and **Reference Information** (CVE, CWE, CERT, IAVA, BID and similar). A single plugin can list several CVEs, so a plugin ID and a CVE are not interchangeable keys. ## Why interviewers ask A candidate who has run Nessus talks about findings by plugin ID, knows that a family is how a policy is scoped, and reads the type before trusting a result. A candidate who has only read about it tends to treat the plugin ID as a CVE number or to describe families as severity buckets.
- Why would you exclude or track a finding by plugin ID rather than by CVE in Nessus?The plugin ID is what Nessus itself keys on: policies select plugins, filters match `Plugin ID`, and a plugin's Reference Information can list several CVEs at once. Tracking by CVE can merge or split findings in ways Nessus does not, so the plugin ID is the stable join between scans.
- A finding's plugin page says Nessus relied only on the application's self-reported version number. What does that tell you?That the plugin inferred the issue from a reported version rather than testing for it, so the result is only as good as that version string. How to confirm or dispute such an inference is a general scanning question; the Nessus-specific point is that the plugin page tells you which kind of evidence you are holding.
saying these in an interview costs you the question
- A Nessus plugin ID is just the CVE number in another format.
- Plugin families are severity tiers such as critical, high and medium.
- Nessus plugins are compiled binaries written in Python.
- A remote-type plugin logs in over SSH to read installed packages.
- Every Nessus plugin reports a vulnerability.