HDF Amendments — v3.3.0

Waivers, attestations, and POA&Ms that modify requirement compliance status or impact. Amendments are standalone documents that can be applied to results via merge operations.

Version	v3.3.0
$id	https://mitre.github.io/hdf-libs/schemas/hdf-amendments/v3.3.0
Download	hdf-amendments.schema.json

Properties

Field	Type	Required	Description
amendmentId	string (uuid)	no	Unique identifier for this amendments document. Useful for cross-referencing when multiple amendment documents target the same results.
name	string	yes	Human-readable name for this amendments document. Example: 'Portal Q1 2026 Waivers'.
description	string	no	Description of the amendments' purpose and scope.
systemRef	string (uri-reference)	no	URI to the hdf-system document these amendments apply to.
appliedBy	Identity	no	Default identity of who created this amendments document. Individual overrides may specify their own appliedBy.
approvedBy	Identity	no	Identity of the authorizing official who approved these amendments.
overrides	Standalone_Override[]	yes	The set of amendments (waivers, attestations, POA&Ms, and other overrides).
labels	Map<string, string>	no	Optional key-value labels for grouping and querying amendments.
integrity	Integrity	no	Cryptographic integrity information for verifying this amendments document has not been tampered with.
signature	Signature	no	Document-level digital signature covering all amendments.
version	string	no	Version of this amendments document.
generator	Generator	no	Information about the tool that generated this document.

Example

{
  "name": "Portal Q1 2026 Waivers",
  "systemRef": "portal-prod.hdf-system.json",
  "approvedBy": {
    "type": "email",
    "identifier": "ao@agency.gov"
  },
  "overrides": [
    {
      "type": "waiver",
      "requirementId": "SV-257777",
      "baselineRef": "RHEL9-STIG",
      "status": "passed",
      "reason": "Compensating control: session timeout set to 15 min",
      "appliedBy": {
        "type": "email",
        "identifier": "ao@agency.gov"
      },
      "appliedAt": "2026-01-15T10:00:00Z",
      "expiresAt": "2026-06-30T00:00:00Z",
      "evidence": [
        {
          "type": "url",
          "data": "https://jira.agency.gov/CYBER-4521",
          "description": "ISSM approval with compensating control documentation"
        }
      ]
    }
  ]
}

Embedded Primitives

These types are embedded from shared primitive schemas.

affected-package

Affected_Package

Represents a package referenced by a vulnerability finding or by an amendment's scope. On Evaluated_Requirement.affectedPackages it says 'this CVE affects these package versions'. On Standalone_Override.affectedPackages it says 'this amendment is scoped to these packages' (used by VEX, OSCAL POA&M, FedRAMP component-aware amendments). NOT a system-level component identifier — see components[] on hdf-system for those. Validity requires at least one of: (name + version + ecosystem), purl alone, or cpe alone. purl and cpe are self-describing identifiers that encode name/version implicitly, so either may stand on its own; the name+version+ecosystem combination is the explicit form for sources without formal identifiers.

Field	Type	Required	Description
name	string	no	The package name as published in its ecosystem. Examples: 'openssl' (rpm), 'lodash' (npm), 'org.apache.logging.log4j:log4j-core' (maven, group:artifact).
version	string	no	The exact version of the package that the vulnerability scanner observed. Use the ecosystem's native version string verbatim (e.g., '1.1.1k-7.el8_4' for rpm, '4.17.20' for npm).
ecosystem	"npm" | "pypi" | "rpm" | "deb" | "maven" | "gem" | "nuget" | "go" | "cargo" | "generic"	no	The packaging ecosystem the package belongs to. Use 'generic' for hardware, firmware, or anything outside the listed language/OS package managers.
cpe	string	no	Optional CPE 2.3 URI identifying the affected product. Validated leniently: only the 'cpe:2.3:' prefix and the part-type letter ('a' application, 'h' hardware, 'o' operating system) are enforced here. Use hdf-utilities.parseCpe for full-grammar parsing. Example: 'cpe:2.3🅰️openssl:openssl:1.1.1k::::::😗'.
purl	string	no	Optional Package URL (PURL) identifying the affected package. Validated leniently: only the 'pkg:TYPE/' scheme prefix is enforced here, where TYPE follows the PURL grammar (a letter followed by letters, digits, '.', '+', or '-') and is matched case-insensitively to mirror hdf-utilities.parsePurl's accept-and-warn behavior. Use parsePurl for full PURL parsing. Example: 'pkg:rpm/redhat/openssl@1.1.1k-7.el8_4?arch=x86_64'.
fixedInVersion	string	no	Optional version string identifying the first release that contains the fix for the vulnerability. Use the same version syntax as version. Example: '1.1.1l' fixes 'openssl@1.1.1k'.

