Nessus: Setup, Configuration, and Best Practices

Step 3: Monitor scan progress

Poll the scan status endpoint until the scan completes:

#!/bin/bash
# Poll scan status until completion
SCAN_ID="123"
TOKEN="your-token"
NESSUS_URL="https://nessus.corp.local:8834"

while true; do
  STATUS=$(curl -k -X GET "${NESSUS_URL}/scans/${SCAN_ID}" \
    -H "X-API-Token: ${TOKEN}" -s | jq -r '.info.status')
  echo "Scan ${SCAN_ID} status: ${STATUS}"
  
  if [ "${STATUS}" == "completed" ] || [ "${STATUS}" == "stopped" ] || [ "${STATUS}" == "aborted" ]; then
    break
  fi
  sleep 30
done

echo "Scan finished with status: ${STATUS}"

Step 4: Export and process results

Once completed, export findings in a structured format for downstream processing:

#!/bin/bash
# Export scan results as a Nessus XML report, then convert to JSON
SCAN_ID="123"
TOKEN="your-token"
NESSUS_URL="https://nessus.corp.local:8834"

# Request an export (chapters control which sections are included)
EXPORT_PAYLOAD='{
  "format": "nessus",
  "chapters": "vuln_hosts_summary,vuln_by_host,vuln_detail,compliance_exec_summary",
  "filter": "severity_level=critical,high,medium"
}'

FILE_ID=$(curl -k -X POST "${NESSUS_URL}/scans/${SCAN_ID}/export" \
  -H "Content-Type: application/json" \
  -H "X-API-Token: ${TOKEN}" \
  -d "${EXPORT_PAYLOAD}" -s | jq -r '.file')

echo "Export file ID: ${FILE_ID}"

# Poll until the export is ready for download
while true; do
  READY=$(curl -k -X GET "${NESSUS_URL}/scans/${SCAN_ID}/export/${FILE_ID}/status" \
    -H "X-API-Token: ${TOKEN}" -s | jq -r '.status')
  if [ "${READY}" == "ready" ]; then
    break
  fi
  sleep 5
done

# Download the report
curl -k -X GET "${NESSUS_URL}/scans/${SCAN_ID}/export/${FILE_ID}/download" \
  -H "X-API-Token: ${TOKEN}" -o "scan_report_${SCAN_ID}.nessus"

echo "Report downloaded to scan_report_${SCAN_ID}.nessus"

Integrating with CI/CD Pipelines

A common pattern is to trigger a Nessus scan after a deployment to a staging environment, then fail the pipeline if critical vulnerabilities are detected. Here's a simplified GitLab CI example:

# .gitlab-ci.yml snippet
staging-vulnerability-scan:
  stage: security
  script:
    - echo "Triggering Nessus scan against staging..."
    - |
      TOKEN=$(curl -k -X POST "${NESSUS_URL}/session" \
        -H "Content-Type: application/json" \
        -d "{\"username\":\"${NESSUS_USER}\",\"password\":\"${NESSUS_PASS}\"}" -s | jq -r '.token')
      SCAN_ID=$(curl -k -X POST "${NESSUS_URL}/scans" \
        -H "Content-Type: application/json" \
        -H "X-API-Token: ${TOKEN}" \
        -d "{\"settings\":{\"name\":\"CI Staging Scan\",\"policy_id\":42,\"text_targets\":\"${STAGING_HOST}\"}}" -s | jq -r '.scan.id')
      curl -k -X POST "${NESSUS_URL}/scans/${SCAN_ID}/launch" -H "X-API-Token: ${TOKEN}" -s
    - sleep 600  # Wait 10 minutes for scan completion (or implement polling)
    - |
      # Retrieve critical/high count
      VULN_COUNT=$(curl -k -X GET "${NESSUS_URL}/scans/${SCAN_ID}" \
        -H "X-API-Token: ${TOKEN}" -s | jq '.info.severity_counts.critical + .info.severity_counts.high')
    - echo "Critical/High vulnerabilities found: ${VULN_COUNT}"
    - if [ "${VULN_COUNT}" -gt 0 ]; then exit 1; fi
  allow_failure: false

