Parity grade: A · SDK aws-sdk-go-v2/service/securityhub@v1.75.0 · last audited 2026-07-25 (1659d616)
| Metric | Value |
|---|---|
| Operations audited | 116 (115 ok, 1 partial) |
| Feature families | 2 (2 ok) |
| Known gaps | 4 |
| Deferred items | 0 |
| Resource leaks | clean |
- ListMembers(onlyAssociated=true) can never return members: filters on MemberStatus=="Enabled", but nothing transitions a member to Enabled because member-invitation acceptance is a cross-account action this single-account in-memory backend doesn't model (the member's own account would call AcceptInvitation against ITS OWN backend instance, not the administrator's). Not attempted this pass -- architectural, not a bug-fix-sized change; would need a multi-backend cross-account simulation this service doesn't have.
- GetFindingsV2 Filters.CompositeFilters only evaluates StringFilters and NumberFilters, and only for the field-name subset in ocsfStringFieldMap/ocsfNumberFieldMap (findings_v2.go) that has a direct scalar ASFF equivalent. DateFilters, MapFilters, IpFilters, BooleanFilters, NestedCompositeFilters, and any OcsfStringField/OcsfNumberField outside the mapped subset (e.g. class_name, which has no scalar ASFF equivalent -- the closest analog, Types, is a string array) are accepted on the wire but not evaluated, matching (not exceeding) the 'basic subset' precedent V1 GetFindings/matchesFindingFilters already established. Full coverage needs a complete OCSF field taxonomy crosswalk (~70 string fields, ~15 number fields alone) -- out of scope for this pass.
- BatchUpdateFindingsV2 MetadataUids-based finding identification can never resolve (always ResourceNotFoundException): this backend has no OCSF ingestion path that would ever hand a real client a metadata.uid to reference back. Only FindingIdentifiers (CloudAccountUid/FindingInfoUid/MetadataProductUid, mapped onto AwsAccountId/Id/ProductArn) can resolve a finding.
- (parity-4) CSPM Connector health ConnectorStatus can never leave UNKNOWN, and EnablementStatus can never reach ENABLED: unlike Connectors V2 (which has a dedicated RegisterConnectorV2 to complete an out-of-band OAuth handshake), the real CreateConnector/GetConnector/UpdateConnector/DeleteConnector/ListConnectors surface has NO companion 'complete authorization' operation at all -- establishing connectivity to the Azure account requires a purely external, provider-side step (granting the AWSConfigConnectorArn role access in the Azure portal) that this mock has no API-observable signal for. Auto-advancing a connector to CONNECTED/ENABLED without any real client action causing it would be a fabricated transition, so CreateConnector leaves it at PENDING_ENABLEMENT/UNKNOWN and UpdateConnector leaves it at PENDING_UPDATE permanently. Not attempted this pass -- architectural (no out-of-band signal exists to model), not a bug-fix-sized change.