# Tenable → FedRAMP Integrated Inventory Workbook

> Build the FedRAMP Integrated Inventory Workbook (IIW) by reconciling a cloud fleet, Tenable Security Center, and Nessus Manager. Read-only, review-by-default.

- Type: Skill
- Author: conard0-git
- License: MIT
- Trust tier: contributed (passed automated validation and a baseline maintainer review)
- Last reviewed: 2026-08-12
- Source repository: https://github.com/conard0-git/tenable-fedramp-inventory
- Repo state: not archived
- Last push: 2026-08-13T16:31:40Z
- 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
- Tags: fedramp, fiiw, iiw, integrated-inventory, inventory, tenable, security-center, nessus, conmon, compliance-reporting
- Date added: 2026-08-07
- Compatible platforms: Claude Code
- Invocation: `/tenable-fedramp-inventory`
- Listing page: https://exchange.tenable.com/skills/tenable-fedramp-inventory
- Source file: https://github.com/tenable/cyberagents-exchange/blob/main/skills/tenable-fedramp-inventory.md

Produce the monthly FedRAMP **Integrated Inventory Workbook (IIW)** by
reconciling three sources into one authoritative asset list: a **cloud
fleet** (running instances), **Tenable Security Center** scan data, and
the **Nessus Manager** agent registry. The output maps onto the canonical
FedRAMP IIW column schema and is maintained as a protected master
workbook that carries forward month to month. The cloud side is a
**pluggable inventory provider** — the reference implementation uses AWS
EC2, but Azure, GCP, or on-prem sources meeting the same per-instance
contract (instance id, name, IPs, MAC, DNS, location, owner tag,
running-state) drop in without touching the reconciliation logic.

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

## What it does

- **Three-source reconciliation.** Cloud is authoritative for asset
  existence, lifecycle, IPs, and owner tag; Tenable is authoritative for
  scan presence, authenticated-scan status, and OS/version; Nessus is
  used only to annotate why a host lacks an authenticated scan. Tool-wide
  match precedence: **instance id → name → IP → DNS**.
- **Canonical FedRAMP IIW schema.** Maps every value onto the 24-column
  canonical layout (Unique Asset Identifier, IP, Virtual, Public, DNS,
  NetBIOS, MAC, Authenticated Scan, OS Name/Version, Location, Asset
  Type, Hardware Make/Model, In Latest Scan, Software/DB Vendor, Patch
  Level, Function, Comments, Asset Tag, VLAN, System/App Administrator,
  End-of-Life, …) via a fuzzy column resolver so header drift,
  hand-edits, and template revisions don't break the pipeline.
- **Review-by-default master update.** Review mode (the default) writes
  a dated review workbook — Inventory + summary sheets with Nessus agent
  annotations explaining un-authenticated hosts — and leaves the master
  untouched. Update mode overwrites the master in place, but only after
  decommissioned rows are dropped and helper columns stripped.
- **Owner precedence.** Cloud owner/team tags are authoritative — they
  set or replace the owner when the tag is present and non-placeholder.
  Optional inference passes (comment-rule, comment-prefix majority,
  diagram-label majority) fill blank owner cells only, never overwriting
  existing values, with ≥ 2-vote / skip-ties guards.
- **OS + EOL enrichment.** Parses OS/version from Tenable scan records
  with source priority (richer network-device OS from credentialed
  plugin output beats a general server OS parse), estimates End-of-Life
  from an OS→EOL lookup, and re-derives EOL at the end so manual edits
  to the OS column stay consistent.
- **Ghost-asset detection.** Scanned hosts whose IPs fall in cloud
  network space but aren't running instances are flagged as ghost assets
  (reported, never auto-added to inventory).
- **Decommission tracking.** On-prem/physical hosts absent from recent
  scans can be immediately dropped or **aged** (drop after ≥ N
  consecutive absent days, default ~15, tracked in a small local
  miss-tracker workbook) so a single missed scan doesn't remove a host
  prematurely.

## How it works

The pipeline is **read-only against source systems** — it reads from the
cloud provider, Tenable, and Nessus and writes only local files (Excel
workbooks, cached scan downloads, and small tracker workbooks). It never
modifies Tenable data, hosts, or agents. The **review-by-default**
posture is the second safety layer: the protected master workbook stays
untouched unless the caller explicitly enables update mode, and even
then the update path drops decommissioned rows and strips helper columns
first. Environment scoping is done by **IP CIDR** rather than a stored
column, so one workbook can span multiple environments and be filtered
without polluting the FedRAMP-standard structure. Everything site-
specific — master filenames, scan names, network ranges, region
defaults, owner/team normalization maps — lives in configuration, never
in code. See `SKILL.md` for the pipeline, `references/reconciliation.md`
for the three-source pull and join cascade,
`references/inventory-schema.md` for the canonical schema + resolver +
review/update model, and `references/enrichment.md` for OS/EOL, staging,
decommission, and the optional physical-asset layer.

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-inventory.json. The full index and how to read it: https://exchange.tenable.com/llms.txt