Understanding Scan Results

Nessus findings are structured hierarchically: each scan contains one or more host records, each host contains vulnerability instances, and each vulnerability references a plugin ID with detailed remediation guidance. Understanding this structure is essential for building effective automation around Nessus.

Vulnerability Severity and Exploitability

Each finding carries a severity level and, crucially, a "Vulnerability Priority Rating" (VPR) in Professional editions. The VPR combines CVSS score with exploit code maturity, malware associations, and report prevalence to give a more actionable ranking than CVSS alone. Developers should prioritize findings with high VPR values over raw CVSS scores, as VPR better reflects real-world risk.

Parsing Nessus XML Programmatically

When you export results in .nessus format, you get an XML document that can be parsed with standard libraries. Here's a Python example that extracts all critical findings across hosts:

import xml.etree.ElementTree as ET
import json

def parse_nessus_report(filepath):
    """Extract critical and high vulnerabilities from a .nessus export."""
    tree = ET.parse(filepath)
    root = tree.getroot()
    
    findings = []
    
    for report_host in root.findall('.//ReportHost'):
        host_ip = report_host.get('name')
        hostname = report_host.find('.//tag[@name="hostname"]')
        hostname_value = hostname.text if hostname is not None else host_ip
        
        for report_item in report_host.findall('.//ReportItem'):
            severity = report_item.get('severity', '0')
            plugin_id = report_item.get('pluginID')
            plugin_name = report_item.get('pluginName')
            
            # Only collect critical (4) and high (3) severity
            if int(severity) >= 3:
                description = report_item.find('description')
                solution = report_item.find('solution')
                cvss_vector = report_item.find('cvss_vector')
                
                finding = {
                    'host': hostname_value,
                    'ip': host_ip,
                    'plugin_id': plugin_id,
                    'plugin_name': plugin_name,
                    'severity': severity,
                    'description': description.text if description is not None else '',
                    'solution': solution.text if solution is not None else '',
                    'cvss_vector': cvss_vector.text if cvss_vector is not None else ''
                }
                findings.append(finding)
    
    return findings

# Usage
results = parse_nessus_report('scan_report_123.nessus')
print(json.dumps(results, indent=2))
print(f"Total critical/high findings: {len(results)}")

Working with the JSON Export Format

For newer integrations, request JSON export directly via the API by setting "format": "json" in the export payload. This avoids XML parsing overhead and integrates cleanly with modern data pipelines:

// Python snippet to fetch and process JSON export
import requests

NESSUS_URL = "https://nessus.corp.local:8834"
TOKEN = "your-api-token"
SCAN_ID = "123"

headers = {"X-API-Token": TOKEN, "Content-Type": "application/json"}

# Request JSON export
export_payload = {"format": "json", "chapters": "vuln_by_host"}
resp = requests.post(f"{NESSUS_URL}/scans/{SCAN_ID}/export", 
                     headers=headers, json=export_payload, verify=False)
file_id = resp.json()['file']

# Download when ready (polling omitted for brevity)
download_resp = requests.get(
    f"{NESSUS_URL}/scans/{SCAN_ID}/export/{file_id}/download",
    headers=headers, verify=False
)

vulnerability_data = download_resp.json()

# Group vulnerabilities by severity
from collections import defaultdict
by_severity = defaultdict(list)
for host in vulnerability_data.get('hosts', []):
    for vuln in host.get('vulnerabilities', []):
        by_severity[vuln['severity']].append({
            'host': host['hostname'],
            'plugin': vuln['plugin_name'],
            'solution': vuln.get('solution', 'N/A')
        })

print(f"Critical: {len(by_severity['critical'])}")
print(f"High: {len(by_severity['high'])}")
print(f"Medium: {len(by_severity['medium'])}")

Automation and API Integration Patterns

Beyond simple scan triggers, the Nessus API enables sophisticated workflows that treat vulnerability data as a first-class citizen in your development lifecycle.

Webhook-Driven Remediation Tracking

You can build a service that listens for scan completions and automatically creates tickets in Jira, ServiceNow, or GitHub Issues for each critical finding:

