In Nessus, a newly published plugin never ran in a scan using your saved policy — what decides whether new plugins join an existing policy?

## Why this goes wrong Teams build a narrow Nessus policy, a vendor publishes an urgent issue, Tenable ships a plugin for it, and the next scheduled scan reports nothing. The scanner did not malfunction; the policy did exactly what its plugin selection told it to. Two separate gates decide whether a plugin runs: whether the scanner **has** it, and whether the policy **selects** it. ## Gate 1: does the scanner have the plugin? How a Nessus 10.12 scanner receives plugins depends on how it is deployed: | Deployment | Where plugins come from | |---|---| | Standalone Nessus | `plugins.nessus.org`, checked every 24 hours by default | | Nessus Essentials | the same feed on a **30-day delay** | | Offline Nessus | only the plugin archive you upload, via the UI or `nessuscli update <tar.gz file name>` | | Managed by Tenable Security Center | Security Center checks every 15 minutes and pushes a new set if it differs | | Linked to Tenable One Vulnerability Management | `cloud.tenable.com` | You can see the installed plugin set and trigger an update on **Settings > About**, next to Last Updated. From the command line, `nessuscli fetch --check` shows whether the scanner is registered and able to receive updates, and `nessuscli update --plugins-only` forces a plugin update. While Nessus compiles a fresh plugin set you cannot create or launch scans. ## Gate 2: does the policy select it? When you save a scan or policy, Nessus records the plugins you selected. When new plugins arrive, the family state decides what happens: - **Enabled family** (green) — new plugins in that family are enabled automatically. - **Disabled family** (gray) — new plugins stay disabled. - **Mixed family** (purple, some plugins on) — the family shows a **padlock**. **Locked**: new plugins added through feed updates are disabled in the policy. **Unlocked**: they are enabled. The general note on the Plugins settings page says new plugins in a disabled or partially enabled family are disabled; the padlock is the per-family control that changes that outcome for a Mixed family. A limited-plugin policy built with **Disable All** and a handful of hand-picked plugins is therefore the policy most likely to miss new detections. ## Dynamic plugin selection `Advanced Dynamic Scan` replaces family and plugin picking with **dynamic plugin filters**. You choose **Match Any** or **Match All**, a plugin attribute, an operator (`is equal to`, `is not equal to`, `contains`, `does not contain`, `greater than`, `less than`) and a value, then **Preview Plugins**. As Tenable releases plugins that match, they are added to the scan or policy automatically. This suits a policy meant to track one class of issue without re-curating it each week. ## Plugin dependencies Many plugins rely on others to collect data first. The scanner advanced setting **`Auto Enable Plugin Dependencies`** (`auto_enable_dependencies`) automatically activates the plugins that selected plugins depend on. If it is disabled, not every plugin selected in a policy may run. Tenable highly recommends keeping it on for any limited plugin policy. It does not enable plugins that scan template settings depend on. ## Finding one plugin in a large policy Large families make scrolling a poor diagnosis. In the policy's Plugins tab, use the **Filter** option and set it to **Match All** with `Plugin ID` `is equal to` the ID you are chasing; Nessus then shows the plugin, its family and whether it is enabled. Note also that Tenable maintains the `Advanced Scan` template itself: it is automatically updated with newly released plugin families whose plugins rely on network traffic for detection, which is a family-level change, not a filter. ## A diagnosis order 1. Confirm the scanner's plugin set includes the plugin (Settings > About; offline and Essentials scanners lag). 2. Open the policy's Plugins tab and find the plugin's family: enabled, disabled, or Mixed with the padlock locked. 3. Check `Auto Enable Plugin Dependencies` on the scanner. 4. Read the plugin's own requirements: a `local` plugin, for example, needs working credentials before it can report anything. ## The trade-off Locked and hand-picked policies are predictable and gentle on fragile hosts, but they silently miss new detections. Enabled families and dynamic filters stay current, at the cost of a scan whose behaviour changes when the feed does. Choose deliberately, and say which one a given policy is.