Example

{
  "$comment": "RPM ecosystem with full CPE + PURL — typical Grype/Trivy output for a RHEL host scan.",
  "name": "openssl",
  "version": "1.1.1k-7.el8_4",
  "ecosystem": "rpm",
  "cpe": "cpe:2.3:a:openssl:openssl:1.1.1k:*:*:*:*:*:*:*",
  "purl": "pkg:rpm/redhat/openssl@1.1.1k-7.el8_4?arch=x86_64",
  "fixedInVersion": "1.1.1l"
}

amendments

Override_Type

The type of amendment, aligned with FedRAMP deviation request categories. 'waiver': risk accepted by Authorizing Official. 'attestation': manually verified by assessor. 'poam': remediation tracked (no status change). 'inherited': control provided by another component or system. 'falsePositive': scanner incorrectly identified a finding — for compliance scans (STIG, CIS), the check actually passes, so status is typically set to 'passed'; for vulnerability scans (CVE, SCA), the flagged vulnerability does not apply to this system, so status is typically set to 'notApplicable'. The disposition field on the requirement distinguishes false positives from genuinely not-applicable findings. 'riskAdjustment': impact score adjusted based on environmental context (FedRAMP Risk Adjustment); does not change pass/fail status, only impact via the impact field. 'operationalRequirement': deviation required by operational constraints (FedRAMP Operational Requirement); the finding cannot be remediated because the system requires the affected functionality. Remains an open risk. Migration note: 'exception' was removed in v3.1.0 — use 'waiver' with status 'notApplicable' instead.

Justification

Structured controlled-vocabulary reason for an override, complementing the free-text 'reason' field. 'reason' carries the human-readable rationale an auditor reads; 'justification' carries the machine-readable category enabling filtering, aggregation, and lossless round-trip with structured ecosystems (VEX, OSCAL, FedRAMP DR). Both fields may be present simultaneously and are NOT redundant: 'reason' explains the specific circumstance; 'justification' classifies it. Authors SHOULD populate both when a controlled-vocabulary value applies — the enum value alone is not self-explanatory to an auditor. The vocabulary is drawn from the VEX ecosystem: the first five values are common across OpenVEX, CSAF VEX, and CycloneDX VEX; the remaining six (requires_configuration / requires_dependency / requires_environment / protected_by_compiler / protected_at_runtime / protected_at_perimeter) are CycloneDX-specific and describe why the vulnerable code path is unreachable in the deployed configuration. The enum is extended additively across schema versions as other ecosystems' controlled vocabularies are integrated; documents using values added in a newer schema version will fail validation against an older schema. Consumers SHOULD validate against the schema version declared by the document ($schema) rather than assume a fixed vocabulary.

Impact_Override

An override to the requirement's impact score. The prior impact is the original result value or the preceding override in the chain.

Field	Type	Required	Description
value	number	yes	The overridden impact score (0.0–1.0).

Standalone_Override

A standalone override to a requirement's compliance status or risk impact. Validation has two branches gated on 'type': when type is 'operationalRequirement', neither 'status' nor 'impact' may be set — the override records accepted risk without changing the finding (documentation-only). For all other types, at least one of 'status' or 'impact' must be set. This rule aligns with: (1) OSCAL Assessment Results — finding.target.status and finding.associated-risk[].facet[] are separate axes (https://pages.nist.gov/OSCAL/learn/concepts/layer/assessment/assessment-results/); (2) FedRAMP deviation request types — Risk Adjustment changes impact only, Operational Requirement documents acceptance only, False Positive changes status (https://www.ignyteplatform.com/blog/fedramp/fedramp-deviation-requests-submit/); (3) NIST SP 800-37 RMF — risk response (accept/mitigate/transfer) is a separate step from control assessment status (https://csrc.nist.gov/pubs/sp/800/37/r2/final).

