Skip to content

analyze should cross-check POA&M control ids against implemented controls #7

Description

@cognis-digital

Idea

A POA&M item carries a control id (e.g. SC-13) naming the weakness's control. Today analyze_boundary reports the POA&M roll-up (open/overdue/risk) and, separately, the set of controls declared on components. It never correlates the two.

A useful, low-cost finding: an open POA&M references a control that no component claims to implement. That is a common package inconsistency — the SSP says a control is met, but there is an open weakness against it (or vice-versa: a POA&M against a control that was never in scope).

Proposed behavior

  • For each open POA&M item with a control, normalize it and check membership in the implemented-control set.
  • Emit a low/moderate finding poam_control_not_implemented when the referenced control is absent from every component's controls.
  • Keep it advisory (non-blocking) so it doesn't flip authorization_ready.

Why it's real

This is exactly the kind of drift a 3PAO flags by hand. The data to compute it is already loaded in analyze_boundary; it just isn't correlated yet. Enrichment (--enrich) could also resolve the missing control's title to make the message actionable.

Happy to send a PR behind the existing finding-emission pattern if this is wanted.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions