Ellipse Gradient for Header

Tenable Integration Guide

Integrate Tenable vulnerability, asset, scan, and finding data with enterprise systems through REST APIs, asynchronous exports, and product-specific notifications.

Tenable integration options at a glance

Tenable primarily integrates through REST APIs for assets, findings, vulnerabilities, scans, tags, plugins, policies, users, and related resources. Its bulk export operations support asynchronous processing of large asset and vulnerability datasets by creating an export, polling its status, and retrieving result chunks. Product-specific notification or callback capabilities may exist, but a universal webhook stream is not confirmed and should be validated for the selected Tenable product. Tenable Vulnerability Management commonly authenticates with access and secret keys in the X-ApiKeys header. Martini can securely consume these APIs, orchestrate polling and exports, transform responses, and expose normalized APIs to downstream systems.

Integration pointSupported by Tenable?Common use casesHow Martini supports it
REST APIsYesManage and retrieve Assets, Findings, Vulnerabilities, Scans, Tags, Plugins, Policies, Users, and related Tenable resources. Availability varies by Tenable product and deployment type.Martini can consume Tenable REST endpoints, manage pagination, map responses, apply business rules, and call downstream APIs.
Bulk / async / batch APIsYesCreate asynchronous export jobs for large asset and vulnerability or finding datasets, then retrieve prepared result chunks.Martini can create exports, poll status, process chunks incrementally, and persist export and chunk checkpoints.
Webhooks / outbound callbacksLimitedSome Tenable products provide notification or integration capabilities, but a universal stream for all Asset, Finding, Scan, and configuration changes is not confirmed.Martini can receive a documented product-specific callback when available; otherwise it can use scheduled polling or export workflows.
File / attachment APIsLimitedTenable documents file-oriented resources such as audit files and export chunks, but not a general attachment API for every object.Martini can retrieve, process, and route supported files or chunks using workflow transformations and controlled downstream delivery.
AuthenticationYesTenable Vulnerability Management commonly uses access and secret API keys in the X-ApiKeys header; permissions follow the associated Tenable user.Martini stores credentials as protected secrets and applies environment-specific API configuration without embedding keys in workflows.
GraphQL APIsNot confirmedNo official Tenable GraphQL API was confirmed in the reviewed material.Martini should use the documented Tenable REST APIs rather than assume GraphQL availability.
SOAP APIsNoNo official Tenable SOAP API was confirmed; the current documented integration model is REST-based.Martini can consume SOAP services generally, but Tenable integrations should use confirmed REST or export mechanisms.
Database / analytics accessNot confirmedDirect database or JDBC access to Tenable data was not confirmed.Martini can write normalized Tenable data to an approved database or analytics destination after retrieving it through Tenable APIs or exports.

How Tenable exposes data and business events

Tenable REST APIs

REST is Tenable's primary documented integration mechanism for cloud vulnerability-management operations. The API reference covers resources such as Assets, Findings, Scans, Tags, Plugins, Policies, Users, and exports, although endpoints and permissions vary by Tenable product.

Martini implementation pattern

Martini implementation pattern: a workflow authenticates with protected Tenable credentials, retrieves paginated resources, validates product-specific response fields, maps them to a canonical model, and invokes downstream APIs or writes to a target store.

Implementation sequence

Select the Tenable product and applicable API version
Load the regional or product-specific base URL and protected API keys
Call the required Tenable REST resource
Follow pagination until the collection is complete
Validate and transform the response
Apply routing and idempotency rules and write the target result

Tenable asynchronous exports

Tenable provides export operations for large asset and vulnerability or finding datasets. Export creation, status polling, and chunk retrieval are separate operations and are more suitable for initial loads or large reconciliations than one request per object.

Martini implementation pattern

Martini implementation pattern: a workflow creates an export, persists the export identifier, polls at a controlled interval, retrieves available chunks, processes each chunk independently, and records restartable checkpoints.

Implementation sequence

Create the Tenable export request
Persist the export identifier and synchronization context
Poll export status with a controlled backoff
Retrieve each available result chunk
Transform and deliver chunk data
Persist the last successful chunk checkpoint

Tenable notifications and callbacks