Field	Type	Required	Description
type	Override_Type	yes	The type of amendment.
requirementId	string	yes	The ID of the requirement being amended. Must match a requirement ID in the referenced baseline.
baselineRef	string	no	Name of the baseline containing the requirement. Required when the system has multiple baselines with potentially overlapping requirement IDs.
status	Result_Status	no	The new status this amendment sets. Optional when only impact is being overridden.
impact	Impact_Override	no	Override to the requirement's impact score. At least one of status or impact must be set.
reason	string	yes	Justification for this amendment.
appliedBy	Identity	yes	Identity of who applied this amendment.
appliedAt	string (date-time)	yes	When this amendment was applied. ISO 8601 format.
expiresAt	string (date-time)	yes	When this amendment expires and must be reviewed. No permanent amendments. ISO 8601 format.
evidence	Evidence[]	no	Supporting evidence (screenshots, logs, URLs, documents).
signature	Signature	no	Digital signature for non-repudiation.
previousChecksum	Checksum	no	Checksum of the prior amendment in the chain. Creates a tamper-evident linked list. Null for the first amendment.
cvss	Cvss	no	Structured CVSS scoring data backing this override. Captures the rubric (which Environmental/Threat metrics the consumer modified, the recomputed score) used to justify a riskAdjustment. For other override types this is optional context.
justification	Justification	no	Structured controlled-vocabulary classification for why this override applies. Complements (does not replace) the free-text 'reason' field. Most useful on falsePositive and attestation overrides where the structured category enables filtering and lossless round-trip with VEX / OSCAL / FedRAMP DR. See the Justification primitive for the precedent vocabulary and rationale.
milestones	Milestone[]	no	Remediation milestones (primarily for POA&M type amendments).
inheritedFrom	string (uuid)	no	componentId of the local component that provides this control. Set when the provider is in the same system. Omit for external or cross-system providers; the reason field explains the source. Primarily used with type 'inherited'.
componentRef	string (uuid)	no	componentId of the component this amendment is scoped to. When set, the amendment only applies to the specified component. When omitted, the amendment applies system-wide.
affectedPackages	Affected_Package[]	no	Software packages this amendment is scoped to, distinct from componentRef (which scopes to an HDF-internal Component by UUID). Use when the source amendment format references packages by purl/cpe/name+version — e.g., VEX affects[] / products[], OSCAL POA&M subjects[], FedRAMP component-aware amendments. Symmetric with Evaluated_Requirement.affectedPackages, which scopes findings to the same package vocabulary. When omitted, the amendment applies system-wide (or only to componentRef when that is set).

Example

{
  "type": "waiver",
  "requirementId": "SV-257777",
  "baselineRef": "RHEL9-STIG",
  "status": "passed",
  "reason": "Compensating control: session timeout set to 15 min",
  "appliedBy": {
    "type": "email",
    "identifier": "ao@agency.gov"
  },
  "appliedAt": "2026-01-15T10:00:00Z",
  "expiresAt": "2026-06-30T00:00:00Z",
  "evidence": [
    {
      "type": "url",
      "data": "https://jira.agency.gov/CYBER-4521",
      "description": "ISSM approval with compensating control documentation"
    }
  ]
}

common

Hash_Algorithm

Supported cryptographic hash algorithms for checksums and integrity verification. blake3 covers container-image and other artifact digests that use it.

Requirement_Group

Describes a group of requirements, such as those defined in a single file.

Field	Type	Required	Description
id	string	yes	The unique identifier for the group. Example: the relative path to the file specifying the requirements.
title	string	no	The title of the group - should be human readable.
requirements	string[]	yes	The set of requirements as specified by their ids in this group. Example: 'SV-238196'.

Dependency

A dependency for a baseline. Can include relative paths or URLs for where to find the dependency.

Field	Type	Required	Description
name	string	no	The name or assigned alias.
url	string (uri-reference)	no	The address of the dependency.
branch	string	no	The branch name for a git repo.
path	string	no	The relative path if the dependency is locally available.
statusMessage	string	no	The reason for the status if it is 'failed' or 'skipped'.
status	string	no	The status. Should be: 'loaded', 'failed', or 'skipped'.
git	string (uri)	no	The location of the git repo. Example: 'https://github.com/my-org/ubuntu-22.04-stig-baseline.git'.
supermarket	string	no	The 'user/profilename' attribute for a Supermarket server.
compliance	string	no	The 'user/profilename' attribute for an Automate server.

Example

{
  "name": "ubuntu-22.04-baseline",
  "url": "https://github.com/my-org/ubuntu-22.04-stig-baseline",
  "git": "https://github.com/my-org/ubuntu-22.04-stig-baseline.git",
  "branch": "main",
  "status": "loaded"
}

Reference

A reference to an external document.

Source_Location

The explicit location of a requirement within source code.

Field	Type	Required	Description
ref	string	no	Path to the file that this requirement originates from.
line	number	no	The line on which this requirement is located.

Example

{
  "ref": "controls/SV-260476.rb",
  "line": 1
}

Supported_Platform

A supported platform target. Example: the platform name being 'ubuntu'.

