Containerized tools for constraint development

[aj-stein-gsa]

This is a ...

research - something needs to be investigated

This relates to ...

• [ ] the FedRAMP OSCAL Registry
• [ ] the FedRAMP OSCAL baselines
• [ ] the Guide to OSCAL-based FedRAMP Content
• [ ] the Guide to OSCAL-based FedRAMP System Security Plans (SSP)
• [ ] the Guide to OSCAL-based FedRAMP Security Assessment Plans (SAP)
• [ ] the Guide to OSCAL-based FedRAMP Security Assessment Results (SAR)
• [ ] the Guide to OSCAL-based FedRAMP Plan of Action and Milestones (POA&M)
• [ ] the FedRAMP SSP OSCAL Template (JSON or XML Format)
• [ ] the FedRAMP SAP OSCAL Template (JSON or XML Format)
• [ ] the FedRAMP SAR OSCAL Template (JSON or XML Format)
• [ ] the FedRAMP POA&M OSCAL Template (JSON or XML Format)
• [X] the FedRAMP OSCAL Validations

User Story

As a developer of software that inputs and outputs OSCAL, I would like streamlined containerized tooling, like the recently published container for consumer user of packaged, ready-to-use constraints, but also for evaluating pre-published developer copies of constraints and testing infra.

Goals

• [ ] Align current release tooling with ongoing development tooling
• [ ] make staff development more effective with rapid development and testing capabilities; and
• [ ] make causual development by community members more effective with rapid development and testing capabilities; and

Dependencies

N/A

Acceptance Criteria

• All FedRAMP Documents Related to OSCAL Adoption (https://github.com/GSA/fedramp-automation) affected by the changes in this issue have been updated.
• A Pull Request (PR) is submitted that fully addresses the goals of this User Story. This issue is referenced in the PR.

Other information

No response

[aj-stein-gsa]

@devbytyler, one of the finer details I was not clear on, from the perspective of you or others, was how much of the dev tooling did you want. This issue could be as tightly scoped as "update the instructions to explain how to override the WIP constraint files with a mount" or make a fuller container with dev tools for the testing harness (the release container only has compiled down oscal-js, but not a full tsc Typescript compiler for the test harness and other things highlighted in the CONTRIBUTING.md for developers. Feedback most certainly welcome from you, other community members, and the FedRAMP Automation Team of course. 😄

[devbytyler]

Thanks for the clarification @aj-stein-gsa. For me, it was mostly just a question of the timing between a new constraint file and a new container image. If that's automated, then I don't think I'd need much else exposed. With that being said, I do believe in the near future that we will be wanting to override/extend the constraint file being used and maybe use some of FedRAMP's rules for other frameworks. For example, we do StateRAMP too, which has some overlap. Not that FedRAMP should be concerned about StateRAMP 😂. (Although... StateRAMP is a gateway drug for FedRAMP.... just sayin).

[aj-stein-gsa]

Per discussion with the community member in https://github.com/GSA/fedramp-automation/issues/683#issuecomment-2346855367, there is not much more need to add or change how constraint information is exposed. I will mark this closed as not planned, but our team, devbytler, or other stakeholders who feel differently can re-open and discuss.