Some Tenable products offer notification or integration capabilities, but a universal webhook stream for all Asset, Finding, Scan, and configuration changes is not confirmed. Event coverage must be validated for the selected product and event type.

Martini implementation pattern

Martini implementation pattern: where Tenable provides a documented callback, Martini receives the notification through an API workflow, retrieves authoritative resource data, and processes it idempotently. If no suitable callback exists, a scheduled REST polling workflow uses filters or checkpoints instead.

Implementation sequence

Confirm the Tenable product and supported notification event
Receive the documented callback when available
Retrieve the authoritative Tenable resource
Map the event to the canonical model
Apply deduplication and business rules
Use scheduled polling when callback coverage is unavailable

Tenable scan orchestration

Tenable REST APIs may allow permitted users to start and monitor Scans or assessment operations. Whether execution is available depends on the product, endpoint, Scan or Policy permissions, and deployment configuration.

Martini implementation pattern

Martini implementation pattern: an exposed Martini API validates the request and permitted Scan or Policy, invokes Tenable, stores the returned scan identifier, and starts a separate status-monitoring workflow that reports completion or failure.

Implementation sequence

Receive an authorized scan request
Validate the permitted Scan, Policy, and target scope
Start the Tenable operation
Store the returned scan identifier
Poll status without excessive frequency
Publish completion, cancellation, or failure status

Common Tenable integration patterns

Pattern 1: Sync Tenable findings to ServiceNow

When to use this pattern

Use this pattern to create or update remediation work from Tenable Findings while preserving ownership, severity, and lifecycle state. It is appropriate for scheduled incremental retrieval or export-based processing.

Integration direction
Tenable
Martini
ServiceNow
Example Mapping
Tenable FieldCanonical FieldTarget Field
finding.idexternalFindingIdu_tenable_finding_id
severityprioritypriority
asset.hostnameaffectedHostcmdb_ci
statevulnerabilityStatestate
Martini implementation pattern

A scheduled workflow retrieves changed Findings or processes export chunks, enriches them with Assets, Plugins, and Tags, maps Tenable severity to ServiceNow priority, routes by ownership, and upserts using a deterministic finding and asset key. Transient API failures are retried, while duplicate chunks and reopened findings are handled idempotently.

Martini capabilities used
  • workflows
  • API consumption
  • scheduling
  • data mapping
  • business rules
  • error handling

Pattern 2: Synchronize Tenable assets to an inventory system

When to use this pattern

Use this pattern to populate or reconcile an enterprise asset inventory with Tenable-assessed hosts, cloud resources, containers, and related metadata.

Integration direction
Tenable
Martini
ServiceNow
Example Mapping
Tenable FieldCanonical FieldTarget Field
asset.idassetIdentifiercorrelation_id
hostnamehostNamename
operating_systemoperatingSystemos
tagsclassificationTagsu_tenable_tags
Martini implementation pattern

Martini performs an initial export for full population, then retrieves filtered or incremental Asset data where supported. It normalizes asset-type-specific fields, maps Tags and cloud identifiers, applies upsert rules, and records checkpoints so interrupted pages or chunks can be replayed safely.

Martini capabilities used
  • workflows
  • API consumption
  • bulk processing
  • data mapping
  • checkpointing
  • retry handling

Pattern 3: Publish Tenable vulnerability data to Splunk

When to use this pattern

Use this pattern when security operations needs normalized Tenable exposure data for correlation, reporting, and investigation across security telemetry.

Integration direction
Tenable
Martini
Splunk
Example Mapping
Tenable FieldCanonical FieldTarget Field
finding.plugin.iddetectionIdplugin_id
finding.severityseverityseverity
asset.idresourceIdasset_id
finding.statelifecycleStatefinding_state
Martini implementation pattern

A Martini workflow creates or retrieves an asynchronous Tenable export, processes chunks incrementally, enriches Findings with Asset and Plugin context, transforms the result into the agreed Splunk ingestion shape, and retries transient delivery errors without duplicating accepted events.

Martini capabilities used
  • workflows
  • asynchronous orchestration
  • data transformation
  • business rules
  • batch processing
  • error handling

Pattern 4: Orchestrate an approved Tenable scan

When to use this pattern

Use this pattern when an external application needs a controlled API-led way to request a Tenable scan and receive a later completion or failure result.