Field	Type	Required	Description
platformFamily	string	no	The platform family. Example: 'redhat'.
platformName	string	no	The platform name - can include wildcards. Example: 'debian'.
platform	string	no	The location of the platform. Can be: 'os', 'aws', 'azure', or 'gcp'.
release	string	no	The release of the platform. Example: '20.04' for 'ubuntu'.

Checksum

Cryptographic checksum for baseline integrity verification.

Field	Type	Required	Description
algorithm	Hash_Algorithm	yes	The hash algorithm used for the checksum.
value	string	yes	The checksum value.

Example

{
  "algorithm": "sha256",
  "value": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
}

Identity

Represents an identity that performed an action, such as capturing evidence or applying an override.

Field	Type	Required	Description
identifier	string	yes	The identifier value. Example: 'user@example.com', 'jdoe', 'automated-scanner-01'.
type	"email" | "username" | "system" | "agent" | "simple" | "other"	yes	The type of identifier. Use 'email' for email addresses, 'username' for user accounts, 'system' for deterministic non-interactive automation (CI jobs, cron, scanners), 'agent' for an AI/LLM agent acting with autonomy — kept distinct from 'system' so auditors can apply AI-specific scrutiny (e.g. 'an LLM proposed this' vs a deterministic job) and satisfy AI-source disclosure under frameworks like the EU AI Act and NIST AI RMF, 'simple' for basic string identifiers without additional classification, or 'other' for custom identity systems.
description	string	no	Optional description of the identity or identity system, particularly useful when type is 'other'.

Example

{
  "type": "email",
  "identifier": "admin@example.com"
}

Evidence

Supporting evidence for a finding or override, such as screenshots, code samples, log excerpts, or URLs.

Field	Type	Required	Description
type	"screenshot" | "code" | "log" | "url" | "file" | "other"	yes	The type of evidence being provided.
data	string	yes	The evidence content. For screenshots/files: base64-encoded data or URL. For code/logs: the raw text. For URLs: the URL string.
description	string	no	Human-readable description of what this evidence shows.
mimeType	string	no	MIME type of the evidence. Example: 'image/png', 'text/plain', 'application/json'.
encoding	string	no	Encoding used for the data. Example: 'base64', 'utf-8'.
size	number	no	Size of the evidence data in bytes.
capturedAt	string (date-time)	no	Timestamp when this evidence was captured. ISO 8601 format.
capturedBy	Identity	no	Identity of who or what captured this evidence.

Example

{
  "type": "screenshot",
  "data": "iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVR42mNk+M9QDwADhgGAWjR9awAAAABJRU5ErkJggg==",
  "description": "Screenshot showing firewall configuration with required ports blocked",
  "mimeType": "image/png",
  "encoding": "base64",
  "size": 95,
  "capturedAt": "2025-12-14T10:30:00Z",
  "capturedBy": {
    "identifier": "security-auditor@example.com",
    "type": "email"
  }
}

Remediation

Reference to automated remediation resources for implementing security controls. Points to external automation content like Ansible playbooks, Terraform scripts, or vendor-provided remediation tools.

Field	Type	Required	Description
uri	string (uri)	yes	URI pointing to automated remediation resources (Ansible playbooks, Terraform scripts, etc.). Examples: GitHub repository, DISA STIG Supplemental Automation Content, vendor-provided scripts.
checksum	Checksum	no	Optional cryptographic checksum for verifying the integrity of remediation resources fetched from the URI. Recommended for security when referencing external automation scripts.

Example

{
  "uri": "https://github.com/ansible-lockdown/RHEL9-STIG/tree/main/tasks"
}

Verification_Method

Verification method containing the public key needed to verify a digital signature. Supports multiple key formats including JWK (for RSA, EC), PEM, and Base58.

Field	Type	Required	Description
type	string	yes	The type of verification method. Example: 'JsonWebKey2020', 'RsaVerificationKey2018', 'Ed25519VerificationKey2020'.
controller	string	yes	The entity that controls this verification method. Can be a DID, URI, or other identifier.
publicKeyJwk	Map<string, any>	no	Public key in JSON Web Key format.
publicKeyPem	string	no	Public key in PEM format. Example: '-----BEGIN PUBLIC KEY-----...-----END PUBLIC KEY-----'.
publicKeyBase58	string	no	Public key in Base58 format, commonly used with Ed25519 keys.

Milestone

A milestone or task within a POA&M remediation plan.

Field	Type	Required	Description
description	string	yes	Description of this milestone or task.
estimatedCompletion	string (date-time)	yes	Estimated completion date. ISO 8601 format.
status	"pending" | "inProgress" | "completed"	yes	Current status of this milestone.
completedAt	string (date-time)	no	Actual completion timestamp. ISO 8601 format.
completedBy	Identity	no	Identity of who completed this milestone.

