PCI DSS compliance

Tenable plugin 33929 is *not* a CVE. It's a Nessus Policy Compliance plugin that fires when a host has any finding that constitutes an *automatic failure* under the PCI DSS Approved Scanning Vendors Program Guide v4.0 — for example any CVSS ≥4.0 vuln, unsupported OS, internet-reachable DB, default creds, XSS, SQLi, directory traversal, SSL/TLS below 1.2, or anonymous key exchange. It applies anywhere Nessus is configured to run a PCI ASV-style policy, so 'affected version range' is meaningless — it triggers whenever a *child* finding triggers.

Tenable labels it HIGH because PCI auditors treat an automatic-failure verdict as scan-blocking. But the plugin itself fixes nothing, exploits nothing, and represents zero attacker capability. It is a *meta-finding* — a checkbox that summarizes what your other plugins already told you. Treating it as a HIGH-severity vulnerability inflates your queue, hides the real bugs underneath, and wastes the patch team's attention. The vendor severity reflects *audit risk*, not *security risk* — and noisgate scores security risk.

Why this verdict

• Not a vulnerability: Plugin 33929 is a *Policy Compliance* roll-up; it has no CVE, no CWE, no CVSS vector, and no protocol-level reachability. Attackers cannot exploit a Nessus reporting artifact.
• Duplicate signal: Every condition that trips 33929 is already produced by the child plugin that caused it (e.g., a TLS 1.0 plugin, an EOL Windows plugin, a default-cred plugin). Treating both as HIGH double-counts the same risk.
• Role multiplier — none: The 'component' is a scan policy. There is no high-value-role variant (no DC, no hypervisor, no IdP equivalent) of a Nessus policy plugin. The deployment-role floor does not apply because no deployment role exists.
• Severity reflects audit risk, not attacker capability: Tenable's HIGH exists so PCI auditors see scan-failing findings. That is a *compliance* signal aimed at QSAs, not a *patch priority* signal aimed at vulnerability managers.

Why not higher?

It cannot be HIGH or above because there is no executable code path, no service, no CVE, and no attacker reachable surface in the plugin itself. Anything an attacker could do is captured by the child finding, which should be scored on its own merits.

Why not lower?

IGNORE *is* the floor. There is no lower bucket in the noisgate scale, and IGNORE is appropriate because the right operational response is to triage the underlying child findings, not to track 33929 as work.

1. Suppress plugin 33929 in vulnerability dashboards — In Tenable Security Center / Tenable.io, exclude plugin family *Policy Compliance* (or specifically plugin 33929) from your VM remediation queue so analysts work the underlying CVEs instead of the meta-finding. No mitigation SLA — this is a dashboard hygiene change, do it next sprint.
2. Route 33929 output to the GRC / PCI audit workstream — Forward the plugin's child-finding list to whoever owns PCI ASV scan submission. They need the report; the patch team does not need a duplicate HIGH ticket.
3. Triage the underlying child findings on their own merits — Open the 33929 output, pull each cited plugin ID / CVE, and reassess those individually. The TLS 1.0 finding, the EOL OS, the SQLi — each has its own real noisgate severity.
4. Tune your PCI ASV scan policy to your cardholder data environment scope — 33929 firing on hosts *outside* CDE scope is pure noise. Restrict the PCI policy to in-scope segments and exclude internal-only assets from ASV-grade evaluation.

Run this on your Tenable.sc / Nessus Manager API host (or any auditor workstation with curl + API keys) to enumerate which assets currently trip plugin 33929 and which *child* plugin IDs are actually responsible. Requires Tenable API access keys with scan-read scope. Invoke: TSC_URL=https://tsc.example.com TSC_AK=... TSC_SK=... ./check.sh

#!/usr/bin/env bash
# noisgate verifier: tenable:33929 (PCI DSS compliance rollup)
# Lists assets reporting plugin 33929 and surfaces the underlying child plugin IDs.
set -euo pipefail

: "${TSC_URL:?Set TSC_URL to https://<tenable-sc-host>}"
: "${TSC_AK:?Set TSC_AK to your access key}"
: "${TSC_SK:?Set TSC_SK to your secret key}"

AUTH="x-apikey: accesskey=${TSC_AK}; secretkey=${TSC_SK}"
PLUGIN_ID=33929

echo "[*] Querying Tenable.sc for hosts reporting plugin ${PLUGIN_ID}..."
RESP=$(curl -ksS -H "${AUTH}" \
  "${TSC_URL}/rest/analysis" \
  -H 'Content-Type: application/json' \
  -d "{\"type\":\"vuln\",\"query\":{\"tool\":\"listvuln\",\"filters\":[{\"filterName\":\"pluginID\",\"operator\":\"=\",\"value\":\"${PLUGIN_ID}\"}]},\"sourceType\":\"cumulative\"}")

COUNT=$(printf '%s' "$RESP" | grep -o '"ip"' | wc -l | tr -d ' ')

if [ "$COUNT" = "0" ]; then
  echo "[+] PATCHED  -- no hosts currently trip plugin ${PLUGIN_ID}"
  exit 0
fi

echo "[!] VULNERABLE -- ${COUNT} host(s) trip plugin ${PLUGIN_ID}"
echo "[*] Note: this is a *rollup* finding. Real work is in the child plugins it cites."
echo "[*] Pull the per-host plugin output to enumerate the underlying CVEs / plugin IDs:"
echo "     curl -ksS -H \"${AUTH}\" \"${TSC_URL}/rest/analysis\" -d '{...pluginID=${PLUGIN_ID}, tool=vulndetails...}'"
exit 1

# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN (env / auth failure)

Sources

1. Tenable plugin 33929 — PCI DSS compliance
2. Plugin 33929 changelog
3. Plugin 33929 dependencies
4. Tenable blog — PCI-DSS Plugins for Nessus
5. Tenable Community — purpose of plugin 33929
6. Tenable Community — solution for plugin 33929
7. PCI SSC — ASV Program Guide v4.0
8. Tenable docs — PCI ASV Workbench