# Tenable → FedRAMP POA&M Workbooks

> Build FedRAMP POA&M workbooks from Tenable.sc — a vulnerability POA&M enriched with team attribution and remediation context, plus STIG/CIS Configuration Findings.

- Type: Skill
- Author: conard0-git
- License: MIT
- Trust tier: contributed (passed automated validation and a baseline maintainer review)
- Last reviewed: 2026-08-13
- Source repository: https://github.com/conard0-git/tenable-fedramp-poam
- Repo state: not archived
- Last push: 2026-08-13T16:31:56Z
- Stars: 0 (a popularity signal, not a safety signal)
- Forks: 0 (a popularity signal, not a safety signal)
- Open issues: 0
- Health checked at: 2026-11-05T20:35:15.821Z
- Integrations: AWS, Tenable
- Domains: governance-risk-compliance, vulnerability-management
- Tags: fedramp, poam, conmon, tenable, security-center, stig, cis, kev, vulnerability-remediation
- Date added: 2026-08-07
- Compatible platforms: Claude Code
- Invocation: `/tenable-fedramp-poam`
- Listing page: https://exchange.tenable.com/skills/tenable-fedramp-poam
- Source file: https://github.com/tenable/cyberagents-exchange/blob/main/skills/tenable-fedramp-poam.md

Turn raw Tenable Security Center findings into the monthly FedRAMP
continuous-monitoring (**ConMon**) POA&M deliverables a vulnerability-
management team actually uses: a **vulnerability POA&M workbook** with
team attribution and remediation context, and a **STIG/CIS Configuration
Findings** workbook mapped to the same FedRAMP Open POA&M Items schema.
Both workbooks produce content compatible with the formal POA&M — the
vulnerability workbook adds per-host detail, team ownership (from cloud
tags + Nessus agent groups), aging, and KEV/BOD 22-01 flags so the same
data drives both compliance submission and engineering remediation
handoff. (POA&M = *Plan of Action and Milestones*.)

This is a **documentation skill** — it teaches the workflow and the
FedRAMP mappings so a Claude Code assistant can reproduce the pipeline
against your own environment; it does not ship a runnable implementation.

## What it does

- **Vulnerability POA&M workbook (with team attribution and remediation
  context).** Pulls `analysis.vulns` from Tenable.sc per repository
  (plugin-centric, unioning host findings, CVE intersections, first/last-
  seen, CVSS), classifies OS from Tenable's authoritative
  `operatingSystem` attribute only, separates OS patches from
  application/library updates via a two-stage classifier, and emits
  per-OS + per-agent-group tabs plus a dashboard with a ConMon status
  banner, severity inventory, and multi-month trend. Cloud tags and
  Nessus agent-group membership attach team ownership to each row so the
  same data both feeds the FedRAMP POA&M and routes work to engineering.

- **STIG / CIS Configuration Findings.** Pulls compliance results
  (`pluginType=compliance`, severities 2 & 3 — failed + manual-review),
  extracts DISA STIG **CAT I / II / III** categories from prioritized
  Tenable fields, parses CIS control IDs and DISA Vuln-IDs (formats like
  `X.X.X`, `V-XXXXXX`, `RHEL-XX-XXXXXX`) as stable control aliases, and
  emits per-OS/benchmark failure tabs plus a **Configuration Findings
  (POA&M)** tab mapped to the FedRAMP Open POA&M Items schema (30-column
  canonical layout).

- **Framework-dependent SLA + KEV.** Computes past-due against
  remediation windows selectable per environment — Critical/High = 30
  days and Moderate = 90 across frameworks, and **Low = 180 days
  (FedRAMP) or 120 days (DoD)** with DoD taking precedence when both
  apply. Cross-references the CISA Known Exploited Vulnerabilities
  catalog for **BOD 22-01** items and treats KEV-past-due as the
  top-priority signal.

- **Deviation model.** Applies an approved-plugin allowlist that
  **marks** findings as accepted/deviated rather than removing them —
  expired approvals revert to not-approved, boilerplate rationale
  downgrades to pending. Handles Tenable's plugin-ID churn via stable
  control aliases so approvals survive STIG republishes.

- **Month-over-month baselines.** Writes per-environment JSON baselines
  each run so New / Remaining / Closed can be computed per SLA band, and
  drift/regression alerts surface on the dashboard.

- **Multi-environment merge.** Runs across many Tenable.sc repositories,
  keeps results environment-segregated, then merges into one workbook
  with a leading Combined Summary tab and label-prefixed environment
  tabs (with the openpyxl chart-copy corruption workaround and Excel
  book-view / sheet-title rules that most teams learn the hard way).

## How it works

The pipeline is **read-only against Tenable** — it queries, computes,
and writes Excel; it never modifies Tenable data, hosts, or agents. The
only optional write to a source-of-record is assigning POA&M IDs back
into your local deviation store. Cloud enrichment is optional — AWS EC2
is the reference implementation but the same IP→host/owner matching
applies to any cloud provider (Azure, GCP, etc.); with no cloud access
the pipeline degrades gracefully and labels hosts from Tenable's own
DNS/hostname fields. Everything site-specific — repository IDs,
environment labels, subnet ranges, inventory file paths, deviation
store location — lives in configuration, never in code. Remediation SLA
day-counts are the one exception: they are code constants you edit to
match your authorization boundary (the as-of date is the one
environment-driven SLA input). See `SKILL.md` for the shared pipeline,
`references/vuln-poam.md` for the vulnerability POA&M workflow,
`references/stig-config-findings.md` for the STIG/CIS + POA&M schema
mapping, and `references/deviations-and-merge.md` for the deviation
model + Excel merge mechanics.

This is the Markdown version of one of 140 listings on CyberAgents Exchange. The same listing as JSON: https://exchange.tenable.com/api/skills/tenable-fedramp-poam.json. The full index and how to read it: https://exchange.tenable.com/llms.txt