Inventory - Virtual Asset

[Rene2mt]

Constraint Task

Consistent with issue #813, these constraint focuses on helping determine if the inventory item is virtual or not by checking for the existence and value of the "virtual" prop.

NOTE - These constraints are level="ERROR"

Intended Outcome

Determine if the asset is "virtual" or not. This is mandatory for all OS/Infrastructure, container, software, and database component / inventory items.

Either the inventory-item itself, or the component linked by the inventory-item MUST have a "virtual" prop indicating whether the item is a physical device or virtual device, such as a virtual server.

NOTE - Ideally, this should check the inventory item first for this property and only check the linked component if not found at the inventory item. They could legitimately conflict, such as if a physical server inventory-item was instantiated using a virtual "software/image" component"

Syntax Type

This is a mix of required, optional, and/or extended syntax.

Allowed Values

Allowed values must be defined or verified.

Metapath(s) to Content

context="//component[@type='software' and ./prop[@name='asset-type' and @value='image']]"

target="."

count(./prop[@name='checksum' and @ns='http://fedramp.gov/ns/oscal']) = 1

Purpose of the OSCAL Content

No response

Dependencies

No response

Acceptance Criteria

• All OSCAL adoption content affected by the change in this issue have been updated in accordance with the Documentation Standards.
  • Explanation is present and accurate
  • sample content is present and accurate
  • Metapath is present, accurate, and does not throw a syntax exception using oscal-cli metaschema metapath eval -e "expression".
• All constraints associated with the review task have been created
• The appropriate example OSCAL file is updated with content that demonstrates the FedRAMP-compliant OSCAL presentation.
• The constraint conforms to the FedRAMP Constraint Style Guide.
  • All automated and manual review items that identify non-conformance are addressed; or technical leads (David Waltermire; AJ Stein) have approved the PR and “override” the style guide requirement.
• Known good test content is created for unit testing.
• Known bad test content is created for unit testing.
• Unit testing is configured to run both known good and known bad test content examples.
• Passing and failing unit tests, and corresponding test vectors in the form of known valid and invalid OSCAL test files, are created or updated for each constraint.
• A Pull Request (PR) is submitted that fully addresses the goals section of the User Story in the issue.
• This issue is referenced in the PR.

Other information

No response