FedRAMP 20x: Build a Historical Vulnerability Activity Feed

A reviewer who sees only today's vulnerability totals cannot reconstruct what changed. For 20x Class B and C teams, a FedRAMP 20x historical vulnerability activity feed should connect findings, evaluations and response activity across reporting periods. Start with the reporting obligations, then design the retrieval mechanism around them.

Separate the three reporting expectations

The current Vulnerability Evaluation and Reporting rules distinguish persistent reporting, human-readable reports and machine-readable history.

Under VER-RPT-PER, providers MUST report detection and response activity, including persistent verification and validation, to all necessary parties persistently. Each report summarizes ALL activity since the previous report. These reports are Certification Data and are subject to Certification Data Sharing rules.

VER-TFR-MHR separately requires a human-readable report in a consistent format at least monthly. VER-TFR-MRH uses SHOULD for making all recent historical detection and response activity available in JSON for automated retrieval by all necessary parties. Its update recommendation is at least monthly for Class B and at least every 14 days for Class C. An API service is an example in the rule; a similar retrieval mechanism can serve the recommendation.

Do not collapse those statements into a single mandatory API schedule. Keep the mandatory reporting requirements and the recommended history updates visible in the implementation plan.

Preserve changes, not just the latest row

As an engineering practice, use stable finding identifiers and retain enough event context to explain changes between reports. A useful event record connects a finding to its resource, detection time, evaluation, response action and the time of that change. These are design suggestions for a usable feed, rather than a prescribed event schema.

For example, a finding could move through evaluation, a revised impact rating and mitigation during one reporting period. Exporting only the last state would make the intervening work harder to review. Keep the sequence available alongside the current state, and use the PAIN rating guidance when explaining the impact assessment.

Keep original timestamps separate from export timestamps. Treat generating a new export as a reporting operation; preserve the underlying response timeline. For accepted findings, connect the history to the accepted-vulnerability record instead of dropping the finding from the history.

Reconcile retrieval with the human report

Build a reporting check that compares the period covered by the human-readable report with the events exposed through automated retrieval. Investigate missing events, duplicate identifiers and mismatched totals before release. A report with accurate totals can still be difficult to audit if the underlying events cannot be located.

Agency-specific views can help readers navigate, but keep the required reporting coverage intact. An interface filter should not silently become the rule for which activity enters the reporting record. Authenticate retrieval and test access for the necessary parties; the rule describes those parties, rather than a public vulnerability feed.

The history recommendation does not specify a universal retention duration. Set an explicit retention design using the applicable requirements and operating needs, and document it separately from the monthly or 14-day update schedule. Our JSON validation workflow covers useful checks before consumers ingest an export.

Put the dates beside the implementation work

The current VER page lists optional adoption from July 4, 2026, initial and ongoing certification adoption dates of December 7, 2026, and grace through March 7, 2027. Track that adoption framework separately from the recurring reporting frequencies.

For the implementation owner, the next step is concrete: compare one completed reporting period across the event store, JSON retrieval and human report. Use the discrepancies to repair coverage and traceability before expanding the feed.