wif.tax

Tenable

D Tenable Vulnerability Management / Tenable One cloud API

The Tenable One / Vulnerability Management API (cloud.tenable.com) accepts only a static access key and secret key pair per user, sent in the X-ApiKeys header. Keys never expire and are not reported to GitHub, but they can be regenerated via the API, held by an API-only user with a custom role, and show a last-used time. Into your cloud it is keyless on AWS and GCP, while the Azure connector wants a client secret.

Docs: developer.tenable.com · Checked 2026-10-22 · source YAML · dispute via PR

Inbound D

How a workload running anywhere authenticates to this product.

One static access key + secret key pair per Tenable user account, sent as "X-ApiKeys: accessKey=...; secretKey=..." to cloud.tenable.com. The same pair covers every licensed Tenable One product on the container. No OIDC, workload identity or token-exchange path exists.

Graded on the cloud.tenable.com platform API that Vulnerability Management, Web App Scanning, Exposure Management and the cloud connectors are automated through; every OpenAPI spec checked on the developer portal declares the single X-ApiKeys security scheme, and nothing documents OIDC, GitHub Actions, cloud workload identity or a token exchange. SAML SSO exists for humans only. The optional API IP allowlist (API Access Security) narrows where a key works but does not change that it is a long-lived secret. Each user holds only one key pair at a time, so rotation is a hard cut-over with no overlap window. Tenable One Cloud Exposure (ex-Ermetic) has its own GraphQL API documented only behind a login, so its auth is not publicly verifiable and is not graded here. Inbound moves to B or A only if the platform accepts a federated token. No tier gate: API keys come with every subscription.

Outbound B

How this product reaches into your cloud, repos, or other SaaS.

Vulnerability Management cloud connectors are keyless on AWS (an IAM role named tenableio-connector trusting Tenable's AWS account, with your container ID as External ID) and on GCP (a Workload Identity Federation pool trusting Tenable's AWS role, which impersonates your service account). The Azure connector only takes an app registration's client secret; keyed AWS (access key) and GCP (service-account JSON key) options also remain.

Checked: Vulnerability Management cloud connectors (AWS keyed `aws`, AWS keyless `aws_keyless`, AWS and Azure Frictionless Assessment `aws_fa`/`azure_fa`, Azure `azure`, GCP keyed `gcp`, GCP Workload Identity Federation `gcp_keyless`); Tenable One Exposure Management third-party connectors (Microsoft Defender for Cloud shown: Entra app client secret; other SaaS connectors similarly take the source tool's API credentials); Attack Surface Management cloud integrations (keyless options for AWS, Azure and GCP); Tenable Cloud Security / Cloud Exposure onboarding. AWS and GCP are keyless (external ID on AWS; on GCP the trust is Tenable's AWS role via WIF, not a key). The VM Azure connector and its Frictionless Assessment variant both take a tenant ID, application ID and client secret, with no keyless option, which holds outbound at B. Tenable Cloud Security's own docs moved behind a login (the old docs.tenable.com/tenablecs pages now redirect to an EOL notice), so its onboarding is not publicly verifiable from Tenable; a third-party walkthrough shows Azure onboarding as Global Administrator consent plus role assignments to Tenable's multi-tenant "Tenable Cloud Security Connector" app (keyless); AWS and GCP onboarding for Cloud Security could not be checked. A keyless (federated credential or multi-tenant app) option on the VM Azure connector would lift outbound to A.

Hygiene for any static credential the product still issues

✗ Expiry enforceable
Fails: no expiry can be set on a key. The Generate API keys endpoint takes only the user ID and returns accessKey and secretKey, the UI has no expiry field, and Tenable's security best-practices guide leaves rotation to the customer. User accounts expire only with the container's license. An org-enforced maximum key lifetime would flip this check.
  • docs.tenable.com checked 2026-10-22
    “Tenable recommends that your organization periodically rotates API keys in a manner that aligns with your organization's risk tolerance and operational requirements.”
  • developer.tenable.com checked 2026-10-22
    “Generates the API keys for a user.”
✓ Rotation via API
PUT /users/{user_id}/keys mints a new pair and kills the old one, and PUT /users/{user_id}/authorizations can switch API access off, so rotation and revocation can be scripted. Because a user holds only one pair, the new key must be deployed at the same moment the old one dies; there is no overlap.
  • developer.tenable.com checked 2026-10-22
    “Generates the API keys for a user.”
  • developer.tenable.com checked 2026-10-22
    “Each account can only have one API key at a time, so new keys invalidate existing keys.”
  • developer.tenable.com checked 2026-10-22
    “Specifies whether API key authentication is authorized for the user.”
✓ Scoped keys
Keys have no scopes of their own and inherit the owning user's role and permissions. Passed because Tenable documents an API-only user account (API Key authorization only, no password or SAML login) that can be given a narrow built-in role (e.g. Read-Only) or a custom role plus asset permissions, the same call as material-security's dedicated service account. A key on a human administrator's account carries all of that admin's access.
  • docs.tenable.com checked 2026-10-22
    “Tip: You can select only this setting to create an API-only user account.”
  • docs.tenable.com checked 2026-10-22
    “API keys are scoped to the user's role and permission for which they are generated.”
  • docs.tenable.com checked 2026-10-22
    “Custom roles allow you to create and manage user roles with precisely defined permissions tailored to your organization’s operational and security needs.”
✓ Last-used visible
GET /users and GET /users/{id} return last_apikey_access, so unused keys can be found. It is per user, which equals per key because each user has one pair.
  • developer.tenable.com checked 2026-10-22
    “A timestamp in Unix milliseconds indicating the last time the user authenticated using API keys.”
✗ Leak revocation
Tenable does not appear in GitHub's supported secret scanning patterns table at all, so a leaked access/secret key pair is neither reported to Tenable nor flagged by default. The keys are bare 64-character hex strings with no prefix, which also makes them hard to detect.

Notes

One card for the cloud.tenable.com platform API shared by Tenable Vulnerability Management, Web App Scanning, Container Security and Tenable One Exposure Management; one key pair serves them all. Tenable Security Center (on-prem) has its own API keys and is not graded here. Three of five hygiene checks pass (rotation API, API-only users with custom roles, last API access), which keeps inbound at D; a key that can expire and GitHub partner revocation would add the other two. Inbound moves to B or A only if the platform accepts a federated token. Outbound moves to A with a keyless Azure connector.

Badge

wif.tax grade D

[![wif.tax grade](https://wif.tax/badge/tenable-vulnerability-management.svg)](https://wif.tax/p/tenable-vulnerability-management/)