[dwolfson]

Summary

Step 2 of the pyegeria/Dr.Egeria support asked for in odpi/egeria-workspaces#702 (design-docs/HANDOFF_pyegeria_statement_of_applicability.md), building on the SecurityOfficer methods from #492.

• New Dr.Egeria "Security Officer" family (commands_security_officer_compact.json, processors in md_processing/v2/security_officer.py):
  • Create/Update Statement of Applicability: Display Name, Qualified Name, Description, Version Identifier, Scope, Review Date, Authors, Content Status. Certification Standard links the certification type through GovernedBy, and Scoped By links the elements it covers through ScopedBy. If an attribute is left out, its links are left alone. With Merge Update: false, links the command no longer lists are removed.
  • Link/Unlink Control Applicability: Is Applicable, Justification, Inclusion Reasons, Implementation Status, Implementation Description, Review Date, Label, Description.
• Attribute names differ from the hand-off: Certification Standard and Scoped By instead of Certification Type and Scope Elements. Attribute names are shared across all families at runtime, and those two already exist with different meanings: one is required, the other is a Dictionary.
• Re-linking merges. Egeria's ControlApplicability attach replaces the relationship's properties wholesale when the control is already linked (confirmed live). So the processor starts from the existing properties, and re-linking with only a new status keeps the justification, inclusion reasons and the rest. Merge Update: false replaces them.
• Report specs:
  • Statement-of-Applicability-Controls: one row per control. LIST gives the auditor's markdown table and DICT gives spreadsheet rows.
  • Statement-of-Applicability-Implementation-Summary: applicable controls counted by implementation status. It's an analytic function, so BAR and PIE outputs give a chart.
  • Both take soa_guid, which accepts a GUID or a qualified name.
• SDK: SecurityOfficer.get_statement_of_applicability_controls and get_control_implementation_summary. Also overview_metrics.control_implementation_summary, registered in the analytic function registry.
• Templates (basic and advanced), the generated Statement-of-Applicability-DrE-* specs, a Dr.Egeria test document (dr_test_security_officer.md, added to run_dr_tests.py), and a Security Officer entry in docs/dr_egeria_manual.md.

Verification

• Tested end to end against a quickstart running egeria-platform:latest (2026-10-26). The Security Content Pack wasn't loaded, so I used stand-in controls I created for the test. I ran create, link, re-link (status update and merge), approve, unlink and both report specs. I confirmed the results by fetching the statement directly from Egeria and checking its properties, the GovernedBy and ScopedBy links, and the control relationship properties. All the stand-in elements were deleted afterwards, and each GUID was confirmed gone.
• omvs_audit.py --service security-officer against the updated .http files: 22 OK, 0 mismatches, 0 missing.
• validate_compact_specs: 0 errors. dr_egeria_attribute_consumption_audit.py --family "Security Officer": 0 findings.
• 6 new micro-tests; the full micro-test suite passes (1512).

Known gaps

• Dr.Egeria View Report can't run report specs backed by an analytic function: _async_run_report only handles function. That's an existing gap, and it affects the analytic demo specs too. So the summary spec runs through exec_report_spec and the SDK, but not from View Report.
• Create Statement of Applicability reports SUCCESS even when a GovernedBy or ScopedBy link fails. The failure is only recorded as a related result, which matches how the other processors behave.
• Not tested against the real NIST catalog, because the Security Content Pack wasn't loaded on the test platform.

Not in this PR

• Security annotation models, report specs and Dr.Egeria Survey Report and finding commands (steps 3 and 4).

🤖 Generated with Claude Code