Component-definition validate is unable to find json schema file

[CloudBeard]

Describe the bug

I believe this bug is similar to the issue in the past with the ssp validate. Using the current version of oscal-cli I am unable to use component-definition validate. I did test the ssp validate on the fedramp xml file from the previous bug and it works.

If I build from source or copy the install and run

oscal-cli component-definition validate oscal-file.yaml

I get the error

Validating '/home/amills/oscal-component.yaml' as YAML.
An uncaught runtime error occured. null

When I run it with stack trace I get

java.lang.NullPointerException: null
	at gov.nist.secauto.metaschema.model.common.util.ObjectUtils.requireNonNull(ObjectUtils.java:71) ~[gov.nist.secauto.metaschema.metaschema-model-common-0.12.2.jar:?]
	at gov.nist.secauto.oscal.tools.cli.core.commands.componentdefinition.ValidateSubcommand.getOscalJsonSchema(ValidateSubcommand.java:63) ~[gov.nist.secauto.oscal.tools.oscal-cli.cli-core-1.0.2.jar:?]
	at gov.nist.secauto.oscal.tools.cli.core.commands.oscal.AbstractOscalValidationSubcommand$OscalCommandExecutor.getJsonSchema(AbstractOscalValidationSubcommand.java:84) ~[gov.nist.secauto.oscal.tools.oscal-cli.cli-core-1.0.2.jar:?]
	at gov.nist.secauto.metaschema.binding.IBindingContext.validate(IBindingContext.java:317) ~[gov.nist.secauto.metaschema.metaschema-java-binding-0.12.2.jar:?]
	at gov.nist.secauto.metaschema.cli.commands.AbstractValidateContentCommand$AbstractValidationCommandExecutor.execute(AbstractValidateContentCommand.java:255) ~[gov.nist.secauto.metaschema.metaschema-cli-0.12.2.jar:?]
	at gov.nist.secauto.metaschema.cli.processor.CLIProcessor$CallingContext.invokeCommand(CLIProcessor.java:403) ~[gov.nist.secauto.metaschema.cli-processor-0.12.2.jar:?]
	at gov.nist.secauto.metaschema.cli.processor.CLIProcessor$CallingContext.processCommand(CLIProcessor.java:374) [gov.nist.secauto.metaschema.cli-processor-0.12.2.jar:?]
	at gov.nist.secauto.metaschema.cli.processor.CLIProcessor.parseCommand(CLIProcessor.java:192) [gov.nist.secauto.metaschema.cli-processor-0.12.2.jar:?]
	at gov.nist.secauto.metaschema.cli.processor.CLIProcessor.process(CLIProcessor.java:176) [gov.nist.secauto.metaschema.cli-processor-0.12.2.jar:?]
	at gov.nist.secauto.oscal.tools.cli.core.CLI.runCli(CLI.java:78) [gov.nist.secauto.oscal.tools.oscal-cli.cli-core-1.0.2.jar:?]
	at gov.nist.secauto.oscal.tools.cli.core.CLI.main(CLI.java:55) [gov.nist.secauto.oscal.tools.oscal-cli.cli-core-1.0.2.jar:?]

If I do an oscal-cli version I get

oscal-cli 1.0.2 built at 2023-10-03 15:11 from branch main (134d077) at https://github.com/usnistgov/oscal-cli.git
liboscal-java v3.0.1 built at 2023-09-21 20:46 from branch ef1df7e3cd6969dc8264acbe5b633d7886233762 (ef1df7e) at https://github.com/usnistgov/liboscal-java
oscal v1.1.1 built at 2023-09-21 20:46 from branch f24dd56d5569ade8489924cf6fc2640dc297bfbe (f24dd56) at https://github.com/usnistgov/OSCAL.git
metaschema-java 0.12.2 built at 2023-09-19T20:12:43+0000 from branch f50c0658054175fd2d72fb8755404e8a998e0fb3 (f50c065) at https://github.com/usnistgov/metaschema-java
metaschema v0.9.0 built at 2023-09-19T20:12:43+0000 from branch a36f579e1e30abb2263895242cdbd2cf4bd29513 (a36f579) at https://github.com/usnistgov/metaschema

Who is the bug affecting?

Anyone using component-definition validate to validate oscal component schemas.

What is affected by this bug?

Looking to integrate the GitHub action of oscal-cli action which uses the oscal-cli to validate our OSCAL components.

When does this occur?

anytime running the component-definition validate command.

How do we replicate the issue?

1. Install latest version of oscal-cli using either method in the README.md
2. run oscal-cli component-definition validate against an oscal file.
3. see error Validating '/home/amills/oscal-component.yaml' as YAML. An uncaught runtime error occurred. null
4. run oscal-cli component-definition validate --show-stack-trace to get more error info.

Expected behavior (i.e. solution)

Expected to validate the component definition be either pointing out issues or saying the file is correct.

[aj-stein-nist]

Not sure that it will make much of a difference since I see the stack-trace, but two suggestions so you can help us help you:

1. Can you re-run the command as oscal-cli component-definition validate oscal-file.yaml -show-stack-trace?
2. Can you provide the example in question to track down the error in question?

Either way, thanks for your bug report.

[CloudBeard]

Hey @aj-stein-nist thanks for the quick response!

