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

Remove component protocol constraint #2082

Open
3 tasks
Rene2mt opened this issue Nov 26, 2024 · 1 comment
Open
3 tasks

Remove component protocol constraint #2082

Rene2mt opened this issue Nov 26, 2024 · 1 comment

Comments

@Rene2mt
Copy link
Contributor

Rene2mt commented Nov 26, 2024

User Story

As an OSCAL stakeholder, I need to specify port and protocol information for a variety of components in my system (e.g., interconnections, services, etc.), so that the flow of information throughout the accreditation boundary is well documented and understood.

Goals

Currently, validating this example FedRAMP SSP results in an error due to a component of type "interconnection" providing protocol details. The current Metaschema constraint is going to throw an error any time a component that is not "service" type has protocol.

This constraint was removed from src/metaschema/oscal_component_metaschema.xml to resolve issue #1913 and should also be removed from src/metaschema/oscal_implementation-common_metaschema.xml.

Dependencies

No response

Acceptance Criteria

  • All OSCAL website and readme documentation affected by the changes in this issue have been updated. Changes to the OSCAL website can be made in the docs/content directory of your branch.
  • 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.

(For reviewers: The wiki has guidance on code review and overall issue review for completeness.)

Revisions

No response

@brian-ruf
Copy link
Contributor

In general, the constraint on protocol is overly strict. For example, if I implement a RDBMS, the component is type "software" and the database is exposing SQL communication ports. I need to be able to document the ports used by the RDBMS within the "software" component.

Likewise, if I am communicating across my authorization boundary with an external system, I must typically represent that remote system using a "system" component, and need to document any communication ports to which I connect that remote system.

Being unable to capture this protocol/service information on the appropriate components undermines goals such as continuous compliance and compliance-as-code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Needs Triage
Development

No branches or pull requests

2 participants