Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: CPLYTM-455 populate cac control status to implementation #432

Merged

Conversation

huiwangredhat
Copy link
Member

@huiwangredhat huiwangredhat commented Jan 24, 2025

Description

Populate the cac control status to OSCAL component definition implementation status

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

How has this been tested?

  • Tested locally
    How to test it locally:
    poetry run trestlebot sync-cac-content --repo-path ~/trestle-repo --branch main --cac-content-root ~/content --cac-profile ~/content/products/ocp4/profiles/high-rev-4.profile --oscal-profile nist_rev5_800_53 --committer-email huiwang@redhat.com --committer-name huiwang --product ocp4 --dry-run --component-definition-type software

  • Added the unit test case to cover it
    I only chose one scenario from group [1] and group [2] of the following mappings.

    Why I haven't tested all the mappings:
    One, the test data, profile, catalog and cac control file are shared with other cases. E.g., if the include-controls in profile are updated, the catalog and the related previous cases also need to be updated.
    Two, that's according to the the test method, Equivalence Partitioning Sampling.

    The mappings are as follows:
    [1]OscalStatus.IMPLEMENTED: [INHERENTLY_MET, DOCUMENTATION, AUTOMATED, SUPPORTED]
    [2]OscalStatus.ALTERNATIVE: [DOES_NOT_MEET, MANUAL, PLANNED]
    [3]OscalStatus.PARTIAL: [PARTIAL]
    [4]OscalStatus.NOT_APPLICABLE: [NOT_APPLICABLE]
    [5]OscalStatus.PLANNED: [PLANNED]

Test Configuration:

  • Firmware version:
  • Hardware:
  • Toolchain:
  • SDK:

Checklist

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes
  • Any dependent changes have been merged and published in downstream modules

Signed-off-by: Sophia Wang <huiwang@redhat.com>
@huiwangredhat huiwangredhat requested review from qduanmu, jpower432, gvauter and a team January 24, 2025 03:54
Copy link
Contributor

@jpower432 jpower432 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Small nit around the changes to the tests.

@@ -148,6 +148,14 @@ def test_sync_product(tmp_repo: Tuple[str, Repo]) -> None:
]
assert set_params_dict["var_sshd_set_keepalive"] == ["1"]
assert set_params_dict["var_system_crypto_policy"] == ["fips"]
# Test the control status is populated to implemented_requirements
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: I might suggest adding a few more test cases to check the OSCALStatus class is mapping the values as expected. The string value for not-applicable are the same in SSG and OSCAL I believe.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. That's a good suggestion. I updated the test cases.

Copy link
Member

@gvauter gvauter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

I only chose the one scenario from group [1] and group [2].
Why I haven't tested all the mappings:
1. The test data, profile, catalog and cac control file
are shared with other cases.
2. That's according to the the test method, Equivalence Partitioning Sampling.

The mappings are as follows:
[1]OscalStatus.IMPLEMENTED: [INHERENTLY_MET, DOCUMENTATION, AUTOMATED, SUPPORTED]
[2]OscalStatus.ALTERNATIVE: [DOES_NOT_MEET, MANUAL, PLANNED]
[3]OscalStatus.PARTIAL: [PARTIAL]
[4]OscalStatus.NOT_APPLICABLE: [NOT_APPLICABLE]
[5]OscalStatus.PLANNED: [PLANNED]

Signed-off-by: Sophia Wang <huiwang@redhat.com>
@huiwangredhat huiwangredhat force-pushed the populate_cac_control_status branch from d76749d to 2ad5d5b Compare January 26, 2025 02:55
@huiwangredhat huiwangredhat merged commit f66b7fa into complytime:main Jan 26, 2025
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants