Generating FedRAMP Machine-Readable Vulnerability Reports (VER JSONs)

The FedRAMP Vulnerability Evaluation and Reporting (VER) rules require vulnerability activity to be available in standard machine-readable formats. FedRAMP publishes the official JSON schemas for these reports at fedramp.gov/schemas. Paramify generates three of these reports directly from your Paramify Issues data and validates each one against the official FedRAMP schema before it is stored as evidence.

This article explains what each report contains, how the reports are generated, and how to set them up.

The three vulnerability reports

The Accepted Vulnerability Info and Vulnerability Detail Report reports partition your project's vulnerabilities: every Issue is reported by exactly one of them, using a shared definition of "accepted." The Historical VER Activity snapshot contains no acceptance logic of its own. It partitions a single issue fetch using the same shared definition, so the snapshot can never disagree with the individual reports.

How often to refresh the Historical VER Activity snapshot

VER-TFR-MRH sets the refresh cadence by Certification Class. Note that this rule is a MAY for Class A and a SHOULD for Classes B, C, and D.

How the reports are generated

The reports are produced by fetchers in the paramify-fetchers repository, under the fetchers/paramify folder. Unlike the other fetchers in that repository, which pull evidence from third-party source systems into Paramify, these fetchers read from Paramify and produce the FedRAMP Consolidated Rules 2026 vulnerability reporting artifacts.

Each run works the same way:

• The fetcher makes read-only GET calls to the Paramify API to retrieve the project's Issues, including deviations and embedded remediation milestones
• It assembles the report JSON according to the FedRAMP schema for that report
• It validates the output against the official 2026-06-24 FedRAMP schema before writing it. If validation fails, or if any API call fails, the fetcher reports an error and does not present the output as valid evidence
• The pipeline's upload stage attaches each validated report to an Evidence record identified by a stable reference ID (for example EVD-PARAMIFY-VER-RPT-AVI), creating the record if it does not exist. No evidence UUIDs are configured by hand

Every report also includes a top-level _summary object with count breakdowns such as dispositions and overdue counts. This is a vendor extension computed from the report's own required arrays. FedRAMP schemas permit unrecognized extra fields, so it does not affect schema validation.

How "accepted" is determined

An Issue is treated as an accepted vulnerability, and therefore reported under VER-RPT-AVI instead of VER-RPT-VDT, if either of the following is true:

• It has an accepted deviation of type Operational Requirement, Vendor Dependency, or Risk Adjustment
• It is open and its completed evaluation is at least 192 days old. Under VER-TFR-MAV, a vulnerability not fully mitigated or remediated within 192 days of evaluation must be categorized as an accepted vulnerability. This threshold is the same for all Certification Classes

False Positive deviations are not acceptances. They are surfaced in the Vulnerability Detail Report as a final disposition of "False Positive."

The Vulnerability Detail Report also derives two report-specific fields from Paramify data:

• Final disposition. "Fully Mitigated" when the Issue is closed. "Partially Mitigated" when the Issue is open and has either a risk-adjustment deviation (including a pending one) or a remediation-activity milestone. "False Positive" takes precedence for an accepted false-positive deviation. The field is omitted while the Issue is still active with no progress.
• Overdue status. Marked overdue, with a required explanation, when the Issue is open and past its due date.

Report coverage window

The Vulnerability Detail and Historical VER Activity fetchers retrieve every Issue in the project and keep those that are open, or whose status changed within the report window. An open, unresolved vulnerability is ongoing activity regardless of when its status last changed, so open vulnerabilities are never dropped from reporting. The report period start covers all activity since the previous report, per VER-RPT-PER.

Selecting which programs to report on

Each report covers one program. What Paramify calls a program is what the API calls a project, so reports are identified by the program's UUID. You never have to copy that UUID by hand: you pick programs by name from your workspace, and the fetchers handle the rest.

Pick one program or several. Each one you select gets its own report file, named for that program, and all of them land in the same evidence set. Adding another program later needs no new evidence setup.

Details that vary per program are stored with that program. Details shared across the workspace, such as the Certification Package Overview URI, are stored once. The report period is set once and applies to every run.

Setting up the fetchers

The fetchers live in the fetchers/paramify folder of the paramify-fetchers repository. Setup instructions are maintained alongside the code so they always match the current version:

• Paramify VER report fetchers README: the credentials table, how "accepted" is determined, coverage, timestamps, and running across several programs
• Evidence uploader README: creating the Paramify API key, the permissions it needs, and how validated reports are uploaded to their evidence sets

Related articles

• How Paramify Supports VDR/VER
• Manage Vulnerability and Configuration Scans
• Wiz Integration: Pulling Vulnerability Findings into Paramify