OpenSCAP plugin overwrites requirement ID, breaking control ID resolution in scan output

[gvauter]

Description

The complyctl scan output always shows - in the CONTROL ID column for OpenSCAP-evaluated policies. This happens because the OpenSCAP plugin replaces the requirement ID it receives from the policy with the XCCDF rule short name parsed from the OVAL check reference.

Expected Behavior

The scan summary should display the control ID from the catalog (e.g., LVMS-ACCESS-01) next to each requirement in the output table.

Actual Behavior

The CONTROL ID column is always -.

REQUIREMENT ID               CONTROL ID  STATUS  MESSAGE
configure_ssh_crypto_policy  -           ⚠️      Configure SSH to use System Crypto Policy (error)
sshd_disable_root_login      -           ⚠️      Disable SSH Root Login (error)

Additional context

The control ID resolution in scan_summary.go uses reqToControl[a.RequirementID], where the reqToControl map is built from the catalog's assessment requirement IDs (e.g., LVMS-ACCESS-01.AR01 -> LVMS-ACCESS-01). However, the OpenSCAP plugin (cmd/openscap-plugin/server/server.go, lines 192-203) does not return the RequirementID it was given via the assessment configuration. Instead, it parses the OVAL check reference from the ARF XML and extracts the XCCDF rule short name:

requirementID, err := parseCheck(ovalRefEl)  // extracts "sshd_disable_root_login"
assessments = append(assessments, plugin.AssessmentLog{
    RequirementID: requirementID,            // overwrites with XCCDF rule name

The lookup then fails because the map has catalog AR IDs as keys but the plugin returns XCCDF rule short names:
Map key: LVMS-ACCESS-01.AR01 (from catalog)
Lookup key: sshd_disable_root_login (from plugin)
Result: no match, falls back to -
This affects all OpenSCAP-evaluated policies, including the existing cis-fedora-l1-workstation bundle.

Possible Fix

The plugin receives both PlanID and RequirementID in the AssessmentConfiguration. It should either:

• Preserve the original RequirementID from the configuration in the returned AssessmentLog, or
• Build an internal mapping from XCCDF rule short name back to the original requirement ID so the response uses the catalog-aligned identifier

Option 1 is simpler. The XCCDF rule name is already available as the PlanID and in the step Name field, so no information is lost.

[gvauter]

After some further research, this actually seems to be addressable by updating the Gemara content without needing to adjust the plugin logic.

The Fix: Align the assessment-requirements[].id in the catalog to match the assessment-plans[].id in the policy. Also set each policy plan's requirement-id to match its own id.