canonical: https://jentic.com/apis/tenable.com/tenable-nessus # Tenable Vulnerability Management API (Nessus) Jentic publishes the only available OpenAPI specification for Tenable Vulnerability Management API (Nessus), keeping it validated and agent-ready. Configure and execute vulnerability scans, export findings, manage assets, and track remediation progress across 93 endpoints covering scan lifecycle management, plugin-based detection, agent management, and workbench analytics. The API provides programmatic access to Tenable's vulnerability database with severity-scored findings, CVSS ratings, and asset-level risk prioritization for infrastructure spanning on-premise servers, cloud instances, and containerized workloads. ## For AI agents Launch vulnerability scans, export scan results, manage asset inventories, and track remediation progress across network infrastructure through Tenable's Vulnerability Management platform. ## Scope Does not handle endpoint detection and response, SIEM correlation, or application code analysis - use for network vulnerability scanning and asset assessment only. ## Capabilities - Launch and schedule vulnerability scans with configurable scan templates, targets, and credentials - Export vulnerability findings in bulk with filtering by severity, plugin family, and asset group - Track asset inventory with tagging, network segmentation, and vulnerability history - Query the plugin database for specific CVEs, CWEs, and vulnerability signatures - Manage Nessus agents for distributed scanning across networks without direct connectivity - Organize scans into folders with shared access and configurable retention policies - Generate workbench reports aggregating vulnerability data by asset, severity, or plugin family ## Use cases ### AI Agent Vulnerability Assessment An AI agent uses the Tenable API through Jentic to orchestrate vulnerability assessments, launching scans against target networks, monitoring scan progress, and exporting findings with severity scores and remediation guidance. The agent identifies critical vulnerabilities by CVSS score, cross-references affected assets, and generates prioritized remediation lists - all without manually configuring API key headers or discovering scan template IDs. Example prompt: Launch a scan via POST /scans with a basic network scan template targeting a CIDR range, monitor status via GET /scans/{scanId}, then export results via POST /scans/{scanId}/export filtered to critical and high severity ### Continuous Vulnerability Monitoring Schedule recurring vulnerability scans across production infrastructure and track remediation progress over time. The API manages scan schedules, monitors completion status, and provides historical vulnerability data per asset. Security teams use the exports API to feed findings into ticketing systems, while workbench analytics reveal trends in vulnerability density and mean-time-to-remediation across organizational units. Example prompt: Create a scheduled scan via POST /scans with a weekly recurrence rule, then query GET /scans/{scanId}/history to compare vulnerability counts across the last 4 scan runs ### Asset-Based Risk Prioritization Build a risk-prioritized view of infrastructure by querying the asset inventory with vulnerability enrichment. The API provides per-asset vulnerability counts by severity, tracks which assets have the highest exposure, and enables bulk export of asset data for integration with CMDB systems. Tag-based grouping allows teams to segment risk reporting by business unit, environment, or criticality tier. Example prompt: Export the full asset inventory via POST /assets/export, check export status via GET /assets/export/{exportUuid}/status, then download chunks via GET /assets/export/{exportUuid}/chunks/{chunkId} ### Bulk Vulnerability Data Export Export large vulnerability datasets for offline analysis, compliance reporting, or SIEM ingestion. The chunked export API handles datasets with millions of findings by splitting results into downloadable chunks with status tracking. Exports can be filtered by date range, severity, plugin family, and asset tags to produce targeted datasets for specific compliance frameworks or audit requirements. Example prompt: Initiate a vulnerability export via POST /vulns/export with severity filter for 'critical', poll status via GET /vulns/export/{exportUuid}/status until complete, then download each chunk ## Key endpoints | Method | Path | Description | | --- | --- | --- | | POST | /scans | Create and configure a new vulnerability scan | | GET | /scans/{scanId} | Retrieve scan details and current status | | POST | /scans/{scanId}/export | Export scan results in specified format | | POST | /assets/export | Initiate bulk asset inventory export | | GET | /assets/export/{exportUuid}/status | Check asset export job status | | GET | /assets/export/{exportUuid}/chunks/{chunkId} | Download a chunk of exported asset data | | GET | /plugins | List available vulnerability detection plugins | | GET | /workbenches/assets | Query asset workbench with vulnerability summaries | ## Key resources - **Scans** — Create, launch, schedule, and retrieve results from vulnerability scans - **Assets** — Inventory managed assets with vulnerability counts, tags, and network metadata - **Exports** — Bulk export vulnerability findings and asset data in chunks for offline processing - **Plugins** — Query Tenable's plugin database for CVE-specific detection signatures - **Agents** — Manage distributed Nessus agents and agent groups for scanning segmented networks - **Folders** — Organize scans into folders with access controls and retention settings ## Why Jentic - **Setup:** Wiring the Tenable Vulnerability Management API by hand means learning its X-ApiKeys header auth (access key plus secret key) against the cloud.tenable.com host and handling scan, export, and chunked-download calls yourself. Through Jentic you install once, import the Tenable Vulnerability Management API from the API Directory, store the key pair once, and your agent calls it. - **Permission scoping:** This API puts the scan id in the URL path (/scans/{scanId}), so a rule can pin your agent to one scan: it can read and export that scan and nothing else. You choose the operations it may call, so launching new scans is not included unless you add it. - **Credential handling:** Your Tenable access key and secret key are stored once, encrypted, by your own Jentic One instance and injected at execution time. They never enter the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'scan hosts for vulnerabilities' or 'export scan results', and Jentic returns the matching Tenable operation with its input schema so the agent calls the right endpoint without browsing the reference docs. ## Related APIs - **Snyk API** — Application dependency vulnerability scanning that complements Tenable's infrastructure scanning - **CrowdStrike Falcon API** — Endpoint threat detection that complements Tenable's vulnerability assessment - **Rapid7 API** — Competing vulnerability management platform with similar scanning and asset tracking capabilities ## FAQ ### Why is there no official OpenAPI spec for Tenable Vulnerability Management API? Tenable does not publish an OpenAPI specification for their Vulnerability Management platform. Jentic generates and maintains this spec so that AI agents and developers can call Tenable's API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer. ### What authentication does the Tenable Vulnerability Management API use? The Tenable API uses API key authentication with two headers: X-ApiKeys containing both an accessKey and secretKey in the format 'accessKey={access_key};secretKey={secret_key}'. Through Jentic, both keys are stored encrypted in your Jentic One instance and agents receive properly formatted auth headers without raw keys entering context. ### Can I launch a vulnerability scan programmatically with the Tenable API? Yes. Use POST /scans to create a scan with a template UUID, target list (IPs, hostnames, or CIDR ranges), and optional credentials. Then launch it via POST /scans/{scanId}/launch. Monitor progress with GET /scans/{scanId} until status shows 'completed', then export results via POST /scans/{scanId}/export. ### What are the rate limits for the Tenable Vulnerability Management API? Tenable enforces rate limits based on your license tier. Standard accounts allow approximately 500 requests per minute for most endpoints. Export operations have separate concurrency limits (typically 2-3 concurrent exports). The API returns 429 status codes with Retry-After headers when limits are exceeded. ### How do I export vulnerability findings in bulk through Jentic? Search Jentic for 'export vulnerability scan results', which returns the POST /assets/export and related chunk download operations. Initiate an export with severity filters, poll the status endpoint until complete, then download each chunk sequentially. Install with pip install jentic and run it through Jentic One, the self-hosted execution layer. ### Can I manage Nessus agents through the API? Yes. The agent management endpoints let you list agents, create agent groups, assign agents to groups, and configure scan policies for agent-based scanning. Agent groups are useful for scanning hosts in network segments that lack direct connectivity from the scanner, such as DMZ or air-gapped environments. ### Does the API support querying by specific CVE? Yes. Use the GET /plugins endpoint to search for plugins by CVE ID, which returns the detection plugin details. The workbench endpoints also support filtering scan results by plugin ID or CVE to find all affected assets for a specific vulnerability across your infrastructure. ### Can I limit what my agent is allowed to do with the Tenable Nessus API? Yes. Because you run Jentic One yourself, your own rules decide which Tenable operations and credentials the agent may use. Since the scan id sits in the URL path, such as GET /scans/{scanId} and POST /scans/{scanId}/export, you can pin the agent to a single scan so it reads and exports that scan and nothing else. You pick the operations it may call, so launching new scans via POST /scans stays off unless you grant it.