add sarif support for resolve function

[wandmagic]

User Story: As a developer

I would like resolve functions to support optional SARIF format error output so that I can better track, analyze and integrate error reporting.

Goals:

Enable resolve functions to optionally output errors in SARIF (Static Analysis Results Interchange Format) format to provide standardized, detailed error reporting that can be consumed by various development tools.

Key requirements:

• Add optional SARIF output format for error reporting in resolve functions
• Support capturing runtime errors, validation errors, and other issues
• Include relevant metadata like error location, severity, and error code
• Allow integration with existing SARIF-compatible tools and CI/CD pipelines

Dependencies:

• SARIF specification implementation library
• Error handling middleware/utilities that can format errors into SARIF
• Test infrastructure for validating SARIF output

Acceptance Criteria

• [ ] All website and readme documentation affected by the changes in this issue have been updated
• [ ] A Pull Request (PR) is submitted that fully addresses the goals of this User Story. This issue is referenced in the PR
• [ ] The CI-CD build process runs without any reported errors on the PR. This can be confirmed by reviewing that all checks have passed in the PR
• [ ] Resolve functions include an option to output errors in valid SARIF 2.1.0 format
• [ ] Error output includes required SARIF fields (tool info, results, locations)
• [ ] Runtime errors are properly captured and formatted in SARIF
• [ ] Unit tests verify SARIF output structure and content
• [ ] Documentation includes examples of SARIF error output and configuration
• [ ] Performance impact of SARIF formatting is minimal and documented

[aj-stein-gsa]

@david-waltermire I had a conversation related to this request later in the afternoon with @wandmagic. Is it possible, given what I know about "the sandwich" of commands up through m-j, lo-j, and oscal-cli to validate the profile (I am not sure the full scope of the disabled feature, but it seems relevant per https://github.com/metaschema-framework/oscal-cli/blob/ef2fe6fef5b4e3a20370f24a5390b614daa156f5/src/main/java/gov/nist/secauto/oscal/tools/cli/core/commands/AbstractResolveCommand.java#L167-L198) and opt to validate with inline STDOUT/STDERR output and optionally SARIF? Paul sees a need in conjunction with the server work as a result in the https://github.com/GSA/fedramp-automation/issues/719.

Thoughts?

[david-waltermire]

Yeah. We could add a --validate switch for this. In the mean time, you can always resolve then validate in separate commands. We could also get fancy and have --validate-source and --validate-output. We would need a switch for the SARIF output. Maybe --sarif or something similar?

[aj-stein-gsa]

Yeah. We could add a --validate switch for this. In the mean time, you can always resolve then validate in separate commands. We could also get fancy and have --validate-source and --validate-output. We would need a switch for the SARIF output. Maybe --sarif or something similar?

@wandmagic sounds like Mikey likes it (to translate the TV show reference, Dave and I are Mikey 😆). I think we need to get through lower-level m-j release and update cycle and maybe this is up for grabs in a subsequent release then?