Boostrap oscal generator and subcommand

[puerco]

This command initializes the first oscal output and generator for the base line data.

This lets us generate a first draft of an OSCAL catalog to start testing and iterating on the format.

Here's a sample of the output for feedback
https://gist.github.com/puerco/e4a18354c281d45fc900cfb626adf286

/cc @brandtkeller

Signed-off-by: Adolfo García Veytia (Puerco) [email protected]

[xee5ch]

I would strongly recommend using OSCAL props: [] in the JSON data format) over parts for this.

Here is the official OSCAL documentation for that in the catalog model. They nest inside the control similarly.

[puerco]

Thanks for the feedback, love the suggestion! I've pushed a new commit moving maturity level to a property. Check out the new output here
https://gist.github.com/puerco/e4a18354c281d45fc900cfb626adf286

[brandtkeller]

This will produce the file for all of the content within the catalog model - but if we look at a catalog example we need the catalog object key included for validity of the model.

This can be done a number of ways. Typically we use the complete schema to reference the catalog and encode the complete schema.

go-oscal has a CLI with a validate command that can perform schema validation of models if that is helpful.

[puerco]

Ah thanks for the tip! I've wrapped the doc into a "catalog" label and fixed the validation:

go run . validate --input-file ../ossf/security-baseline/cmd/oscal.json  
go-oscal: 2025/02/20 19:05:13 Successfully validated ../ossf/security-baseline/cmd/oscal.json is valid OSCAL version 1.1.3 catalog

[xee5ch]

I like the update here to use prop, but another minor recommendation given extending and customizing data, it might make sense to namespace (with ns) that maturity-level has a specific meaning in the context of OpenSSF and if other organizations have a similar prop, they do not "collide" with its use or downstream code assumes some other group's use of the term applies here. The go-oscal library seems to support this, so I'd recommend picking a ns URL to use in props and other things and sticking to it through the codebase for namespacing per the guidance.

I am not saying it has to be that specific value, but just giving you an idea of where I am going with it.

Suggested change

	Props: &[]oscal.Property{
	{
	Name: "maturity-level",
	UUID: catalogUUID,
	Value: fmt.Sprintf("%d", criteria.MaturityLevel),
	},
	Props: &[]oscal.Property{
	{
	Ns: "http://openssf.org/ns/oscal",
	Name: "maturity-level",
	UUID: catalogUUID,
	Value: fmt.Sprintf("%d", criteria.MaturityLevel),
	},

[puerco]

I took out the maturity level for now as I need to introduce some changes to the new schema to handle them properly.

[xee5ch]

I would recommend per the OSCAL docs on /catalog/parts/@name to change this to example.

Suggested change

	pts := append(*newCtl.Parts, oscal.Part{
	ID: strings.TrimPrefix(criteria.ID, "OSPS-") + "_implementation",
	Name: "implementation",
	Prose: strings.TrimSpace(criteria.Implementation),
	})
	pts := append(*newCtl.Parts, oscal.Part{
	ID: strings.TrimPrefix(criteria.ID, "OSPS-") + "_example",
	Name: "example",
	Prose: strings.TrimSpace(criteria.Implementation),
	})

[puerco]

This one was also deprecated with the new schema

[puerco]

@xee5ch I see that the NIST namespace url (https://csrc.nist.gov/ns/oscal) does not return anything. Does this mean that the IRI is just used as a label?

Going through the docs it seems that the namespace does not really need to be defined anywhere, other linked data formats namespace with an URI/IRI but also expect a definition file (for example the Context in JSONLD).

I guess we are fine just defining our namespace and not really worrying about writing a definition?

[xee5ch]

Correct it is just a label.

[puerco]

OK, I pushed commits with updates for the new schema and to fix the validation with @defenseunicorns go-oscal.

The new output is published here: https://gist.github.com/puerco/e4a18354c281d45fc900cfb626adf286