usnistgov/oscal-cli

Component in OSCAL Component Definition for Systems Using oscal-cli

aj-stein-nist opened this issue · 3 comments

aj-stein-nist commented

User Story:

As a security practicioner and/or OSCAL tool developer, to make the most effective use of OSCAL with this OSCAL tooling, I would like the project to maintain a component-definition with a component detailing what control requirements it supports as part of the NIST SP 800-53 catalog of controls for a FISMA-based security program.

Goals:

  • Successfully dogfood our wonderful information and data models
  • Make a reusable example component for demonstration in our own NIST tools such as usnistgov/oscal-tools and community tools for processing and rendering/presentation of OSCAL content, such as EasyDynamics/oscal-react
  • Document automated testing and manual effort done to support secure development and operation of modern GRC using OSCAL under the hood

Dependencies:

{Describe any previous issues or related work that must be completed to start or complete this issue.}

Acceptance Criteria

  • A component definition is created against control implementation requirements for SP 800-53 and 800-53A
  • The component-definition validates
  • The component-definition is automatically generated (and potentially stored) in all OSCAL data models (JSON, XML, YAML)
  • All website and readme documentation 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.
  • The CI-CD build process runs without any reported errors on the PR. This can be confirmed by reviewing that all checks have passed in the PR.
aj-stein-nist commented

@david-waltermire-nist, let me know if we want an additional one for liboscal-java and/or metaschema-java. :-)

wendellpiez commented

@aj-stein-nist as it happens, part of the reason for my response yesterday is that I had already started taking notes for an "Open Source Policy" CDEF that would enclose/encapsulate usage guidelines for XML stack components (Java or other, OSS or COTS) or in principle non-XML components built on open source principles. I don't know how that would fit or if the scope is right: TBD.

  • 👍1
aj-stein-nist commented

@aj-stein-nist as it happens, part of the reason for my response yesterday is that I had already started taking notes for an "Open Source Policy" CDEF that would enclose/encapsulate usage guidelines for XML stack components (Java or other, OSS or COTS) or in principle non-XML components built on open source principles. I don't know how that would fit or if the scope is right: TBD.

Would love to see what you have drafted for such an "Open Source Policy" CDEF. Let's sync up next week!