Nessus Remediation: From Nessus Findings to Verified Fixes

You do not have to replace Nessus to fix what it finds. SITEY works with the scanner you already run: it can launch Nessus scans through the Nessus API, and it imports your .nessus exports. Each imported finding then goes through triage, a host-specific fix, a human approval, deployment by agent and a retest. This page explains how that Nessus remediation workflow runs, what it needs from you, and where its limits are.

Keep Nessus. Let SITEY handle what happens after the scan

Most teams that run Nessus are not short of findings. They are short of the hours it takes to turn a finding into a tested change on a specific server, get it approved, and prove it worked. Nessus keeps scanning; SITEY turns its output into a remediation queue that ends in a retest.

There are two ways to work with Nessus from SITEY:

Results of a scan launched from SITEY are not pulled in automatically: when the scan finishes, export it from Nessus and upload the file. The file importer prefers CVSS v3 over v2, keeps the plugin output, references and solution text, and when the Nessus 0 to 4 severity and the CVSS score disagree, the higher one wins, so a Critical is never quietly stored as a Medium. Repeat findings merge into the existing record. Details are on the scanner integrations page.

Why the Nessus solution text is not a remediation plan

A Nessus finding comes with a solution text, and for a scanner that is the right level of detail. The same text is written for every host where the check fires, so it cannot know which build is installed on your server, whether an application still depends on the setting, or which PowerShell cmdlets exist on an older Windows Server. That is not a flaw in Nessus; a scanner’s job is to detect and describe. It does mean someone still has to turn “disable the protocol” or “upgrade to the fixed version” into a command that is safe on that machine, get it approved and roll it out, host by host.

Nessus remediation automation in SITEY replaces that hand-written playbook or script with a generated, checked and approved script per host, while a person stays in charge of what runs.

How SITEY automates remediation of Nessus findings

1. Collect and deduplicate

   Findings are normalized into one schema with results from your other scanners. On import, SITEY matches each Nessus host to a registered SITEY agent by host name or IP, which is how a fix later reaches the right machine.

2. AI triage

   Each finding gets a priority score and a false-positive probability, drawing on CVSS, EPSS and the CISA KEV catalog. The reasoning is stored, so an analyst can read it and reverse the verdict. On hosts with a SITEY agent, the deep analysis path can run a read-only diagnostic script that checks the finding on the live machine. See AI triage.

3. Host-specific plan

   AI remediation writes a bash or PowerShell script for that host from the diagnostic output, the operating system profile and the host’s software and service inventory. For registry and service changes the model is asked for a typed plan that SITEY compiles itself; for registry changes this is enforced. Findings only a vendor can fix become a vendor-contact record, not an invented script.

4. Safety checks

   The script passes a blocklist, a size limit and a shell syntax check before it can be queued.

5. Approval gate

   At the default autonomy level the job waits in pending approval. The approver sees the actual script, the target agent and the operation type, and can approve, reject, or move the job into a maintenance window.

6. Deployment by agent

   The SITEY agent on the Windows or Linux host runs the approved script and reports its output, exit code and inventory back to your server.

7. Retest and closure

   A successful job does not close the finding. It moves to awaiting retest and is marked resolved only when the retest does not find it again. A check that cannot run leaves the status unchanged. For Nessus, the retest only matches High and Critical results, so confirm Medium and Low closures with a fresh Nessus scan. See retest and closure.

Nessus tells you what is wrong. SITEY’s job is to get it fixed on that exact host, with a named approver and a retest on record.

Illustrative example: a Nessus remediation script for one host

Suppose Nessus reports that SMB version 1 is enabled on a Windows Server 2019 file server at 10.20.4.17, port 445, and the solution text says, in general terms, to disable SMBv1. The read-only diagnostic confirms it. The plan that comes back for approval could look like this:

# Illustrative example: job for WIN-FS02 (10.20.4.17), finding imported from Nessus
# Plan: configuration change | Reboot: none | Service restart: none
$ErrorActionPreference = 'Stop'

# 1. Record the state before the change
$before = (Get-SmbServerConfiguration).EnableSMB1Protocol
Write-Output "BEFORE EnableSMB1Protocol=$before"
if (-not $before) { Write-Output 'ALREADY_COMPLIANT'; exit 0 }

# 2. Stop if any client is using SMB1 right now
$smb1 = @(Get-SmbSession | Where-Object { $_.Dialect -and ([version]$_.Dialect -lt [version]'2.0') })
if ($smb1.Count -gt 0) { Write-Output "ABORT: $($smb1.Count) SMB1 session(s)"; exit 2 }

# 3. Apply the change
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force