Signature

A digital signature following W3C Data Integrity Proofs pattern. Supports hardware security tokens (PKCS#11/PKCS#12), Yubikeys, GPG keys, passkeys, and other cryptographic signing methods via JWK, PEM, or Base58 key formats.

Field	Type	Required	Description
type	string	yes	The signature suite type. Example: 'JsonWebSignature2020', 'RsaSignature2018', 'Ed25519Signature2020'.
created	string (date-time)	yes	When the signature was created. ISO 8601 format.
creator	Identity	yes	The identity that created this signature.
signatureValue	string	yes	The base64-encoded or base58-encoded signature value.
proofPurpose	string	yes	The purpose of this signature. Example: 'attestation', 'authentication', 'assertionMethod'.
verificationMethod	Verification_Method	yes	The verification method containing the public key for signature verification.
nonce	string	no	Random value to prevent replay attacks.
challenge	string	no	Challenge value from the verifier, used in challenge-response authentication.
domain	string	no	Domain restriction for the signature, prevents cross-domain replay attacks.

Example

{
  "type": "JsonWebSignature2020",
  "created": "2025-12-14T10:00:00Z",
  "creator": {
    "identifier": "security-team@example.com",
    "type": "email"
  },
  "signatureValue": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..MEYCIQDvKbtLRhWAa",
  "proofPurpose": "attestation",
  "verificationMethod": {
    "type": "JsonWebKey2020",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyJwk": {
      "kty": "RSA",
      "n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx4cbbfAAtV",
      "e": "AQAB"
    }
  }
}

Baseline_Metadata

Shared metadata fields for baselines. Used in both standalone baseline documents and evaluated baseline results.

Field	Type	Required	Description
name	string	no	The name - must be unique.
title	string	no	The title - should be human readable.
maintainer	string	no	The maintainer(s).
copyright	string	no	The copyright holder(s).
copyrightEmail	string	no	The email address or other contact information of the copyright holder(s).
license	string	no	The copyright license. Example: 'Apache-2.0'.
summary	string	no	The summary. Example: the Security Technical Implementation Guide (STIG) header.
version	string	no	The version of the baseline.
supports	Supported_Platform[]	no	The set of supported platform targets.
status	string	no	The status. Example: 'loaded'.
labels	Map<string, string>	no	Optional key-value labels for flexible grouping. Well-known keys: system, component, environment, region, team. Values must be strings.

Example

{
  "name": "rhel-9-stig-baseline",
  "title": "Red Hat Enterprise Linux 9 STIG Baseline",
  "maintainer": "MITRE SAF Team",
  "copyright": "The MITRE Corporation",
  "copyrightEmail": "saf@mitre.org",
  "license": "Apache-2.0",
  "summary": "InSpec baseline for RHEL 9 STIG compliance",
  "version": "1.0.0",
  "supports": [
    {
      "platformName": "redhat",
      "platformFamily": "redhat",
      "release": "9"
    }
  ],
  "status": "loaded"
}

Requirement_Core

Core requirement fields shared between baseline requirements and evaluated requirements. Contains the fundamental requirement definition without assessment results.

Field	Type	Required	Description
id	string	no	The requirement identifier. Example: 'SV-238196'.
title	string	no	The title - is nullable.
descriptions	object[]	no	Array of labeled descriptions. At least one description with label 'default' must be present. Convention: place default description first. Common labels: 'default', 'check', 'fix', 'rationale'.
impact	number	no	The impactfulness or severity (0.0 to 1.0).
refs	Reference[]	no	The set of references to external documents.
tags	Map<string, any>	no	A set of tags - usually metadata like CCI, STIG ID, severity.
code	string	no	The raw source code of the requirement. Set to null for manual-only requirements or requirements not yet implemented; use verificationMethod to disambiguate manual-by-design from manual-pending-automation. Note that if this is an overlay, it does not include the underlying source code.
sourceLocation	Source_Location	no	The explicit location of the requirement within the source code.
controlType	"policy" | "procedure" | "technical" | "management" | "operational"	no	Classification of the control's nature, aligning with NIST SP 800-53 / SP 800-53A categories. 'policy' = an authored governance statement; 'procedure' = a documented process; 'technical' = an enforced technical configuration; 'management' = a programmatic/management activity; 'operational' = a recurring operational activity (e.g. AT, IR, MA families). Optional: when omitted, consumers may infer heuristically from family/id but should not assume a default.
verificationMethod	Verification_Method_Enum	no	How this requirement is intended to be verified. Disambiguates the two cases that null 'code' overloads: 'manual-by-design' (the requirement is statement-form and not amenable to automation, e.g. FedRAMP 20x KSIs); 'manual-pending-automation' (automation could exist but does not yet, e.g. a STIG rule lacking a fix). 'automated' = a check exists and runs without operator action; 'hybrid' = part automated, part manual. Optional: when omitted, consumers should not infer a default.
applicability	"required" | "optional" | "advisory"	no	Whether the requirement is mandatory within its baseline. Distinct from severity (risk weight) and status (lifecycle state). Maps cleanly onto: FedRAMP rev5 OSCAL 'CORE' prop, FedRAMP 20x inline 'Optional:' markers, CMMC sublevel rows, and CIS Implementation Group memberships (IG1/IG2/IG3 may carry richer semantics; layer those onto props[]/tags{}). Optional: when omitted, consumers should treat the requirement as 'required' by convention.

