sync update to oscal content

[huiwangredhat]

Description:

Add the workflow to sync the CAC content to OSCAL content

Rationale:

• Fixes CPLYTM-627

Review Hints:

This CI/CD relates to several repos:
CAC content
OSCAL content
Trestlebot
Content_test_filtering
The steps of syncing CAC to OSCAL.

• If the PR comes from OSCAL content, it will skip the following actions to avoid unnecessary loops.
• Detect the CAC content update via content-test-filtering PR
• If the PR has some profiles and controls updates that will impact the OSCAL content, it will run the following actions
• Set up the trestle-bot environment, cac-content, oscal-content
• Get the github app installation access token of oscal-content
• Get the mapping of the control, cac profile, oscal profile for each product
• Parse the CAC content update to the inputs of the trestle-bot sync-cac-content CLI and sync the content and push the update to OSCAL content.
• Create PR to oscal-content

I listed my questions:
(It‘s out of date, but they are the reason to the step(Get the mapping of the control, cac profile, oscal profile for each product))

• When the pr has a control update, how to map which --cac-profile and --oscal-profile the component-definition will use? My thought: get mapping of the control, cac profile, oscal profile via a python script(shell is a little bit tricky).
• When the pr has a profile update, how to define the --oscal-profile the component-definition will use? (The --oscal-profile is $$policy_id_level). My thought: Sync all the profiles for the Red Hat products to the OSCAL content first. Get a map of product profile and the oscal profile mapping.
• I created a PR to get the profiles, control files, and levels mapping. We could use this mapping to sync related component definitions.

Additional info:
Run details:

• No detected cac updates: https://github.com/complytime/cac-content/actions/runs/14531793161/job/40772745422
• Detected the controls updates: https://github.com/complytime/cac-content/actions/runs/14530398592/job/40769101643
• Detected the controls and profiles updates: https://github.com/complytime/cac-content/actions/runs/14565914082/job/40855144512
• Detected the rules updates: Skip the rules sync that only need to update the rule title.
  Any change in rules or variables content should not impact the transformation because for transformation we only need to know the ids and values used in control files and profiles.
  There is a case if the rule title is changed. We use this field from rule.yml in the Component Definition. Only this case we need to do a sync. This update details won't in this CI, later it will be improved.

Note, all the syncs base on the inited the catalogs and profiles which are stored on the oscal-content side. The initial should be done after the stories: https://issues.redhat.com/browse/CPLYTM-702, what could tag the profiles for each product; https://issues.redhat.com/browse/CPLYTM-644 which component-definition is removing ANSSI and including CIS

• The design and discussion doc is [here.](https://docs.google.com/document/d/1wby2E7yyoQBFAaRFcWyFr1HNod7726CO3Fs988pvPhM/edit?tab=t.0)

• The CAC content update output format as follows:

{"rules": ["dconf_gnome_enable_smartcard_auth", "dconf_gnome_disable_ctrlaltdel_reboot"], "product": "rhel8", "bash": "True", "ansible": "True"} {"profiles": ["anssi_bp28_enhanced", "anssi_bp28_high", "default", "hipaa"], "product": "rhel10"} {"profiles": ["default", "hipaa", "ospp", "cui"], "product": "rhel9"} {"profiles": ["stig-v1r1"], "product": "ocp4"} {"controls": ["anssi.yml", "section-1.yml", "SRG-OS-000080-GPOS-00048.yml"]}

[marcusburghardt]

When the pr has a control update, how to map which --cac-profile and --oscal-profile the component-definition will use? My thought: get mapping of the control, cac profile, oscal profile via a python script(shell is a little bit tricky).

I agree that using a Python script could be simpler. In CaC multiple profiles can use the same control file, so the approach would be to resolve the profiles to determine which of them are impacted by the control file change. The profile ID on both sides should be the equivalent, so once knowing which profiles in CaC are impacted, it should not be a problem to locate the equivalent profiles in OSCAL.

When the pr has a profile update, how to define the --oscal-profile the component-definition will use? (The --oscal-profile is $$policy_id_level). My thought: Sync all the profiles for the Red Hat products to the OSCAL content first. Get a map of product profile and the oscal profile mapping.

I think it is a good approach.

[marcusburghardt]

@huiwangredhat , I know it is still in draft, but already provided some initial comments.

[marcusburghardt]

Just to confirm, this is only for testing, right? The final version should execute the test whenever a PR is opened.

[huiwangredhat]

The final version should execute the test when a PR is merged with the master. That means the updates are in master, which will trigger the accurate detection of the updates. Then sync the CAC updates to OSCAL content. Due to this PR is still in test stage, I'd like to update it with workflow_dispatch and comment the lines of the current trigger condition.

[marcusburghardt]

I see. I wonder if it would not be valid to have preliminary tests (without actually syncing) when a PR is opened. That way, the author and reviewers have time to check and fix any possible issue in an earlier stage. Then when the PR is merged, synchronization issues would be less expected. But this is something that we can definitely discuss later and easily change if necessary. No worries for now. : )

[huiwangredhat]

@marcusburghardt, I think using PR incremental updates to sync OSCAL content is expected, but there seem to be some issues.
Problem with the Current Filter:
The filter currently checks all updates based on one PR, rather than just the incremental changes per push. This can cause synchronization chaos.
Example Scenario:
A first push in a CAC PR modifies control-file-A.
This triggers a sync PR to update OSCAL content with related changes.
Later, the CAC PR reverts the change to control-file-A.
The component-test-filter detects no changes, so no OSCAL sync occurs.
If the CAC PR is merged into master without changes to control-file-A, but the OSCAL PR still includes updates for it, the result is inconsistent.

I tried to use the latest commit and the parent commit to detect the incremental updates of CAC content, but the author of the CAC PR may push multiple commits at once. This method fails to capture all changes for each push.

Do you have any idea? Or it's acceptable to use the pr closed as the trigger condition I mentioned above?

[huiwangredhat]

@marcusburghardt Thanks for your feedback and suggestions. I will update this PR according to your comments tomorrow. BTW, today I created a PR in trestlebot to get the mapping of profile, the available control file, and the levels. I am going to update the component definitions according to the mapping I got from the PR.

[d10n]

A general comment, in workflows, the gh command is available and might be able to clean up some of the setup and header boilerplate: https://cli.github.com/manual/gh_pr

[huiwangredhat]

A general comment, in workflows, the gh command is available and might be able to clean up some of the setup and header boilerplate: https://cli.github.com/manual/gh_pr

@d10n Thanks for your feedback. I replaced curl with gh except for getting the token part that can't work in gh.

[hbraswelrh]

@huiwangredhat I have tested the syncing updates to oscal-content with:

1. PR#20 in oscal-content which triggered the auto-generated PR Auto-generated PR from OSCAL content 20 #16
2. PR #17 in oscal-content which triggered the auto-generated PR Auto-generated PR from OSCAL content 17 #13

The functionality does not change original CaC/content, but opens the PRs based on those changes identified in the oscal-content repo. I also tested using the content_test_filtering repo.

[hbraswelrh]

@huiwangredhat I tested this PR by including the .github/workflows/sync_updates_to_oscal_content.yml and deleting a rule in cis_rhel8.yml.

I created a new branch (test/hannah-oscal-629) and copied the workflow file from the sync_update_to_oscal_content branch. PR #19 detected the cac-content updates and opened PR #22 in oscal-content.

Therefore, this PR works as expected.

[huiwangredhat]

Close this PR and will sync the workflow after the merge of ComplianceAsCode#13512