Components

OSCAL component are the backbone of an OSCAL System Security Plan (SSP), enabling data normalization of inventory, control responses and other key concepts.

Create an SSP component:

• to normalize inventory data
  • Example: instead of listing the same OS and its details in every inventory entry, define an OS compnent and link to it from inventory.
• for control responses
  • Example: if it is appropriate to discuss an Identity, Credential and Access Management (ICAM) solution within a control response, define a component for it. If it is also necessary to discuss just the enterprise directory portion of that solution, consider also defining a component for that capability.
• to represent third party validation
  • Example: For US Government systems required to use FIPS-140-2/3 validated cryptographic modules, create a component for module and a second component representing the validation of that component. Link the two.
• to represent external or underlying (leveraged) systems and services
  • Example: Create a component for each cloud-native service, underlying general support system (GSS), cloud system or external/third-party capability used by your system.

Component Types

All components have a required type field. Certain component types, such as hardware and software have sub-types represented using an asset-type property.