Example

{
  "$comment": "v3.1.x-style requirement: classification fields omitted. Consumers must continue to handle this shape under v3.3.0 (backward compatibility).",
  "id": "SV-238196",
  "title": "The Ubuntu operating system must enforce password complexity",
  "impact": 0.5,
  "tags": {
    "nist": [
      "IA-5"
    ],
    "severity": "medium",
    "cci": [
      "CCI-000192"
    ]
  },
  "refs": [
    {
      "url": "https://public.cyber.mil/stigs/"
    }
  ],
  "descriptions": [
    {
      "label": "default",
      "data": "Use of a complex password helps to increase the time and resources required to compromise the password."
    },
    {
      "label": "check",
      "data": "Verify the value of 'minlen' in /etc/security/pwquality.conf."
    }
  ]
}

Verification_Method_Enum

How a requirement is intended to be verified. Disambiguates the two cases that null 'code' overloads: 'manual-by-design' (the requirement is statement-form and not amenable to automation, e.g. FedRAMP 20x KSIs); 'manual-pending-automation' (automation could exist but does not yet, e.g. a STIG rule lacking a fix). 'automated' = a check exists and runs without operator action; 'hybrid' = part automated, part manual. Named '_Enum' to disambiguate from the unrelated Verification_Method DID-context struct.

Severity

Severity rating for a requirement. Typically derived from the numeric impact score.

Cloud_Provider

Cloud service provider identifier.

cvss

Cvss_Severity

Qualitative CVSS severity band. Aligns with FIRST/NVD bands: none=0.0, low=0.1-3.9, medium=4.0-6.9, high=7.0-8.9, critical=9.0-10.0. Distinct from the broader Severity enum used on Requirement_Core (which includes 'informational').

Cvss

A CVSS (Common Vulnerability Scoring System) score record for a vulnerability finding. Captures the vendor-supplied Base metric group and optional consumer-supplied Threat, Environmental, and Supplemental metric groups. Supports all four CVSS major versions (2.0, 3.0, 3.1, 4.0). Vector strings are validated against a permissive umbrella grammar; semantic validation (correct metrics per version, correct values per metric) is performed by the hdf-utilities validateCvssVector helper rather than at the schema layer.

