01

Top-level report structure

JSON fieldRequiredPurpose
certificationPackageOverviewUriYesFull URI for the provider Certification Package Overview document.
reportPeriod.fromYesISO 8601 start date-time for activity summarized by the report.
reportPeriod.toYesISO 8601 end date-time for activity summarized by the report.
vulnerabilitiesYesArray of non-accepted vulnerability records with activity in the period.
02

Vulnerability detail fields

  • providerTrackingId identifies the finding in the provider system.
  • detection contains detectedAt and detectionSource.
  • vulnerabilityDescription provides a responsible, useful description.
  • evaluationCompletedAt records when contextual evaluation finished.
  • isInternetReachable and isLikelyExploitable carry the IRV and LEV decisions.
  • currentRating is an integer from 1 through 5 for the current PAIN estimate.
  • projectedNextReduction contains an estimated time and target rating.
  • overdueStatus requires an explanation when isOverdue is true.
  • finalDisposition is limited to Fully Mitigated, Partially Mitigated, or False Positive.
03

Keep accepted records separate

The Vulnerability Detail Report covers non-accepted vulnerabilities. Accepted records use the separate Accepted Vulnerability Info schema, which nests a vulnerabilityDetail record and adds an acceptanceRationale.

Historical VER Activity combines active and accepted arrays for automated retrieval. Do not collapse all three document types into an undocumented custom payload.

04

Validation and disclosure boundaries

  • Use the dated schema URL and record the schema version used for generation.
  • Validate data types, enum values, dates, required fields, and conditional overdue explanations.
  • Do not put exploit-enabling details into reports shared with parties that do not require them.
  • Keep the workbook or source system as an auditable source of truth instead of hand-editing final JSON.
  • Revalidate before each real export because FedRAMP may update schemas and rule guidance.