Travis Truman
Travis Truman
### What version of CUE are you using (`cue version`)? $ cue version cue version v0.13.0-alpha.4 go version go1.24.2 -buildmode exe -compiler gc -trimpath true CGO_ENABLED 0 GOARCH arm64 GOOS...
## Observed Behavior As a newcomer to the project, I was reading https://github.com/ocsf/ocsf-schema/blob/main/extensions.md?plain=1#L19 and expected to find a directory named `macos` in https://github.com/ocsf/ocsf-schema/tree/main/extensions but I did not. ## Expected Behavior...
We don't know how the last specification PDF was produced in the release and we would like to produce another one that is consistent with the last released version PDF
## Overview https://github.com/search?q=language%3AYAML+path%3Asecurity-insights+%22schema-version%3A+2.0.0%22&type=code shows me 24 insights files using the v2 schema. Reviewing the usage of `header.url` across those samples, I observed that the majority of these projects are using...
## Desired outcome Maintainers of a project that has previously adopted the v1 version of the schema want to easily produce a new insights file using the v2 schema based...
The spec documentation hints at a constraint that is not currently implemented in `schema.cue` The schema declares `header.project-si-source` and `project` as optional, however, the documentation for `project` explains [This field...
https://cuelang.org/docs/concept/schema-definition-use-case/#validating-backwards-compatibility suggests that we might be able to write a Go tool that would give us feedback on changes to `schema.cue` and what they mean with respect to release versioning.
See https://github.com/ossf/security-baseline/pull/390
https://best.openssf.org/SCM-BestPractices/ relates heavily to many controls in the baseline. I propose we better illustrate that relationship by making the following changes - [ ] Update the doc above to reference...