feat(generate)!: initial generate ssp command

docs/cli-commands/lula_generate.md

@@ -25,5 +25,6 @@ Generate a specified compliance artifact template
 
 * [lula](./lula.md)	 - Risk Management as Code
 * [lula generate component](./lula_generate_component.md)	 - Generate a component definition OSCAL template
-* [lula generate profile](./lula_generate_profile.md)	 - Generate a profile OSCAL template
+* [lula generate profile](./lula_generate_profile.md)	 - Generate a profile OSCAL artifact
+* [lula generate system-security-plan](./lula_generate_system-security-plan.md)	 - Generate a system security plan OSCAL artifact
 

docs/cli-commands/lula_generate_profile.md

@@ -5,7 +5,7 @@ type: docs
 ---
 ## lula generate profile
 
-Generate a profile OSCAL template
+Generate a profile OSCAL artifact
 
 ### Synopsis
 

docs/cli-commands/lula_generate_system-security-plan.md

@@ -0,0 +1,50 @@
+---
+title: lula generate system-security-plan
+description: Lula CLI command reference for <code>lula generate system-security-plan</code>.
+type: docs
+---
+## lula generate system-security-plan
+
+Generate a system security plan OSCAL artifact
+
+### Synopsis
+
+Generation of a System Security Plan OSCAL artifact from a source profile along with an optional list of component definitions.
+
+```
+lula generate system-security-plan [flags]
+```
+
+### Examples
+
+```
+
+To generate a system security plan from profile and component definition:
+	lula generate system-security-plan -p <path/to/profile> -c <path/to/component-definition>
+
+To specify the name and filetype of the generated artifact:
+	lula generate system-security-plan -p <path/to/profile> -c <path/to/component-definition> -o my_ssp.yaml
+
+```
+
+### Options
+
+```
+  -c, --components strings                      comma delimited list the paths to the component definitions to include for the SSP
+  -h, --help                                    help for system-security-plan
+  -o, --output-file system-security-plan.yaml   the path to the output file. If not specified, the output file will default to system-security-plan.yaml
+  -p, --profile string                          the path to the imported profile
+      --remarks strings                         Target for remarks population (default [statement])
+```
+
+### Options inherited from parent commands
+
+```
+  -f, --input-file string   Path to a manifest file
+  -l, --log-level string    Log level when running Lula. Valid options are: warn, info, debug, trace (default "info")
+```
+
+### SEE ALSO
+
+* [lula generate](./lula_generate.md)	 - Generate a specified compliance artifact template
+

docs/cli-commands/lula_tools_upgrade.md

@@ -31,7 +31,7 @@ To Upgrade an existing OSCAL file:
   -f, --input-file string          the path to a oscal json schema file
   -o, --output-file string         the path to write the linted oscal json schema file (default is the input file)
   -r, --validation-result string   the path to write the validation result file
-  -v, --version string             the version of the oscal schema to validate against (default is the latest supported version) (default "1.1.2")
+  -v, --version string             the version of the oscal schema to validate against (default is the latest supported version) (default "1.1.3")
 ```
 
 ### Options inherited from parent commands

docs/oscal/system-security-plan.md

@@ -1,25 +1,33 @@
 # System Security Plan
 
-A [System Security Plan](https://pages.nist.gov/OSCAL/resources/concepts/layer/implementation/ssp/) is an OSCAL-specific model to represent a system as a whole. In Lula, the `generate system-security-plan` command creates an `oscal-system-security-plan` object to explain the system as a whole by using the compliance data provided by the `component-definition`. The System Security Plan will detail each contributor and groups of contributors that play any part in the system's lifecycle. It will also include every `component` that make up the system with each `implemented-requirement` that details the controls each tools helps to satisfy and how.
+A [System Security Plan](https://pages.nist.gov/OSCAL/resources/concepts/layer/implementation/ssp/) is an OSCAL-specific model to represent a system. In Lula, the `generate system-security-plan` command creates a representative `system-security-plan` object to describe the system as a whole. The only required input to the command is an OSCAL `profile` that defines the controls the system will implement. Optionally, one to many `component-definitions` can be provided to include the details of the components that make up the system and the respective implementation of the controls.
+
+When defining the components for a particular system and profile combination, it's important to note that the `component-definitions` will need to have a `source` field that equates to the profile source or any imported sources therein. Only components with implemented requirements that match the profile source (or imported sources) will be included in the system security plan.
+
+The System Security Plan will detail each contributor and groups of contributors that play any part in the system's lifecycle. It will also include every `component` that make up the system with each `implemented-requirement` that details the controls each tools helps to satisfy and how.
 
 ```mermaid
