Adding validation against the Cue schema

[trumant]

This PR adds a Validate func to the v2/si/SecurityInsights struct that compares the value of the struct against those specified by the schema.

[eddie-knight]

I'm concerned by the 50+ new dependencies added here. Let's hold off on merging this until I can explore any possible alternatives.

[trumant]

I'm concerned by the 50+ new dependencies added here. Let's hold off on merging this until I can explore any possible alternatives.

Yeah, its a bit much.

While I appreciate the expressiveness of cue for the schema, it feels like that choice is proving quite a bit of a friction in terms of serving as the foundational source of truth. The ideal foundational source of truth schema would allow us to easily generate documentation directly from comments/descriptions within the schema file as well as easily generate go types corresponding to the schema type definitions.

The changes in https://github.com/ossf/security-insights-spec/pull/111/files helpfully illustrates the complexity we see today.

Curious if others have felt this pain and considered alternatives to the cue schema, like JSON schema

[trumant]

Well, I just found ossf/security-insights#96 so clearly jsonschema had its own pain

[eddie-knight]

I met on Friday with @myitcv, who is a maintainer of cue-lang. We chatted about the reputational risk of a long requirements list, and the need to keep that tight for our use case.

Let's leave this PR on standby for a bit until we can lock in the best next steps.

[trumant]

cue-lang/cue@51c5fdf looks promising in terms of allowing us to generate rather than manually maintain go types

[myitcv]

@eddie-knight great to catch up last week!

We chatted about the reputational risk of a long requirements list, and the need to keep that tight for our use case.

Indeed, let us report back on this PR once we have had a chance to do some analysis.

cue-lang/cue@51c5fdf looks promising in terms of allowing us to generate rather than manually maintain go types

Yes, @trumant - we have some work-in-progress docs we can share on this very soon! But the command is already live in the latest version of CUE: https://cuelang.org/docs/reference/command/cue-help-exp-gengotypes/

[myitcv]

@trumant - just out of interest, did you close the issue here in favour of generating Go types?

From my perspective, the goal of adding real CUE validation to a process is an entirely reasonable and legitimate goal, and so the dependencies need to reflect that process being lightweight.

We are working on means of cutting down the actual dependencies used by the core CUE evaluator (some work due to land today), and per my discussion with @eddie-knight we also need to look at how to handle the unused modules that appear because of module dependencies being just that, at a module level rather than package level.

[trumant]

@trumant - just out of interest, did you close the issue here in favour of generating Go types?

From my perspective, the goal of adding real CUE validation to a process is an entirely reasonable and legitimate goal, and so the dependencies need to reflect that process being lightweight.

We are working on means of cutting down the actual dependencies used by the core CUE evaluator (some work due to land today), and per my discussion with @eddie-knight we also need to look at how to handle the unused modules that appear because of module dependencies being just that, at a module level rather than package level.

Yes, this is closed in favor of #21

I appreciate the work happening in the cue-lang community to try to trim down the dependencies here.