Integration direction
External application
Martini
Tenable
Example Mapping
Tenable FieldCanonical FieldTarget Field
requested_scan_idscanIdscan_id
requested_policy_idpolicyIdpolicy_id
target_scopevalidatedTargetScopetargets
scan_statusexecutionStatusstatus
Martini implementation pattern

Martini exposes a protected API, validates the requested Scan, Policy, and target scope, applies authorization and concurrency controls, starts the permitted Tenable operation, and persists the scan identifier. A separate workflow polls status and sends the result to the requesting system, handling canceled, failed, and partially completed states.

Martini capabilities used
  • API exposure
  • workflows
  • API consumption
  • validation
  • business rules
  • asynchronous execution

Applications commonly integrated with Tenable

Tenable data is commonly routed into security operations, remediation, analytics, cloud-security, and collaboration platforms. The exact integration method depends on the Tenable product, licensed capabilities, and the target application's API.

Application Scenario Direction Martini Pattern
ServiceNow Create or update vulnerability and remediation tasks, route findings to configuration items and owners, and track remediation status. Tenable → Martini → ServiceNow A scheduled Martini workflow retrieves Findings or asynchronous export chunks, maps severity, asset, Plugin, state, and remediation details, then upserts ServiceNow records using a stable Tenable-derived key. Status updates can be returned through a separate workflow.
Jira Create remediation issues for development, infrastructure, and security teams from Tenable Findings. Tenable → Martini → Jira Martini polls or exports Findings, applies routing rules based on severity, Tags, and ownership, maps the result to Jira issue fields, and updates existing issues idempotently through the Jira REST API.
Splunk Ingest Tenable assets, vulnerabilities, and scan information for security operations, correlation, and reporting. Tenable → Martini → Splunk A Martini workflow retrieves Tenable data or export chunks, normalizes product-specific schemas, enriches events with Tags and asset context, and publishes the resulting payloads to the approved Splunk ingestion interface with retry handling.
Microsoft Sentinel Send Tenable vulnerability and exposure information into security analytics and incident workflows. Tenable → Martini → Microsoft Sentinel Martini incrementally retrieves Findings and Assets, maps severity and resource identifiers to the Sentinel data model, validates required fields, and submits batches while recording checkpoints and transient failures.
Microsoft Defender XDR Correlate Tenable vulnerability context with endpoint and identity security information. Tenable → Martini → Microsoft Defender XDR Martini retrieves Tenable Findings and Assets, resolves stable device or resource identifiers where available, applies correlation rules, and sends normalized enrichment to approved Microsoft security APIs.
AWS Security Hub Combine Tenable cloud or vulnerability findings with AWS security findings and centralized cloud-security workflows. Tenable → Martini → AWS Security Hub A workflow transforms Tenable findings into the target Security Hub shape, maps severity and resource metadata, validates account and region context, and performs idempotent publishing with checkpointed retries.
Microsoft Teams Notify responsible teams about high-severity findings, scan failures, or remediation milestones. Tenable → Martini → Microsoft Teams Martini polls Tenable or consumes a validated product-specific notification, applies severity and ownership rules, and sends concise Teams messages through the approved Teams integration endpoint while suppressing duplicates.
Slack Send operational notifications for critical findings, scan completion, or remediation escalation. Tenable → Martini → Slack A Martini workflow retrieves or receives qualifying Tenable events, enriches them with asset and Tag context, formats a Slack-compatible message, and records a notification key to prevent repeated alerts.

How to build a Tenable integration in Martini

Objective

Identify the Tenable product, API version, regional endpoint, and permissions required for the integration, then configure credentials without embedding them in workflow definitions.

Instructions in Martini

  • Select the applicable Tenable product and API surface
  • Store the access key and secret key as protected Martini secrets
  • Configure the product-specific base URL as environment configuration
  • Use separate credentials for reporting, synchronization, and scan administration where appropriate

Objective

Select scheduled polling, asynchronous export processing, or a validated product-specific callback based on the event coverage and data volume available in Tenable.

Instructions in Martini

  • Use a scheduler for incremental REST retrieval when no suitable callback exists
  • Use export workflows for large initial loads and reconciliations
  • Use a callback workflow only after confirming the Tenable product and event type
  • Set polling intervals that respect operational constraints

