Pre-requisites for generating VEX Documents for Kubernetes using vexflow (Alpha)

# Goal
Implement an automated workflow to generate and publish VEX (Vulnerability Exploitability eXchange)
documents for the Kubernetes project, starting with "not affected" determinations on the master
branch. This uses [vexflow](https://github.com/carabiner-dev/vexflow) as the triage and publishing
engine, with GitHub Issues as the triage backend and sigstore attestations as the publishing target.

## In Scope (Alpha)
- VEX generation for `kubernetes/kubernetes` **master branch only**
- CVEs determined to be **not_affected** only (the five OpenVEX justifications)
- Publishing VEX as sigstore attestations to `kubernetes/.vexflow`
- Bridge tooling from k/k issues to vexflow triage issues

## Out of Scope (Alpha)
- VEX for release branches (v1.31, v1.32, etc.)
- VEX for `affected` or `fixed` statuses
- VEX for container images (OCI referrers API)
- Integration with VexHub
- Replacing the Snyk scanner with OSV or govulncheck

# Proposed worflow

For a more detailed view of the workflow, check [the KEP](https://github.com/kubernetes/enhancements/pull/6376)

1. Snyk prow job detects CVEs and engineers open tracking issues in `kubernetes/kubernetes`
(unchanged).
2. SRC / maintainers analyze the issue (unchanged).
3. **NEW:** When a CVE is determined to not affect Kubernetes, the issue is labeled
`vex-unaffected-feed` (analogous to the existing `official-cve-feed` label).
4. **NEW:** A periodic prow job (Bridge job) creates vexflow triage issues from issues labeled `vex-unaffected-feed` in `kubernetes/kubernetes` into https://github.com/kubernetes/.vexflow, with the expected metadata
5. **NEW:** A second periodic prow job runs `vexflow update` on the triage repository
`kubernetes/.vexflow`, with `--scan=false` and generates VEX attestations

# Prerequisites

## Repositories and Infrastructure

- [ ] **Create `kubernetes/.vexflow` repository**
- Public repository under the `kubernetes` GitHub organization
- Add an OWNERS file with `sig-security-leads` as approvers (vexflow uses this for slash command
authorization)
- Configure GitHub attestation store (sigstore) — the repository must allow attestation uploads
- Request repo creation via
[kubernetes/org](https://github.com/kubernetes/org) following the standard process

- [ ] **Create `vex-unaffected-feed` label in `kubernetes/kubernetes`**
- Define the label in the
[kubernetes/test-infra label config](https://github.com/kubernetes/test-infra/tree/master/label_sync)
or via the k/k repo settings
- Document the label's purpose and usage guidelines

## Prow Jobs (in `kubernetes/test-infra`)

- [ ] **Bridge job: `ci-kubernetes-vex-bridge`**
- Periodic job (e.g., every 6 hours, matching the Snyk scan cadence)
- Configured at `test-infra/config/jobs/kubernetes/sig-security/vex-bridge.yaml`
- Checks out `kubernetes/sig-security` and runs the bridge binary
- Requires: `GITHUB_TOKEN` secret with appropriate permissions
- TestGrid dashboard: `sig-security-vex-feed`

- [ ] **VEX publish job: `ci-kubernetes-vex-publish`**
- Periodic job (e.g., every 6 hours, after the bridge job)
- Runs: `vexflow update --repo kubernetes/kubernetes --branch master --triage-repo kubernetes/.vexflow --scan=false`
- Requires: `GITHUB_TOKEN` secret with write access to `kubernetes/.vexflow` (for issue
management and attestation publishing)
- Sigstore signing: uses keyless signing (Fulcio + Rekor) — no additional key management needed
- TestGrid dashboard: `sig-security-vex-feed`

- [ ] **Presubmit tests for the bridge binary**
- Configured at `test-infra/config/jobs/kubernetes/sig-security/vex-feed-tests.yaml`
- Runs unit tests on PRs touching `sig-security-tooling/vex-feed/`
- Similar to existing `pull-sig-security-cve-feed-unit-tests`

## Secrets and Permissions

- [ ] **GitHub token / GitHub App for `kubernetes/.vexflow`**
- The bridge job needs write access to create issues and post comments in `kubernetes/.vexflow`
- The publish job needs write access for attestation uploads to `kubernetes/.vexflow`
- Both need read access to `kubernetes/kubernetes` issues
- Coordinate with SIG Testing / Prow admins for secret provisioning

- [ ] **Sigstore identity for attestation signing**
- Vexflow uses keyless signing via Fulcio — the signing identity is the OIDC identity of the
prow job's service account
- Verify that the prow cluster's workload identity is configured for Fulcio
- Document the expected signing identity so consumers can verify attestations

# TODOs

## Tooling (in `kubernetes/sig-security`)

- [ ] **Implement the bridge binary**
- Go binary under `sig-security-tooling/vex-feed/hack/` (or a new subdirectory)
- Queries GitHub API for `vex-unaffected-feed` labeled issues in k/k
- Parses CVE IDs and maintainer determinations from issue title, body, and comments
- Maps maintainer analysis to vexflow slash commands (`/not_affected:`)
- Creates vexflow-formatted issues in `kubernetes/.vexflow` (idempotent — skips if issue already
exists for that CVE + branch)
- Posts the slash command as a comment on the created issue
- Needs `GITHUB_TOKEN` secret with write access to `kubernetes/.vexflow` and read access to
`kubernetes/kubernetes`

- [ ] **Define the mapping from k/k issue analysis to vexflow slash commands**
- How to extract the justification category from free-form issue comments
- Consider using structured labels or comment templates in k/k issues to make extraction reliable
- Fallback: don't add any comments and wait for SIG Security team to add slash command and justification manually

Start with the KEP and the existing `pull-sig-security-cve-feed-unit-tests` job, then inspect `test-infra/config/jobs/kubernetes/sig-security/` and `sig-security-tooling/vex-feed/`. Define the bridge binary, job configuration, permissions, and mapping behavior described here; done means the prerequisites and Alpha workflow are implemented and covered by presubmit tests.

Written by the indexing model from the issue text.