Creating Public Issues for any SRC Disclosure Reports triaged as not a Vulnerability

## Current State

Currently there are many reports to K8s SRC (Security Response Committee), that are not categorized as vulnerabilities but do merit a bug fix, as it is a valid finding, just not security relevant. SRC typically requests the reporter to open a public issue for this so the community is made aware of it. Often, reporters do not follow through, and no public issue is created.

Without that issue existing and fixed, sometimes duplicate reports pile up. This has become more frequent with AI generated disclosure reports.

## What we are proposing

1. We propose SRC makes the report that is triaged as not a security issue public.
2. These public reports are then converted to GitHub Issues automatically in the appropriate repository
3. Each of these issues gets a common label for easy filtering (label name - tbd)
4. SRC then points their auto-replies for disclosure reports, to these labelled issues

## Benefit to Community

This reduces:
- Burden on SRC to continuously triage known duplicates
- Burden on reporter to open a GitHub issue

This allows:
- Community to become aware of the issues that need a fix
- Opens up new contributor opportunities as these issues are likely going to be detailed enough to begin a fix
- Allows reporters (and their agents) to self-triage their disclosures by looking at this list of issues as known issues

## Scope

* Disclosure reports in kubernetes community only
* Non-security issues that warrant a public fix only

What is out of scope:
* Disclosure reports that are false positives or do not warrant a fix
* Disclosure with noticeable security impact

## Roles and Responsibilities

- SRC:
- Work with hackerone to investigate the best way to make a report public with appropriate redactions in place
- Add to auto-replies the list of issues with a pre-defined label

- SIG Security Tooling:
- Consume these public reports and convert them to appropriate GitHub Issues
- Create new label that apply to these issues

Start by reviewing the proposed SRC and HackerOne workflow, including the redaction, publication, conversion, and auto-reply responsibilities described here. Done means the participating teams have agreed on how eligible reports become GitHub Issues and on the common label and routing process.

Written by the indexing model from the issue text.