📢 New post: Is It Even in Your Boundary? CVE-2026-0257 and the Question a KEV Clock Asks First · 📝 Also fresh: 20x Is Permanent Now: The Rehearsal's Over, the Rules Land in June · 🚦 Beacon — the FedRAMP 20x KSI emitter — design partners open ✨ · 🆕 20x Hub: program reference, kept current · 🧪 Free tool: KSI Quick Check — paste, run, get the verdict
← Blog
FedRAMPConMonProductGRC

Announcing the Novaprospect FedRAMP Audit Suite — Catalog Live, Engine in Alpha

Today we shipped two things:

  1. A browsable, searchable Rev 5 Moderate + 20x KSI catalog at /fedramp/controls — 323 controls and 72 Key Security Indicators, side by side, with the KSI→control mappings already wired up.
  2. The alpha of the Novaprospect FedRAMP audit engine — a Rust suite that discovers AWS state, evaluates it against the catalog, and emits machine-readable evidence in the same shape a 20x package expects.

The catalog is live and finished for this slice of scope. The engine is genuinely alpha — one collector (IAM), one evaluator (AC-2 Account Management), end-to-end. The shape of the rest is in place; the next several months are filling it in.

What's at /fedramp/controls

The page is the public-facing slice of the catalog database that backs the audit engine. It's where to go to ask "what does AC-2's statement actually say," "which Rev 5 controls does KSI-IAM-01 cover," or "how does FedRAMP Moderate group its Access Control family." Searchable by ID, title, or statement text. Filterable by control family.

A few things worth knowing:

  • The Rev 5 statements are FedRAMP-resolved. The parameter substitutions and tailoring decisions from the FedRAMP Moderate baseline are baked into the control statements. Parameter placeholders ({{ insert: param, ... }}) point at the resolved values, which live in the catalog database and surface in per-control detail pages.
  • The 20x KSI mappings are wired. Each control's detail page shows the KSIs that cover it (or notes when none in the current catalog version do). The mappings come from the FRMR machine-readable KSI release 25.12A, which is the version in active 20x pilot use.
  • The catalog is regenerable. It's generated from the same Postgres schema the audit engine queries against. When NIST publishes Rev 5 updates or FedRAMP publishes a new KSI release, we regenerate. The page is the artifact of a deterministic build, not a hand-maintained reference.

What the audit engine does, and what it doesn't yet

The engine is a Rust binary called npa. The shape is discover → audit → report:

npa discover --account 123456789012        # pulls AWS state into an immutable snapshot
npa audit --run <snapshot-id>              # evaluates controls against the snapshot
npa report --run <audit-id> --format json  # emits a machine-readable evidence package

Each discovery snapshot is timestamped and immutable. Each audit run pins to exactly one snapshot. Evidence carries the binary version that produced it, so a 3PAO reviewing the output knows precisely what they're looking at and can reproduce it.

Today, "what runs" is small: an IAM collector that pulls users, roles, policies, attached policies, access keys, MFA devices, the account password policy, and account aliases — and an AC-2 evaluator that flags inactive users, stale access keys, and active keys that haven't been exercised, against tunable thresholds.

That's the alpha. The shape is right, the schema is settled, the CLI works end-to-end, the catalog query path is wired. The remaining several months are about coverage: S3, CloudTrail + CloudWatch Logs, KMS, EC2 + VPC, Config — the cluster of services that together cover the largest chunk of FedRAMP Moderate customer-responsibility controls — and the evaluators that consume them.

Why we built it

For anyone following recent posts here, the through-line will be familiar:

  • The Consolidated Rules make machine-readable artifacts the destination, with templates on a deprecation path.
  • 20x Phase One prep needs a generator pipeline, not a template — and the generator has to read infrastructure state.
  • A 10.0 on Thursday puts ConMon under load against a three-day clock, and the artifact that survives is the evidence trail.

The piece that kept showing up in conversations with teams: the muscle memory for "answer a control with infrastructure evidence" is the load-bearing capability. The catalog is just the index. The engine is the part that makes the index actionable.

So we built it. The audit engine is a thing we'd want to use ourselves on engagements; the catalog is the half of it that's already useful on its own as a reference, which is why it went live first.

Honest scope

What this is, today:

  • A public, browsable, searchable catalog of FedRAMP Rev 5 Moderate + 20x KSIs, with the KSI→control mappings
  • A Rust audit engine with one working AWS collector (IAM) and one working evaluator (AC-2), running end-to-end against real AWS or a moto mock
  • A schema, a CLI, and a build pipeline ready to absorb the rest of the v1 collectors and evaluators

What this isn't, yet:

  • Open-source (we're still working through licensing — more on that as the picture firms up)
  • Distributable as a binary (cross-compile pipeline is in place, releases aren't cut)
  • Multi-cloud (AWS-only for the foreseeable future; that's the deliberate scope)
  • A replacement for a 3PAO (the engine produces evidence; humans still review)
  • Done with the AWS customer / shared / inherited responsibility split (that work is in progress against the AWS Artifact CRMs — content paraphrased in our own words per the Artifact NDA)

What's next

Coverage, mostly. The v1 collector set is six services (IAM, S3, CloudTrail + CWLogs, KMS, EC2 + VPC, Config). The v1 evaluator set is the cluster of FR Mod customer-responsibility controls those collectors enable — AC-2, AC-3, AC-6, IA-2, IA-5, AU-2, AU-6, SC-7, SC-12, SC-13, SC-28, AU-9, AU-11. After that, the AWS responsibility split gets layered on, and the per-control detail pages start showing what's the customer's job versus what AWS handles inside its own FedRAMP authorization.

In parallel, we're working out what a meaningful early-access program looks like for a tool at this stage. Teams in active 20x or Rev 5 Moderate authorizations who'd like to compare what the engine sees against what their current ConMon program produces — that's the conversation we'd most like to be in over the next few months.

If that's you, we'd love to hear from you. The catalog is yours to use right now. The engine, when it lands.