Official CVE feed: add OSV schema JSON feed

[mtardy]

Posting an update: it seems that many people from the community are doing effort on the CVEs for k8s, to my knowledge, today we have:

• The official CVE feed https://kubernetes.io/docs/reference/issues-security/official-cve-feed/ which is automated based on GitHub issues from k/k on CVEs.
• People from Aqua have been motivated to create an OSV feed that takes (amongst other things) the official CVE feed as an input https://github.com/kubernetes-sigs/cve-feed-osv/ which needs manual intervention
• We have govulncheck running in the CI but the result are not really exploited yet Scan kubernetes/kubernetes with govulncheck #95.

From the discussions, my understanding is that these projects could unite for a better CVE feed. The main requirement would be for the k8s SRC to have a way to generate the initial source information in OSV format. Indeed, the fact that the automated official CVE feed cannot provide much more information is because we don't have well formed input to consume, detailing for example which versions of k8s are affected (which is an information they provide to SIG release), or which binaries. From what I've been told, the SRC process today is fairly laborious and manual and using OSV could potentially make things simpler.

So I'd love to help to push the initiative forward and see how we can discuss with the SRC to consolidate the information they are already distributing in order to have a structured input for the CVE feeds!

cc @tabbysable @puerco @itaysk

Originally posted by @mtardy in #1

[mtardy]

First step would be to take a look at the OSV format https://ossf.github.io/osv-schema/, and see what is missing from our current formatted information https://kubernetes.io/docs/reference/issues-security/official-cve-feed/ to just have a minimal OSV feed (so only the required field).

• If we already everything in our existing JSON feed (which I doubt) the second step could be to generate a new JSON feed in OSV scheme.
• If we don't have everything, the second step would to get in contact with the SRC and ask them to modify their "new CVE" template to include some structured part that we can parse (so that it doesn't change the way they publish CVE too much and doesn't require more work, it just change the way it's formatted for machine parsing).

Example

If we take CVE issue kubernetes/kubernetes#132151:

• First line is usually the CVSS rating, maybe we could ask for it be consistently on the first line, and only just one line so that we can parse it properly.
• Affected/Fixed versions could be formatted in a machine friendly way
• etc.

We could also use markdown backtick for that:

```osv
field1: value1
field2: value2
```

Not sure what's best.

[mtardy]

/assign 4rivappa

[k8s-ci-robot]

@mtardy: GitHub didn't allow me to assign the following users: 4rivappa.

Note that only kubernetes members with read permissions, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time.
For more information please see the contributor guide

In response to this:

/assign 4rivappa

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[4rivappa]

I would like to look into this issue.

[mtardy]

/assign 4rivappa

[4rivappa]

Hi @mtardy and Team

Regarding the required fields for OSV feed to be valid,

The id and modified fields are required. For schema versions above 1.0.0, the schema_version field is also required.

This is at the top level, within individual list fields - there are required fields.
ref: https://ossf.github.io/osv-schema/

Observations on generating OSV feed from official-cve-feed run data:

• The data which we get from issue is unstructured, but still we can extract few fields.

• We cannot determine the introduced, last_affected, fixed versions exactly for the OSV feed.

• If a CVE has been raised before, there must be some structured data for that ID. Like below
  https://cveawg.mitre.org/api/cve/CVE-2025-9708
  From where, we can extract any relevant missing fields we require.

• I observed in OSV feed affected_pkg.severity.score section, we are providing CVSS vectorString instead of actual score (number).

--
In future if we are able to generate OSV feed from Issues data through automation, we can run the final json through the schema validation step.

[tabbysable]

The SRC follows this procedure when we publish new vulnerabilities. The tracking issue in k/k is the canonical public source from which all the other disclosure processes draw.

Here is the template we use when populating the tracking issues.

[mtardy]

We had a good discussion during sig-security-tooling meeting about what we could provide the SRC with to ease the pain to locally incrementally build a document that would contain the CVE information. This information could be then used to generate:

• The GitHub issue, like the existing template now. The issue might still be used by the CVE feed to generate the feed, so we could add machine readable info there directly.
• The JSON to provide the CVE website for public general disclosure (I know less about that format, Tabitha might now)

I think a simple CLI form like tool could help them, I'll try to provide a quick prototype with an explanation elaborating on what I just wrote in this message to see if the SRC finds it useful and wants to continue with that (and then we could collaborate on that project together to enhance that in the sig-security-tooling repo). Keep you posted!