-flowchart TD
-    catalog1["Catalog/Profile 1"] --> component1["Component Definition 1"]
-    catalog2["Catalog/Profile 2"] --> component2["Component Definition 2"]
-    catalog3["Catalog/Profile 3"] --> component3["Component Definition 3"]
-
-    component1 --> ssp["System Security Plan (SSP)"]
-    component2 --> ssp["System Security Plan (SSP)"]
-    component3 --> ssp["System Security Plan (SSP)"]
+flowchart LR
+    P1[Child Profile]-->|imported by|P[Profile]
+    C[Catalog]-->|imported by|P
+    C1[Child Catalog]-->|imported by|P1
+
+    P-->|imported by|SSP[System Security Plan]
+    CD1[Component A]-->|sources|C1
+    CD2[Component B]-->|sources|C
+
+    CD1-->|defines|SSP
+    CD2-->|defines|SSP
 ```
 
-## Metadata
+## System Security Plan Content
+### Metadata
 
 Includes all `responsible parties`, `parties`, and `roles` that play a part in the system. Responsible parities are the collection of contributors who are responsible for the maintenance and development of the system. Parties includes any internal or external collection of contributors that contribute to the system or the lifecycle of the system. Roles are the designated positions contributors take within the system and system's lifecycle.
 
 `Version` is the specific revision of the document. `Revision` is a sequential list of revisions such as `predecessor-version`, `successor-version`, and `version-history`. These fields track the history of the document as changes are made.
 
-## System Characteristics
+### System Characteristics
 
 Describes the system and the systems security requirements. This includes the `security-sensitivity-level` which is the overall system's sensitivity categorization as defined by [FIPS-199](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.199.pdf). The system's overall level of expected impact resulting from unauthorized disclosure, modification, or loss of access to information through `security-impact-level` children items of `security-objective-confidentiality`, `security-objective-integrity`, and `security-objective-availability`.
 
@@ -29,37 +37,42 @@ The system characteristics also includes the `authorization-boundary`, `network-
 
 The `system-information` field contains all of the details about the type of data stored, processed, and transmitted by the system. The possible options are `fips-199-low`, `fips-199-moderate`, and `fips-199-high`. Consult NIST [800-60](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-60v2r1.pdf) for help defining the system.
 
-## System Implementation
+### System Implementation
 
 Contains any `leveraged-authorizations`, if used, all `components` used to build the system, all `users` with their type and access levels listed, and `inventory-items` detailing how the overall system is configured. The `inventory-items` is a large collection of everything that lives within the system such as operating systems and infrastructure. In addition the `responsible-parties` are listed and connected to each piece they are responsible for.
 
-## Control Implementation
+### Control Implementation
 
 Contains all of the compliance controls the system must adhere to as outlined within the `profile`. Each `implemented-requirement` is listed detailing the control and the information of how the system meets the control on a `by-component` instance. The component will outline all `export`, `inherited`, and `satisfied` indications for each control the component represents.
 
 ## System Security Plan Generation
 
-**NOTE:** This command is in an active research phase.
-
 To generate a system security plan, you need the following context:
-- The component definition
-- The profile source or catalog source
+* The profile source
+  * Currently, profile resolution (i.e., the ability to extract imported profiles/catalogs) will only work for profiles that have hrefs to resolvable file paths; UUID references to back-matter resources are not supported.
+  * The profile support is limited to `imports` that `include-all`, `include-controls.with-ids`, and `exclude-controls.with-ids`. Support for `matching` and `with-child-controls` will be added in the future.
+* (Optional) list of component definitions linked to the profile
+  * The component definition's implemented requirements will need to have the `source` field that equates to the profile source or any imported sources therein.
+* (Optional) output file path
+* (Optional) list of desired remarks text (e.g., `statement`, `assessment-objective`, etc.)
 
-The following command could generate a system security plan with the above context:
+The following command generates a system security plan:
 
 ```bash
 
-lula generate system-security-plan --component .src/test/unit/valid-component.yaml --catalog https://raw.githubusercontent.com/usnistgov/oscal-content/main/nist.gov/SP800-53/rev5/json/NIST_SP-800-53_rev5_HIGH-baseline-resolved-profile_catalog.json
-
+lula generate system-security-plan --profile profile.yaml --component oscal-component.yaml --remarks assessment-objective --output oscal-system-security-plan.yaml
 ```
 