Objective

Call the relevant Tenable REST resource or export operation and retrieve complete, authoritative data without assuming that one response contains the full collection.

Instructions in Martini

  • Follow pagination for collection endpoints
  • Create and monitor export jobs for high-volume datasets
  • Retrieve related Assets, Plugins, Tags, or Scan status when required
  • Persist resource, export, and chunk checkpoints

Objective

Coordinate Tenable retrieval, enrichment, target delivery, and checkpoint updates as a restartable Martini workflow.

Instructions in Martini

  • Separate export creation, polling, and chunk processing stages
  • Apply bounded concurrency and controlled polling
  • Keep product-specific API logic isolated from downstream mapping
  • Route transient and permanent failures differently

Objective

Convert Tenable Assets, Findings, Vulnerabilities, Scans, Tags, and Plugins into a canonical model and target-specific payloads.

Instructions in Martini

  • Map identifiers, severity, state, asset context, and remediation fields
  • Handle nullable and asset-type-specific fields
  • Use JSON transformations for API payloads
  • Preserve stable external identifiers for future updates

Objective

Apply authorization, severity, ownership, scope, deduplication, and scan-safety rules before writing or executing downstream actions.

Instructions in Martini

  • Route by Tags, asset ownership, business unit, or severity
  • Validate Scan and Policy identifiers before execution
  • Use deterministic keys for idempotent writes
  • Reject unauthorized or malformed requests without indefinite retries

Common Tenable data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
AssetsSynchronize devices, hosts, cloud resources, containers, and other assessed resources with inventory or security platforms.ServiceNow, Splunk, Microsoft Sentinel, AWS Security Hub, databasesMartini retrieves paginated results or export chunks, normalizes asset-type-specific fields, maps Tags and identifiers, and applies idempotent upserts.
FindingsCreate remediation work, security events, reports, and notifications from vulnerability observations associated with Assets.ServiceNow, Jira, Splunk, Microsoft Sentinel, Microsoft TeamsMartini maps Plugin, severity, state, asset, evidence, and remediation data, derives stable keys, and handles reopened or fixed states.
VulnerabilitiesAnalyze vulnerability summaries and remediation exposure across assessed resources.Security analytics platforms, data warehouses, Splunk, Microsoft SentinelMartini retrieves or exports high-volume data, transforms product-specific schemas, processes chunks incrementally, and stores synchronization checkpoints.
ScansTrack configured or executed vulnerability scans, targets, schedules, statuses, and results.ServiceNow, Teams, Slack, operational databasesMartini can initiate permitted scans through the REST API, store scan identifiers, poll status separately, and route completion or failure notifications.
TagsClassify Assets and support filtering, ownership routing, reporting, and workflow decisions.ServiceNow, Jira, Splunk, internal data storesMartini uses Tags as enrichment and routing inputs, preserves their relationship to Assets, and avoids assuming consistent availability across products.
PluginsRepresent detection definitions used to identify vulnerabilities and configuration issues.ServiceNow, Jira, security analytics platformsMartini maps Plugin identifiers and descriptive fields into finding or remediation payloads while treating optional fields defensively.

Authentication and security considerations

API keys and permissions

Tenable Vulnerability Management commonly uses an access key and secret key in the X-ApiKeys request header. The associated Tenable user determines access to Assets, Findings, Scans, Tags, exports, and administrative resources.

Credential protection

Store Tenable credentials as protected Martini secrets. Do not place keys in workflow parameters, source-controlled mappings, logs, or error payloads. Rotate long-lived keys according to organizational policy.

Product-specific security

Authentication and authorization can vary across Tenable Vulnerability Management, Security Center, Tenable One, Web App Scanning, Cloud Security, and other products. Confirm the applicable product endpoint, API version, permissions, and credential model before deployment.

  • Use separate least-privilege credentials for reporting, synchronization, scan orchestration, and administration.
  • Protect Martini APIs that expose normalized Tenable data or accept scan requests.
  • Keep regional and product-specific endpoints in environment configuration.

Operational considerations for Tenable integrations

Rate limits and pagination

Confirm applicable Tenable limits for the product and subscription. Use bounded concurrency, backoff for throttling responses, and complete pagination rather than assuming the first response contains all data.

