Skip to content

v1.15.0 — HDF Aggregation: re-occurrence lifecycle, amendment approval, document aggregation

Choose a tag to compare

@clem-field clem-field released this 27 Jul 12:31
v1.15.0
f9b5732

Extends HDF triage from a per-scan worklist into an audit-ready, ATO-integrated flow. Scans are tied to the component they assessed, kept as history with a re-occurrence lifecycle, gated by an approval + ODP-validity flow, and folded into the boundary's assessment documents.

Includes v1.14.0. The HDF Amendment Triage work (#447) set VERSION 1.14.0 on main but was never tagged, so no v1.14.0 release or image exists. Everything from that release ships here. Upgrading from v1.13.2 → v1.15.0 is the supported path.

HDF Aggregation (#809, #811)

  • Audit-ready scan history + re-occurrence lifecycle (#811) — each ingest records its Target / CDEF and Scope (target-specific vs boundary-wide), and findings are kept per-scan-run as history (current flag) rather than overwritten. Every finding carries a lifecycle status — new / carried_forward / re_failed (failing again at worse severity) / expired / superseded — computed against the prior current scan. The triage board defaults to the current scan with an Include history toggle, a Component column, lifecycle badges, and a re-failed banner.
  • Amendment approval + ODP validity (#809) — a disposition is a proposed amendment that only suppresses a finding once approved (by an admin or a role granted the new amendment.approve permission) and while inside its validity window. The window comes from the boundary profile's ODP, else a new admin Remediation Timelines SLA table (baseline × NIST criticality → days); an active POA&M for the control means no expiry. Amendments record both decider and approver, bound into the signature.
  • Aggregate into SSP / SAP / SAR / POA&M (#809) — an Aggregate action (synchronous or via AggregateFindingsJob) maps findings to controls through their HDF tags.nist, writes a non-destructive hdf_scan_result annotation on matching SSP/SAP/SAR controls, and opens POA&M items for un-suppressed failures.
  • Signed HDF package export (#809) — a single HMAC-SHA256 signed bundle (amendments + findings + dispositions) keyed from SPARC_HASH, which a consumer can archive or feed downstream. Full Api::V1 surface for every new action.

Also in this release: HDF Amendment Triage (#447, previously v1.14.0)

Upload scanner findings in Heimdall Data Format (a single scan or a saf convert bundle), triage each failed control into one of the seven HDF v3.4.0 override kinds (falsePositive / waiver / poam / vendorDependency / inherited / riskAdjustment / operationalRequirement) with an evidence / POA&M / attestation / risk-assessment linkage and provenance hash, then export a deterministic per-boundary HDF Amendments document your CI applies with hdf amend apply before its saf validate threshold gate. The export validates itself via hdf amend verify, and the #244 severity policy is enforced (no waiver or downgrade on CRITICAL).

Fixes shipped alongside

Found while verifying the epic end-to-end against a running instance. Each carries a regression test.

  • Control-catalog XML export returned 500 for every user — OSCAL catalogs nest <select> inside <param>, and elements are emitted with send, so the element name resolved to Kernel#select and raised TypeError. Also fixed how-many, which was emitted as a child element instead of an attribute (schema-invalid OSCAL).
  • POA&M export was impossible — OSCAL requires risk/statement and finding/target; the demo data supplied neither. Fixed in the data, not the exporter: required OSCAL content is never synthesised, because a POA&M that passes schema validation while misrepresenting the risk is worse than one that fails.
  • Profile export was impossible for any profile containing an untailored ODP — a blank parameter produced "values": [], which OSCAL rejects, failing the whole document. Untailored parameters are now omitted.
  • Markup injection on the POA&M item screens — the add/edit screens marked an interpolated, user-supplied document name html_safe. CSP blocked script execution, so the impact is markup injection rather than working XSS, but injected elements did reach the DOM. Note Brakeman does not flag this pattern, so the suite carries the regression test.
  • POST with a non-existent authorization_boundary_id returned 500 instead of 422 — belongs_to … optional: true makes the association optional, not the id valid, so PostgreSQL raised an unhandled foreign-key violation. Now validated across all five document types.
  • A double-escaped label rendered as POA&amp;M to users on the processing banner.
  • Navigation — Authoritative Sources had no top-nav route at all; it now appears under Enterprise › Compliance Library, mirroring the sidebar.

Naming

  • Help Center guides renamed: Security Assessment Plan (SAP), Security Assessment Results (SAR), and Compliance Library (was "Trust Store"). /help/trust-store now 301s to /help/compliance-library.

Upgrade notes

  • Migrations are additive — new columns on scan_runs, scanner_findings, finding_dispositions, plus a new remediation_timelines table. The (boundary, control_id) unique index on findings becomes a partial index on current = true so scan history can be retained.
  • New permission key amendment.approve, seeded to the Authorizing Official, Agency AO, and ISSM roles. The roles seed section bumps to 1.1.0 so existing databases pick it up; Instance Admins bypass it regardless.
  • SPARC_HASH keys the signed HDF package. Without it the derivation falls back to secret_key_base (logged in production), which weakens the cross-instance provenance claim on the bundle.
  • The seeded Remediation Timelines SLA grid is a starting point, not an organizational determination — review it against your own remediation policy, since those values decide how long an approved amendment suppresses a finding.

Full changelog: v1.13.2…v1.15.0