FAQ & Troubleshooting

Common Issues

TENABLE_URL is missing or invalid:
```
TENABLE_URL is required and must be non-empty
```
```
TENABLE_URL must include a scheme and hostname (got 'nessus.example.com:8834')
```
Solution: Set TENABLE_URL to the full URL of the Nessus scanner, including https://, for example https://nessus.example.com:8834. Make sure the variable is passed to the agent container. An unset variable is passed to the integration as the literal text ${TENABLE_URL}, which fails the same check.
API keys missing:
```
TENABLE_ACCESS_KEY and TENABLE_SECRET_KEY are required
```
Solution: The access key or the secret key is missing or empty in the policy config. Set TENABLE_ACCESS_KEY and TENABLE_SECRET_KEY in your configuration or .env file. See Generate Nessus API keys.
The run fails with a 401 Unauthorized error:

The error appears in the traceback logged after Error running Tenable backend:.

Solution: The access key or secret key is not valid, or a variable was not passed to the agent container, so its literal text, such as ${TENABLE_ACCESS_KEY}, was sent as the key. Check that the variables are set in the agent container's environment. If they are, generate keys again, as described in Generate Nessus API keys, and update TENABLE_ACCESS_KEY and TENABLE_SECRET_KEY.
No IP addresses are recorded:
```
No scans found in Tenable
```
Solution: The Nessus user who owns the API keys cannot access any scans. Check that the scans you want to sync are visible to that user in the Nessus web interface. Also check that the scans have run: a scan with no hosts in its results produces no IP addresses.
A scan is skipped:
```
Failed to fetch details for scan 'DMZ Scan': <error>
```
Solution: The integration could not read that scan's results and skipped it. Other scans are still synced. Check the error text and that the scan's results open in the Nessus web interface.
A scan is skipped because it has not completed:
```
Skipping scan 'Weekly Internal': it has no completed run yet
```
Solution: This is expected. The integration reads only completed runs, so a scan that has never completed contributes nothing. Its hosts appear after its first run completes. A scan that has completed before but is running again, paused, or canceled is not skipped: its last completed run is used.
A warning says a host's details could not be read:
```
Failed to fetch details for host 3 in scan id=12: <error>
```
Solution: The integration could not read the host's details, which hold its IP address and DNS name. It uses the host's entry in the scan's host list for the address instead, which holds the IP address only when the scan targets IP addresses, and gets no DNS name for the host from that scan. If that entry is a name, the host is skipped with the warning below.
A warning says a host was skipped:
```
Skipping host 'web01.example.com' in scan 'DMZ Scan': no IP address
```
```
Skipping host 3 in scan 'DMZ Scan': no IP address
```
Solution: The integration found no IP address for the host, so it was not recorded. This happens when the host's details have no IP address or could not be read (see the previous entry), and the scan targets host names. The second form, with the host's ID, means the scan's host list gave no address at all. Check that the host's results open in the Nessus web interface.
IP addresses have no DNS name:

Solution: The DNS name comes from the host-fqdn property in each host's details. If no scan reports one for the host, or its host details could not be read, the DNS name is empty. Set USE_DNS_FALLBACK: true to look up a name by reverse DNS from the agent container instead. See DNS names.
Vulnerability counts in NetBox differ from a scan in Nessus:

Solution: The counts come from each scan's newest completed run. For a host found by more than one scan, they come from the scan that completed most recently, so they can differ from an older scan's results. If that newest scan is a discovery scan that does not check for vulnerabilities, the host shows none and zero counts. A scan that is running again keeps its previous completed counts until the new run completes. See Hosts found by more than one scan.
Discovered objects do not appear in NetBox:

Solution: Discovered data is staged as deviations in NetBox Assurance and must be applied before it appears in NetBox. Navigate to Assurance → Active Deviations and apply the deviations.
Custom fields not present in NetBox after the first run:

Solution: The custom fields are created during bootstrap mode. Ensure you ran the agent with BOOTSTRAP: true and applied the resulting deviations in NetBox Assurance before running the full sync.

Frequently Asked Questions

Q: Which Tenable products are supported?

A: Tenable Nessus. Other Tenable products, such as Tenable Vulnerability Management and Tenable Security Center, are not supported in this release. See Supported Tenable Products.

Q: Does the integration write anything to Nessus?

A: No. It does not create, launch, or change scans. It only reads scan results.

Q: Which scans are synced?

A: Every scan that the Nessus user who owns the API keys can access. There is no setting to select scans. To exclude scans, use API keys for a user that cannot access them.

Q: Are individual vulnerabilities or CVEs recorded?

A: No. Only the most severe level and the number of findings at each severity are recorded, in custom fields and in the IP address description. Plugin IDs, CVEs, and CVSS scores are not recorded.

Q: Are devices or virtual machines created?

A: No. Each scanned host is recorded as an IP address. The integration does not create devices or virtual machines, and it does not link an IP address to an existing device, virtual machine, or interface.

Q: Why does a host with findings show a severity of none?

A: Either its findings are all info severity, or the most recently completed scan that found it reported no vulnerabilities. Info findings, such as open ports and operating system detection, are not treated as vulnerabilities. A discovery scan that does not check for vulnerabilities reports none, and if it completed after a vulnerability scan of the same host, its results are used.

Q: How do I find addresses with critical vulnerabilities?

A: In NetBox, navigate to IPAM → IP Addresses and filter by the Tenable Max Severity custom field set to critical. See Severity Custom Fields for every field.

Q: Are severity values updated when vulnerabilities are fixed?

A: Yes. Every run sets all five Tenable custom fields on every IP address it records, including none and zero counts. After the scan that found the vulnerability runs again and completes, the next sync shows the host's current state.

Q: Does the integration verify the Nessus TLS certificate?

A: No. A scanner using its default self-signed certificate works, and there is no setting to provide a CA certificate.

Q: How do I sync more than one Nessus scanner?

A: Add a policy for each scanner, each with its own URL and API keys. Each scanner's IP addresses carry a tag naming that scanner, such as nbl-tenable-tenable-nessus-example-com.

Q: Will IP addresses be deleted from NetBox if a host is no longer scanned?

A: No. The integration does not delete NetBox objects. Handle these removals manually.

Common Issues

Frequently Asked Questions

On this page