# Python Flask webhook receiver example
from flask import Flask, request
import requests
import os

app = Flask(__name__)

NESSUS_URL = os.environ.get("NESSUS_URL")
API_TOKEN = os.environ.get("NESSUS_API_TOKEN")
JIRA_URL = os.environ.get("JIRA_URL")

@app.route('/webhook/scan-complete', methods=['POST'])
def scan_complete():
    data = request.json
    scan_id = data.get('scan_id')
    
    # Fetch results from Nessus
    headers = {"X-API-Token": API_TOKEN}
    scan_info = requests.get(
        f"{NESSUS_URL}/scans/{scan_id}",
        headers=headers, verify=False
    ).json()
    
    critical_count = scan_info['info']['severity_counts'].get('critical', 0)
    
    if critical_count > 0:
        # Create a Jira ticket
        jira_payload = {
            "fields": {
                "project": {"key": "SEC"},
                "summary": f"Nessus Scan {scan_id}: {critical_count} Critical Findings",
                "description": f"Automated scan detected {critical_count} critical vulnerabilities.\nScan ID: {scan_id}\nReview at: {NESSUS_URL}/#/scans/{scan_id}",
                "issuetype": {"name": "Bug"}
            }
        }
        requests.post(
            f"{JIRA_URL}/rest/api/2/issue",
            json=jira_payload,
            auth=('jira_user', os.environ.get('JIRA_PASS'))
        )
    
    return {"status": "processed"}, 200

if __name__ == '__main__':
    app.run(port=5000)

Scheduled Scan Orchestration with Cron and API

While Nessus has built-in scheduling, external orchestration via cron allows you to coordinate scans with maintenance windows, backup completion, or deployment events:

#!/bin/bash
# /etc/cron.d/nessus-orchestration
# Runs every night at 2 AM after backup window closes
0 2 * * * root /usr/local/bin/nessus-scheduled-scan.sh

# --- nessus-scheduled-scan.sh ---
#!/bin/bash
TOKEN=$(curl -k -X POST "${NESSUS_URL}/session" \
  -H "Content-Type: application/json" \
  -d "{\"username\":\"${NESSUS_USER}\",\"password\":\"${NESSUS_PASS}\"}" -s | jq -r '.token')

# Scan production subnet
curl -k -X POST "${NESSUS_URL}/scans" \
  -H "Content-Type: application/json" \
  -H "X-API-Token: ${TOKEN}" \
  -d '{
    "settings": {
      "name": "Prod-Nightly-Scan",
      "policy_id": 5,
      "text_targets": "10.0.100.0/24",
      "launch": "ONETIME"
    }
  }' -s | jq '.scan.id' > /tmp/current_scan_id

# Log to syslog
logger -t nessus-orchestration "Launched nightly scan with ID: $(cat /tmp/current_scan_id)"

Best Practices

Adopting Nessus effectively requires more than just running scans. The following best practices will help you maximize detection accuracy, minimize operational disruption, and integrate vulnerability management seamlessly into your development lifecycle.

1. Tune Scan Policies to the Environment

Never run the default "All Plugins" policy against production without careful consideration. Aggressive plugins can overwhelm services, trigger IDS alerts, or cause performance degradation. Segment your scanning policies by asset type:

• Web Servers – Enable web-focused plugins (CGI, OWASP checks), disable database brute-force plugins.
• Database Servers – Include database-specific families, but avoid web application tests.
• Network Infrastructure – Focus on service detection, missing patches, and configuration audits.
• Staging/Development – You can safely run more aggressive plugins here, including credentialed checks with full root access.

2. Use Credentialed Scanning Wherever Possible

Uncredentialed scans see only what an attacker sees from the outside. Credentialed scans log into each target (via SSH, SMB, or agent) and enumerate installed packages, file permissions, registry entries, and local configurations. This increases finding accuracy by 40–60% and dramatically reduces false negatives. Store credentials securely within Nessus's encrypted credential vault or retrieve them at runtime via a secrets manager integration.

3. Implement Rate Limiting and Scan Windows

Production scans should be throttled to avoid saturating network links or CPU on critical systems. Configure these parameters in your scan policy:

