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

Required 'asset-id' prop under inventory-items>implemented-components #2043

Open
1 of 3 tasks
Telos-sa opened this issue Sep 16, 2024 · 6 comments
Open
1 of 3 tasks

Comments

@Telos-sa
Copy link

User Story

Screenshot 2024-09-16 at 10 11 53 AM

The oscal-cli requires there be a prop under inventory-items>implemented-components with name="asset-id". This is not outlined anywhere in the schema or the outline of the SSP.

Goals

Screenshot 2024-09-16 at 10 17 42 AM

Reflect in the schema and outline that the 'props' array is required and that one matching name="asset-id" is necessary.

Alternatively, "asset-id" could be changed into an actual (required) schema element under implemented-components rather than being represented as a prop.

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

@iMichaela
Copy link
Contributor

@Telos-sa - OSCAL schema never had an inventory-item/implemented-components/asset-id please check with all released versions. Please provide the oscal-cli version .

I am guessing you are using the oscal-cli released/used by FedRAMP and not NIST which most likely was generated not from NIST OSCAL metaschema definitions.

If such assembly is needed by others as well, we need to work it with the community, BUT it cannot be mandated since it will cause backward incompatibility.

@Telos-sa
Copy link
Author

I am using oscal-cli version v1.0.3 from https://github.com/usnistgov/oscal-cli.

Screenshot 2024-09-16 at 3 55 39 PM

The error log is suggesting that inventory-items>implemented-components requires a prop with name="asset-id". There is no implemented-components>asset-id element.

The issue I see with this, is that there is nothing in the v1.1.2 metaschema that indicates that props is a required element for implemented-components, and also nothing indicating that a prop with name="asset-id" is required.

@iMichaela
Copy link
Contributor

I am using oscal-cli version v1.0.3 from https://github.com/usnistgov/oscal-cli.

Screenshot 2024-09-16 at 3 55 39 PM The error log is suggesting that inventory-items>implemented-components requires a **prop** with **name="asset-id"**. There is no implemented-components>asset-id element.

The issue I see with this, is that there is nothing in the v1.1.2 metaschema that indicates that props is a required element for implemented-components, and also nothing indicating that a prop with name="asset-id" is required.

I am sorry for misunderstanding your note above. This is a constraint documented with all OSCAL constraints in the References. For this particular constraint, please see: https://pages.nist.gov/OSCAL-Reference/models/v1.1.2/system-security-plan/json-reference/#/system-security-plan/system-implementation/inventory-items

The cardinality is documented in References under the implemented-component: https://pages.nist.gov/OSCAL-Reference/models/v1.1.2/system-security-plan/json-reference/#/system-security-plan/system-implementation/inventory-items/implemented-components , see:

HAS CARDINALITY:  for prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal') and @name='asset-id'] the cardinality of prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal') and @name='asset-id'] is constrained: 1; maximum unbounded.

This information (the documentation) is automatically generated front eh OSCAL metaschema definition. I can provide details (where to find it ) , if interest exists.

@iMichaela
Copy link
Contributor

If no additional information is needed under this issue, I recommend we close it.

@Telos-sa
Copy link
Author

What is the user story for this constraint? This section already requires a component-uuid, so is it requiring the id of the asset as well? In most cases the uuid is adequate for establishing a reference point.

And also recommending that this constraint is removed, and if it can't be removed, at least make this 'props' sub-element required (as it is required by the validator).

@iMichaela
Copy link
Contributor

What is the user story for this constraint? This section already requires a component-uuid, so is it requiring the id of the asset as well? In most cases the uuid is adequate for establishing a reference point.

A system's component is not always identical with a system's asset, especially when such component is "this system" aka the entire system. From the analyzed data when we developed OSCAL (SSP model) we found that organizations have specific identifiers that are used to uniquely identify a logical or tangible item (e.g. Router S/N or P/N #) and sometimes asset tags.

And also recommending that this constraint is removed, and if it can't be removed, at least make this 'props' sub-element required (as it is required by the validator).

The oscal-cli is checking artifacts for correctness against the schema PLUS the constraints defined (cardinality included). This particular cardinality constraint makes the prop mandatory BUT only under the OSCAL namespace.

Making the prop mandatory will not be the same with enforcing the cardinality for this @name="asset-id", not to mention that it will break the backward compatibility, so such change is not possible to consider until OSCAL v2.0.

Reducing the number of constraints is something that I am open to do as long as it is not affecting tools' ability of understanding the data or degrades OSCAL's ability of representing high-quality data in support of automation.

Obtaining community's support for this request is also expected.

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