Exports and checkpoints

For large datasets, create asynchronous exports, poll at a controlled interval, process chunks incrementally, and persist export identifiers and last successful chunks. Checkpoints should be restartable and isolated by tenant and resource type.

Idempotency and schema changes

Use stable identifiers or composite finding keys, tolerate repeated pages and chunks, and support reopened or fixed Finding states. Validate nullable fields, product-specific structures, severity values, and pagination or export formats.

Retries and testing

  • Retry transient rate-limit and service failures with bounded backoff.
  • Surface authentication, permission, invalid-resource, and malformed-response failures for operator action.
  • Validate Scan and Policy scope and prevent unsafe concurrent scans.
  • Test against the actual Tenable product, API version, permissions, regional endpoint, and representative data volumes.

Why use Martini instead of scripts or point-to-point integrations?

Orchestration instead of isolated scripts

Martini centralizes Tenable API calls, asynchronous export processing, pagination, transformations, business rules, and downstream delivery in maintainable workflows. This avoids duplicating authentication, retry, checkpoint, and error-handling logic across scripts.

Canonical data and reusable APIs

Martini can isolate product-specific Tenable schemas from target applications by mapping Assets, Findings, Scans, Tags, Plugins, and related resources into canonical models. It can also expose controlled APIs for normalized data or approved scan operations.

Operational reliability

  • Schedule incremental synchronization and coordinate long-running exports.
  • Apply idempotency, validation, routing, and controlled retries consistently.
  • Use protected secrets and environment configuration across deployments.
  • Monitor workflow execution and troubleshoot failures without creating separate point-to-point implementations.

Frequently asked questions

How can Tenable be integrated with enterprise systems?

Tenable is primarily integrated through product-specific REST APIs for Assets, Findings, Vulnerabilities, Scans, Tags, Plugins, Policies, Users, and related resources. Large datasets can use asynchronous export jobs that are created, polled, and retrieved in chunks. Product-specific notification capabilities may be available, but universal webhook coverage is not confirmed.

Can Martini integrate with Tenable?

Yes. Martini can consume Tenable REST APIs, authenticate with protected Tenable API keys where applicable, orchestrate pagination and asynchronous exports, transform Tenable objects, and deliver normalized data to enterprise applications or data stores.

Do I need a connector to integrate Tenable with Martini?

No. A dedicated Tenable connector is not required. Martini can use Tenable's confirmed REST APIs, asynchronous exports, supported product-specific callbacks, and authentication methods through workflows and API integrations.

Is there any extra Lonti cost to integrate Tenable with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Tenable. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Tenable, cloud infrastructure, or other third-party systems based on subscriptions, usage, and deployment model.

Which Tenable integration methods should be used?

Use the REST API for operational resources and incremental retrieval, and use asynchronous export APIs for large asset or vulnerability datasets. Authentication for Tenable Vulnerability Management commonly uses access and secret keys in the X-ApiKeys header. GraphQL and SOAP were not confirmed as Tenable integration methods.

Are Tenable webhooks or event callbacks available?

Some Tenable products provide notification or integration capabilities, but a universal webhook stream for all Assets, Findings, Scans, and configuration changes is not confirmed. Validate the event type for the deployed product; otherwise use scheduled polling, filters, timestamps, or export checkpoints.

How should Tenable data synchronization handle large volumes and duplicates?

Use asynchronous exports where available, process result chunks incrementally, and persist export and synchronization checkpoints. Use stable Tenable identifiers or composite keys for Findings, apply an overlap window for incremental retrieval, and make target writes idempotent so retries do not create duplicates.

Can Martini expose an API façade for Tenable?

Yes. Martini can expose a controlled REST API that normalizes Tenable data or accepts approved scan requests. The façade can validate callers, hide Tenable credentials, apply business rules and scope restrictions, orchestrate Tenable REST calls, and return a consistent enterprise-facing response.

Related Martini documentation

API Workflows

Data Processing

Security

Reliability

Integrate Tenable with Martini

Use Martini to build secure, maintainable Tenable integrations for vulnerability data synchronization, remediation workflows, asynchronous exports, and controlled scan orchestration.

EXPLORE MARTINI
BOOK A DEMO