Field	Type	Required	Description
version	"2.0" | "3.0" | "3.1" | "4.0"	yes	The CVSS specification version this entry conforms to. Vendor scanners typically emit 3.1 or 4.0; legacy data may use 2.0 or 3.0.
source	string	no	Optional identifier the CVSS data is associated with — most commonly a CVE ID (e.g., 'CVE-2024-12345'), but may also be a vendor advisory ID, GHSA, or similar.
baseVector	string	no	Optional Base metric group vector string as emitted by the source (e.g., 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H'). For CVSS 2.0 the version prefix is omitted. Some vendor tools emit a final baseScore without the vector — in that case this field is absent and the score cannot be recomputed or decomposed. The pattern accepts any version-prefixed or prefix-less metric token sequence; semantic validity of individual metrics is checked by hdf-utilities, not by the schema.
baseScore	number	no	The Base score (0.0–10.0) computed from the base vector. Reflects the intrinsic, vendor-published severity before consumer enrichment.
baseSeverity	Cvss_Severity	no	Qualitative severity band corresponding to baseScore. CVSS 2.0 does not natively use 'none' or 'critical' bands; map accordingly when populating.
threatVector	string	no	Optional Threat metric group vector segment (e.g., 'E:U/RL:O/RC:C' for CVSS 3.1, or 'E:A' for CVSS 4.0). Consumer-supplied — captures real-world exploitation and remediation context the vendor cannot know.
threatScore	number	no	Optional score (0.0–10.0) recomputed after applying Threat metrics. Always less than or equal to baseScore in practice.
environmentalVector	string	no	Optional Environmental metric group vector segment (e.g., 'MAV:N/CR:H/IR:H/AR:H'). Consumer-supplied — reflects the deployment context (criticality, mitigations, network exposure).
environmentalScore	number	no	Optional score (0.0–10.0) recomputed after applying Environmental metrics.
supplementalVector	string	no	Optional Supplemental metric group vector segment (CVSS 4.0 only). Examples: 'S:P/AU:N/V:C/RE:M/U:Amber'. Per CVSS 4.0 spec, supplemental metrics convey additional context but have no impact on the computed score.
computedScore	number	no	Optional final score after combining Base + Threat + Environmental metrics. This is the score consumers should treat as authoritative for risk decisions when present.
computedSeverity	Cvss_Severity	no	Qualitative severity band corresponding to computedScore. Same band convention as baseSeverity.

Example

{
  "$comment": "Base-only: vendor-supplied CVSS 3.1 data exactly as a scanner (e.g., Nessus, Grype) would emit it. No consumer enrichment yet.",
  "version": "3.1",
  "source": "CVE-2024-12345",
  "baseVector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
  "baseScore": 9.8,
  "baseSeverity": "critical"
}

extensions

Status_Override

An intentional change to a requirement's compliance status and/or impact score. At least one of status or impact must be set. Overrides change the effectiveStatus or impact of the requirement. All overrides must have an expiration date to enforce periodic review.

Field	Type	Required	Description
type	Override_Type	yes	The type of override applied to this requirement.
status	Result_Status	no	The new status this override sets for the requirement. Optional when only impact is being overridden.
impact	Impact_Override	no	Override to the requirement's impact score. At least one of status or impact must be set.
reason	string	yes	Explanation for why this override was applied.
appliedBy	Identity	yes	Identity of who applied this override. For simple cases, use type 'simple' with just an identifier.
appliedAt	string (date-time)	yes	Timestamp when this override was applied. ISO 8601 format.
expiresAt	string (date-time)	yes	Timestamp when this override expires and must be reviewed/renewed. REQUIRED - no permanent overrides allowed. ISO 8601 format.
signature	Signature	no	Optional digital signature for enhanced trust and non-repudiation. Supports hardware security tokens (PKCS#11/PKCS#12), Yubikeys, GPG keys, passkeys, and other signing methods.
evidence	Evidence[]	no	Supporting evidence for this override, such as screenshots demonstrating manual verification for attestations.
previousChecksum	Checksum	no	SHA-256 checksum of the previous amendment in chronological order. Creates a tamper-evident chain of amendments (similar to blockchain). Null for the first amendment on a requirement.
cvss	Cvss	no	Structured CVSS scoring data backing this override. Captures the rubric (which Environmental/Threat metrics the consumer modified, the recomputed score) used to justify a riskAdjustment. For other override types this is optional context.
justification	Justification	no	Structured controlled-vocabulary classification for why this override applies. Complements (does not replace) the free-text 'reason' field. Most useful on falsePositive and attestation overrides where the structured category enables filtering and lossless round-trip with VEX / OSCAL / FedRAMP DR. See the Justification primitive for the precedent vocabulary and rationale.

Example

{
  "type": "waiver",
  "status": "notApplicable",
  "reason": "This control does not apply to containerized environments as the application runs in ephemeral containers without persistent storage",
  "appliedBy": {
    "identifier": "security-team@example.com",
    "type": "email"
  },
  "appliedAt": "2025-12-01T10:00:00Z",
  "expiresAt": "2026-12-01T00:00:00Z"
}

POAM

Plan of Action and Milestones for tracking remediation, mitigation, or risk acceptance. POAMs do NOT change the effectiveStatus - the requirement remains in its current state while the POA&M tracks remediation efforts.

Field	Type	Required	Description
type	"remediation" | "mitigation" | "riskAcceptance" | "vendorDependency"	yes	The type of POA&M. 'remediation' fixes root cause. 'mitigation' reduces risk via compensating controls. 'riskAcceptance' documents decision to accept risk. 'vendorDependency' tracks a fix that depends on a vendor releasing a patch or update.
explanation	string	yes	Detailed explanation of the plan, including what actions will be taken.
appliedBy	Identity	yes	Identity of who created this POA&M. For simple cases, use type 'simple' with just an identifier.
appliedAt	string (date-time)	yes	Timestamp when this POA&M was created. ISO 8601 format.
expiresAt	string (date-time)	no	Optional expiration date for this POA&M requiring review/renewal. ISO 8601 format.
milestones	Milestone[]	no	Optional array of milestones tracking progress toward completion.
signature	Signature	no	Optional digital signature for enhanced trust and non-repudiation.
evidence	Evidence[]	no	Supporting evidence for this POA&M, such as documentation of compensating controls or mitigation implementation.
previousChecksum	Checksum	no	SHA-256 checksum of the previous amendment in chronological order. Creates a tamper-evident chain of amendments (similar to blockchain). Null for the first amendment on a requirement.

Example

{
  "type": "remediation",
  "explanation": "Upgrade OpenSSL to version 3.0.x to address CVE-2024-XXXXX vulnerability. Root cause: outdated dependency version in base image.",
  "appliedBy": {
    "identifier": "devops-team@example.com",
    "type": "email"
  },
  "appliedAt": "2025-12-01T09:00:00Z",
  "milestones": [
    {
      "description": "Update base Docker image to use OpenSSL 3.0.x",
      "estimatedCompletion": "2025-12-15T00:00:00Z",
      "status": "completed",
      "completedAt": "2025-12-10T16:30:00Z",
      "completedBy": {
        "identifier": "alice.smith",
        "type": "username"
      }
    },
    {
      "description": "Deploy updated image to production",
      "estimatedCompletion": "2025-12-20T00:00:00Z",
      "status": "inProgress"
    },
    {
      "description": "Verify vulnerability no longer present via security scan",
      "estimatedCompletion": "2025-12-22T00:00:00Z",
      "status": "pending"
    }
  ]
}

Generator

Information about the tool that generated this HDF file.

Field	Type	Required	Description
name	string	yes	The name of the software that produced this HDF file. Example: 'gosec-to-hdf'.
version	string	yes	The version of the tool. Example: '5.22.3'.

Tool

The security tool that produced the assessment data represented in this HDF file. Aligns with SARIF, OSCAL, and CycloneDX terminology.

Field	Type	Required	Description
name	string	no	The name of the security tool that produced the data. Examples: 'gosec', 'Semgrep', 'OpenSCAP', 'AWS Config', 'Nessus'. Omit if the tool cannot be identified.
version	string	no	Version of the source tool, if available in the tool's output. Example: '5.22.3'.
format	string	no	The file format, if it is a recognized named format shared by multiple tools. Examples: 'SARIF', 'XCCDF'. Omit for tool-specific formats where the tool name already implies the format (Nessus XML, gosec JSON).

Integrity

Cryptographic integrity information for verifying the HDF file has not been tampered with. If algorithm is provided, checksum must also be provided, and vice versa.

Field	Type	Required	Description
algorithm	Hash_Algorithm	no	The hash algorithm used for the checksum.
checksum	string	no	The checksum value.
signature	string	no	Optional cryptographic signature.
signedBy	string	no	Identifier of who signed this file.

Example

{
  "algorithm": "sha256",
  "checksum": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
}

result

Result_Status

The status of an individual test result. 'notApplicable' indicates the requirement does not apply to the target. 'notReviewed' indicates the requirement was not assessed (e.g., requires manual verification).

Requirement_Result

A test within a requirement and its results and findings such as how long it took to run.

Field	Type	Required	Description
status	Result_Status	yes	The status of this test within the requirement. Example: 'failed'.
codeDesc	string	yes	A description of this test. Example: 'limits.conf * is expected to include ["hard", "maxlogins", "10"]'.
runTime	number	no	The execution time in seconds for the test.
startTime	string (date-time)	yes	The time at which the test started.
resource	string	no	The resource used in the test. Example: 'file', 'command', 'service'.
resourceId	string	no	The unique identifier of the resource. Example: '/etc/passwd'.
message	string	no	An explanation of the test result. Typically provided for failed tests, errors, or to explain why a test was not applicable or not reviewed.
exception	string	no	The type of exception if an exception was thrown.
backtrace	string[]	no	The stacktrace/backtrace of the exception if one occurred.

Example

{
  "status": "passed",
  "codeDesc": "File /etc/ssh/sshd_config content is expected to match /Protocol\\s+2/",
  "startTime": "2025-06-15T10:30:00Z",
  "runTime": 0.015
}

Requirement_Description

A labeled description for a requirement, such as fix text or check instructions.

Field	Type	Required	Description
label	string	yes	The type of description. Examples: 'fix', 'check', 'rationale'.
data	string	yes	The text of the description.

Example

{
  "label": "default",
  "data": "Verify the SSH daemon is configured to only use FIPS-validated key exchange algorithms."
}