// Advanced scan settings for production safety
{
  "advanced": {
    "max_checks_per_host": 3,
    "max_hosts": 10,
    "min_time_between_scans": 15,
    "scan_delay": 30,
    "parallel_scans": 1,
    "safe_checks": "yes",
    "stop_unreachable": "yes",
    "scan_timeout": 3600
  }
}

4. Treat Findings as Code

Version your Nessus scan policies and export scripts alongside your application code. Use infrastructure-as-code principles to define what a "clean" scan looks like, and gate deployments on scan results. Store policy JSON definitions in your repository and push them to Nessus via the API as part of your provisioning pipeline.

5. Deduplicate and Suppress Intelligently

Not every finding requires immediate action. Use Nessus's built-in "Accepted Risk" and "False Positive" marking capabilities to suppress findings that have been reviewed and deemed acceptable. This keeps your vulnerability dashboard actionable and prevents alert fatigue. For API-driven workflows, maintain a suppression list in your codebase that filters known false positives before generating tickets:

# Example suppression list used in post-processing
SUPPRESSED_PLUGINS = {
    '11213': 'Internal IP disclosure - expected in private subnet',
    '42263': 'Self-signed cert on internal dev endpoint',
    '57608': 'HTTP TRACE method enabled - required for legacy app'
}

def filter_suppressed(findings):
    return [f for f in findings if f['plugin_id'] not in SUPPRESSED_PLUGINS]

6. Monitor Plugin Freshness

Nessus plugins are updated daily. A scanner with outdated plugins misses newly disclosed vulnerabilities. Automate a health check that verifies plugin age:

#!/bin/bash
# Check plugin freshness and alert if older than 48 hours
TOKEN=$(curl -k -X POST "${NESSUS_URL}/session" \
  -H "Content-Type: application/json" \
  -d "{\"username\":\"${NESSUS_USER}\",\"password\":\"${NESSUS_PASS}\"}" -s | jq -r '.token')

PLUGIN_DATE=$(curl -k -X GET "${NESSUS_URL}/server/properties" \
  -H "X-API-Token: ${TOKEN}" -s | jq -r '.plugin_set_timestamp')

# Convert timestamp to epoch and compare
PLUGIN_EPOCH=$(date -d "${PLUGIN_DATE}" +%s)
NOW_EPOCH=$(date +%s)
AGE_HOURS=$(( (NOW_EPOCH - PLUGIN_EPOCH) / 3600 ))

if [ ${AGE_HOURS} -gt 48 ]; then
  echo "WARNING: Nessus plugins are ${AGE_HOURS} hours old. Triggering update..."
  curl -k -X POST "${NESSUS_URL}/server/plugins/update" \
    -H "X-API-Token: ${TOKEN}" -s
fi

7. Segment Scanning Infrastructure

Place your Nessus scanner on a dedicated management VLAN with direct network paths to all target subnets. Ensure firewall rules allow the scanner's source IP to reach target ports but restrict the scanner's own management interface (port 8834) to a secure jump host or VPN. Never expose the Nessus web interface directly to the internet.

8. Integrate with SIEM and Logging Platforms

Forward scan results to your SIEM (e.g., Splunk, Elastic) for correlation with runtime events. A critical vulnerability combined with an active intrusion detection alert becomes an actionable incident. Use the export API to push structured JSON to your SIEM via HTTP Event Collector or log file ingestion.

Conclusion

Nessus is far more than a checkbox compliance scanner—it is a foundational tool for developers and engineers committed to building resilient systems. By mastering its installation, configuring precise scan policies, leveraging the REST API for pipeline automation, and adopting the best practices outlined here, you transform vulnerability assessment from a periodic audit into a continuous, code-driven feedback mechanism. The combination of Nessus's deep plugin coverage with developer-friendly API extensibility makes it an ideal fit for modern DevSecOps workflows. Start with a single staged integration—perhaps a nightly scan of your staging environment with results posted to your team's Slack channel—and iterate toward fully automated, policy-gated deployments that refuse to promote code when critical vulnerabilities are present. In a landscape where new vulnerabilities emerge daily, this proactive posture is not optional; it's essential.