-There are optional flags that can be added to the command to generate a system security plan:
+In order to create a valid System Security Plan from information readily available, some fields are mocked and marked as `TODO` items. In other words, this command will not currently generate a fully ready to use System Security Plan without some additional work by the user. See [System Security Plan Generate Context](#system-security-plan-generate-context) for more details.
 
-- The output file of the component `-o` or `--output`; `oscal-system-security-plan.yaml`
+> [!NOTE]
+> Additional work has been scoped to identify how to add additional context to the SSP that could be stored in a separate medium and injected upon generation.
 
 ## System Security Plan Generate Context
 
-The `system-security-plan` can be generated using the upstream catalog and/or profile in conjunction with the `component-definition`. There are net new fields that are apart of the `system-security-plan` that are not within the `component-definition` or catalog/profile that currently do not make sense to add as props. Those items are under the section `Elements in SSP Not in Component Definition`. There are items that are not in the `system-security-plan` but also not in the `component-definition` that currently do make sense to create as props. Those items are under the section `Elements NOT in Component Definition that need added for SSP Generate`. Lastly as a note there are items within the `component-definition` that are not used in the `system-security-plan` that can be found under the section Elements NOT in `Component Definition that need added for SSP Generate`.
+The `system-security-plan` can be generated using the upstream profile in conjunction with the `component-definition`. There are net new fields that are apart of the `system-security-plan` that are not within the `component-definition` or catalog/profile that currently do not make sense to add as props. Those items are under the section `Elements in SSP Not in Component Definition`. There are items that are not in the `system-security-plan` but also not in the `component-definition` that currently do make sense to create as props. Those items are under the section `Elements NOT in Component Definition that need added for SSP Generate`. Lastly as a note there are items within the `component-definition` that are not used in the `system-security-plan` that can be found under the section Elements NOT in `Component Definition that need added for SSP Generate`.
+
+For items that could not be derived from other sources, but were necessary to generating a valid SSP, the fields are marked as `TODO` in the output document and are marked below as **Mocked**. Note that the `SystemImplementation.Components` are only Mocked if no components have been provided which match the profile sources and controls (or have intersecting implemented requirements to profile controls).
 
 The items in `Elements in SSP Not in Component Definition` need further context to fill in the missing elements as well as establish data across OSCAL models. Some examples of the data fields are within the `metadata` fields such as `responsible-roles`, `responsible-parties`, and `parties` that can be added to the `system-security-plan` that do not directly map from the `component-definition` field. Additional context can be added through common OSCAL fields such as `props`, `links`, and `remarks`.
 
@@ -88,16 +101,16 @@ The following fields need further research to further enhance generating an SSP.
 - `system-characteristics`
   - `system-ids`
     - `identifier-type`
-    - `id`
-  - `system-name`
+    - `id` - **Mocked**
+  - `system-name` - **Mocked**
   - `system-name-short`
   - `description`
   - `security-sensitivity-level`
   - `system-information`
     - `information-types`
-      - `id`
-      - `title`
-      - `description`
+      - `uuid` - **Mocked**
+      - `title` - **Mocked**
+      - `description` - **Mocked**
       - `security-objective-confidentiality`
       - `security-objective-integrity`
       - `security-objective-availability`
@@ -106,8 +119,8 @@ The following fields need further research to further enhance generating an SSP.
     - `security-objective-integrity`
     - `security-objective-availability`
   - `status`
-    - `state`
-    - `remarks`
+    - `state` - **Mocked**
+    - `remarks` - **Mocked**
   - `authorized-boundary`
     - `description`
     - `props`
@@ -149,10 +162,10 @@ The following fields need further research to further enhance generating an SSP.
   - `remarks`
 - `system-implementation`
   - `users`
-    - `uuid`
-    - `title`
+    - `uuid` - **Mocked**
+    - `title` - **Mocked**
     - `short-name`
-    - `description`
+    - `description` - **Mocked**
     - `props`
     - `links`
     - `role-ids`
@@ -269,14 +282,14 @@ The following fields need further research to further enhance generating an SSP.
         - `remarks`
   - `system-implementation` (Contains Fields from Component Definition)
     - `components`
-      - `uuid`
-      - `type`
-      - `title`
+      - `uuid` - **Mocked**
+      - `type` - **Mocked**
+      - `title` - **Mocked**
       - `description`
       - `purpose`
       - `props`
       - `links`
-      - `status`
+      - `status` - **Mocked**
       - `protocols`
     - `implemented-components`
       - `component-uuid`

src/cmd/generate/generate.go

@@ -5,11 +5,12 @@ import (
 	"strings"
 
 	oscalTypes "github.com/defenseunicorns/go-oscal/src/types/oscal-1-1-3"
+	"github.com/spf13/cobra"
+
 	"github.com/defenseunicorns/lula/src/cmd/common"
 	"github.com/defenseunicorns/lula/src/pkg/common/network"
 	"github.com/defenseunicorns/lula/src/pkg/common/oscal"
 	"github.com/defenseunicorns/lula/src/pkg/message"
-	"github.com/spf13/cobra"
 )
 
 type flags struct {
@@ -187,8 +188,8 @@ func init() {
 
 	generateCmd.AddCommand(generateComponentCmd)
 	generateCmd.AddCommand(GenerateProfileCommand())
+	generateCmd.AddCommand(GenerateSSPCommand())
 	// generateCmd.AddCommand(generateAssessmentPlanCmd)
-	// generateCmd.AddCommand(generateSystemSecurityPlanCmd)
 	// generateCmd.AddCommand(generatePOAMCmd)
 
 	bindGenerateFlags()

src/cmd/generate/profile.go

@@ -4,9 +4,10 @@ import (
 	"fmt"
 	"strings"
 
+	"github.com/spf13/cobra"
+
 	"github.com/defenseunicorns/lula/src/pkg/common/oscal"
 	"github.com/defenseunicorns/lula/src/pkg/message"
-	"github.com/spf13/cobra"
 )
 
 var profileExample = `
@@ -35,7 +36,7 @@ func GenerateProfileCommand() *cobra.Command {
 		Use:     "profile",
 		Aliases: []string{"p"},
 		Args:    cobra.MaximumNArgs(1),
-		Short:   "Generate a profile OSCAL template",
+		Short:   "Generate a profile OSCAL artifact",
 		Long:    profileLong,
 		Example: profileExample,
 		RunE: func(cmd *cobra.Command, args []string) error {