oscal-cli component-definition validate oscal-file.yaml -show-stack-trace       15:48:00 
Validating '/home/amills/defense-unicorns/oscal-file.yaml' as YAML.
An uncaught runtime error occured. null
java.lang.NullPointerException: null
	at gov.nist.secauto.metaschema.model.common.util.ObjectUtils.requireNonNull(ObjectUtils.java:71) ~[gov.nist.secauto.metaschema.metaschema-model-common-0.12.2.jar:?]
	at gov.nist.secauto.oscal.tools.cli.core.commands.componentdefinition.ValidateSubcommand.getOscalJsonSchema(ValidateSubcommand.java:63) ~[gov.nist.secauto.oscal.tools.oscal-cli.cli-core-1.0.2.jar:?]
	at gov.nist.secauto.oscal.tools.cli.core.commands.oscal.AbstractOscalValidationSubcommand$OscalCommandExecutor.getJsonSchema(AbstractOscalValidationSubcommand.java:84) ~[gov.nist.secauto.oscal.tools.oscal-cli.cli-core-1.0.2.jar:?]
	at gov.nist.secauto.metaschema.binding.IBindingContext.validate(IBindingContext.java:317) ~[gov.nist.secauto.metaschema.metaschema-java-binding-0.12.2.jar:?]
	at gov.nist.secauto.metaschema.cli.commands.AbstractValidateContentCommand$AbstractValidationCommandExecutor.execute(AbstractValidateContentCommand.java:255) ~[gov.nist.secauto.metaschema.metaschema-cli-0.12.2.jar:?]
	at gov.nist.secauto.metaschema.cli.processor.CLIProcessor$CallingContext.invokeCommand(CLIProcessor.java:403) ~[gov.nist.secauto.metaschema.cli-processor-0.12.2.jar:?]
	at gov.nist.secauto.metaschema.cli.processor.CLIProcessor$CallingContext.processCommand(CLIProcessor.java:374) [gov.nist.secauto.metaschema.cli-processor-0.12.2.jar:?]
	at gov.nist.secauto.metaschema.cli.processor.CLIProcessor.parseCommand(CLIProcessor.java:192) [gov.nist.secauto.metaschema.cli-processor-0.12.2.jar:?]
	at gov.nist.secauto.metaschema.cli.processor.CLIProcessor.process(CLIProcessor.java:176) [gov.nist.secauto.metaschema.cli-processor-0.12.2.jar:?]
	at gov.nist.secauto.oscal.tools.cli.core.CLI.runCli(CLI.java:78) [gov.nist.secauto.oscal.tools.oscal-cli.cli-core-1.0.2.jar:?]
	at gov.nist.secauto.oscal.tools.cli.core.CLI.main(CLI.java:55) [gov.nist.secauto.oscal.tools.oscal-cli.cli-core-1.0.2.jar:?]

2. I thought it could be my OSCAL file so Ive been testing on https://github.com/usnistgov/oscal-content/blob/main/examples/component-definition/yaml/example-component.yaml

---
component-definition:
  uuid: 8223d65f-57a9-4689-8f06-2a975ae2ad72
  metadata:
    title: Test Component Definition
    last-modified: 2021-06-08T13:57:28.355446-04:00
    version: "20200723"
    oscal-version: 1.0.0
    parties:
      - uuid: ee47836c-877c-4007-bbf3-c9d9bd805a9a
        name: Test Vendor
        type: organization
  components:
    - uuid: b036a6ac-6cff-4066-92bc-74ddfd9ad6fa
      type: software
      title: test component 1
      description: This is a software component that implements basic authentication
        mechanisms.
      responsible-roles:
        - role-id: provider
          party-uuids:
            - ee47836c-877c-4007-bbf3-c9d9bd805a9a
      control-implementations:
        - uuid: cfcdd674-8595-4f98-a9d1-3ac70825c49f
          source: ../../../nist.gov/SP800-53/rev4/json/NIST_SP-800-53_rev4_catalog.json
          description: This is a partial implementation of the SP 800-53 rev4 catalog,
            focusing on the control enhancement AC-2 (3).
          implemented-requirements:
            - uuid: d1016df0-9b5c-4839-86cd-f9c1d113077b
              description: Inactive accounts are automatically disabled based on the
                duration specified by the duration parameter. Disabled accounts are
                expected to be reviewed and removed when appropriate.
              control-id: ac-2.3
        - uuid: 22dbff65-9729-449f-9dfc-4e5fee0906de
          source: https://raw.githubusercontent.com/GSA/fedramp-automation/master/baselines/rev4/json/FedRAMP_rev4_HIGH-baseline_profile.json
          description: This is a partial implementation of the FedRAMP High profile,
            focusing on the control enhancement AC-2 (3).
          implemented-requirements:
            - uuid: 65e30b37-0640-4844-9f42-b2a7ae944bb1
              description: An alternate narrative for FedRAMP..
              control-id: ac-2.3

[aj-stein-nist]

Ah, I see it's one of our own? 🤦 I will quickly examine this for triage and determine what level of effort or fix is needed and follow up. Thanks for reporting.

[aj-stein-nist]

OK: status update, I think I have found the issue, but will need to confirm it later in the day or first thing tomorrow morning. It's the schema locations, and it is specific to the model (CDEF), but the same bug exists for all formats (XML and JSON schemas will throw the same exception). I will update it and try to prioritize a fix.

This relates to #178 and now we have aligned liboscal-java and oscal-cli releases with 1.1.1 models and the previous deadline for that for October 2, 2023, for ... checks notes ... no longer applicable reasons, it will be important next release covers both of these.

Thanks again for reporting, @CloudBeard!

[aj-stein-nist]

@CloudBeard when #201 is merged into develop you can test a snapshot. When develop is merged into a release this will be identified in the release notes and you can use that release. It will be added to the Next milestone until that PR is merged, Ready once merged, and later added to the appropriate release (since this is a low-effort, high-impact bug, expect that in the next 1.0.4 patch release).