[dwolfson]

Summary

Step 3 of the pyegeria/Dr.Egeria support asked for in odpi/egeria-workspaces#702 (design-docs/HANDOFF_pyegeria_security_annotations.md). It covers the security annotation types Egeria 6.3 adds for security test results (model 0665).

• Models: AnnotationProperties, ResourceMeasureAnnotationProperties, SecurityFindingAnnotationProperties, VulnerabilityAnnotationProperties, PenetrationTestFindingAnnotationProperties and SecurityPostureAnnotationProperties. Field names are checked against the Java properties classes. Severity is limited to the CVSS ratings and the CVSS score to 0–10.
• Fix: DataDiscovery's own AnnotationProperties was never used and named a field confidence_level, where Egeria's field is confidence. It now re-exports the shared model, so existing imports keep working.
• DataDiscovery.get_security_findings: the findings for one survey report, or for one element through AssociatedAnnotation, sorted by CVSS score with the highest first. Optional filters are min_severity and finding_types, and the report or element can be given as a GUID or a qualified name.
• DataDiscovery.get_security_posture_history: one SecurityPostureAnnotation per run, oldest first. An optional report_qualified_name_prefix follows one system's series of reports.
• Report specs: Security-Findings, Penetration-Test-Findings and Security-Posture.

Unset values Egeria reports as 0 or false

cvssScore, exploitAvailable, patchAvailable and the posture counts are Java primitives in Egeria. A finding where only the severity was set came back live with cvssScore: 0.0, exploitAvailable: false and patchAvailable: false. Shown as they are, those would read as "CVSS 0, no exploit, no patch" for something nobody assessed. So the report rows apply these rules:

• A CVSS score of 0.0 is shown only when the severity is None, the rating that a score of 0.0 means.
• Exploit Available and Patch Available are shown only when true.
• If a run has 0 resources in scope, the count wasn't recorded, so both resource counts are left blank.
• A severity missing from a recorded findingCountsBySeverity map counts as 0. If there's no map at all, every severity count is blank.

New and resolved finding counts of 0 still can't be told apart from unrecorded ones, and the Security-Posture description says so. Making these fields boxed types (Float, Boolean, Long) in Egeria would remove the ambiguity, so that's worth raising with the Egeria team.

Verification

• Tested live against a quickstart running egeria-platform:latest (2026-10-26), using throwaway reports and annotations. I checked a sparse vulnerability, a fully populated vulnerability, a pen-test finding linked to an element, and two posture runs. All three specs ran through exec_report_spec, covering the per-report and per-element views, min_severity, prefix filtering and ordering. Everything was deleted afterwards, and each GUID was confirmed gone.
• omvs_audit.py --service data-discovery: 25 OK, 0 mismatches, and no new findings.
• 10 new micro-tests in test_security_annotations.py; the full micro-test suite passes (1522).

Not in this PR

• Step 4: Dr.Egeria Survey Report, security finding and posture commands.
• The optional create_security_finding convenience method. It fits naturally with the step 4 commands.

🤖 Generated with Claude Code