# 4. Verify
$after = (Get-SmbServerConfiguration).EnableSMB1Protocol
Write-Output "AFTER EnableSMB1Protocol=$after"
if ($after) { exit 1 } else { exit 0 }

The job also carries a plain-language description, a risk warning (clients that still need SMB1 will no longer connect), the affected service and a verification command. If verification later finds the issue still open, the change can be rolled back from the pre-change snapshot, where one was taken, and the case goes to a person.

Safety gates between a generated script and your servers

Setting up the Nessus integration

1. Install SITEY on Linux

   Ubuntu 22.04 or 24.04, Debian 12, RHEL or Rocky 9, with your own PostgreSQL database. There is no Windows server installation.

2. Create Nessus API keys

   In Nessus, generate an access key and a secret key for the account SITEY should use.

3. Enter them on the Integrations page

   Add the Nessus URL and both keys. SITEY stores them in agent/config.json on your server, not in the database, and shows them masked afterwards. Only the infrastructure-manager role can change them.

4. Run the connectivity test

   It checks that Nessus answers, reads its edition and lists the available templates, policies and scanners. If the edition does not allow scan creation through the API, SITEY tells you here.

5. Deploy agents

   Install the SITEY agent on the Windows and Linux hosts you want remediated.

6. Import, review, then automate

   Upload a .nessus file and read the first triage results yourself. Keep the default autonomy level, which stops every change at the approval gate, until you agree with what SITEY proposes.

If you also run OpenVAS, the same pipeline applies; see the OpenVAS integration.

Nessus remediation with SITEY or with Tenable’s own tools

Tenable sells its own answer to this problem, and it deserves a fair look, especially if you already own Tenable’s platform. Tenable Patch Management describes “intelligent and customizable autonomous patching”, with guardrails, SLAs and patch policies that control how far the automation goes. According to Tenable, it covers Windows (including drivers and BIOS), Mac and Linux plus more than 20,000 third-party applications, lets you schedule, pause and roll back deployments, and runs on-premises or as SaaS, licensed by annual subscription and priced by asset.

SITEY takes a different route. It writes a script for the specific host and finding, including configuration findings such as registry, service or protocol settings; it takes findings from 16 scanners, not only Nessus; and it is sold at a fixed price with no per-asset fee, although each license has an IP quota. The trade-offs are real: SITEY’s agents run on Windows and Linux, with no macOS agent, and you install and operate the platform yourself.

Before you buy

You buy online and install it yourself, with no sales call; see pricing. SITEY is built by SITEY Bilişim at Giresun Teknopark in Turkey; its founder has worked as a security researcher since 2014 and is credited with CVE-2021-40960 and CVE-2022-3792.

Frequently asked questions

Does SITEY work with Nessus Essentials?

Imports do not depend on the edition: the parser reads the .nessus or .xml file and does not check which edition produced it. Launching scans is different. SITEY checks the Nessus license before it creates a scan; when it reports Essentials, or a license without scan API support, SITEY does not create or launch the scan and shows a warning instead. In that case, run scans in Nessus and import the results.

Where does my Nessus data go? Does SITEY work air-gapped?

Reports are parsed on your SITEY server and stored in your own PostgreSQL database. SITEY is not air-gapped. It makes two connections to siteyvm.com, for license activation and validation and for the engine feed, and neither carries scan data. If you enable AI, finding text and host context go to the OpenAI-compatible endpoint you choose, with your own key; you can point it at a model endpoint you host yourself, or turn AI off. Optional lookups go to NVD, CISA KEV, FIRST EPSS, MSRC and the Microsoft Update Catalog. The security page lists each connection.

Does anything run on my servers without approval?

Read-only diagnostic scripts are sent without a separate approval, because they are validated as read-only. At the default autonomy level every change waits at the approval gate, and even if you widen autonomy for a narrow class of findings, high-impact changes still need a person’s approval.

Do my hosts need a SITEY agent?

For remediation, yes. Fixes are run by the SITEY agent on Windows or Linux hosts. Findings on hosts without an agent can still be imported, triaged and assigned, but SITEY cannot run a diagnostic or deliver a fix there.

How much does SITEY cost?

$599 per month, cancel anytime, or $5,999 for a lifetime license with one year of updates and engine feed included. There is no per-asset fee and no scan quota, but each license has an IP quota; see the pricing page. AI usage is paid to your AI provider and is not included. You also need your own Nessus license.

Sources

• Tenable, Tenable Patch Management product page: https://www.tenable.com/products/patch-management, accessed 24 September 2026.

Nessus and Tenable are trademarks of Tenable, Inc. SITEY is not affiliated with or endorsed by Tenable. Other product names are trademarks of their respective owners.