The following members of the Security Response Committee have completed CNA training and can request/assign/publish CVEs for the Kubernetes CNA:
- CJ Cullen (@cjcullen)
<[email protected]>
- Craig Ingram (@cji)
<[email protected]>
- Joel Smith (@joelsmith)
<[email protected]>
- Micah Hausler (@micahhausler)
<[email protected]>
- Mo Khan (@enj)
<[email protected]>
- Rita Zhang (@ritazh)
[email protected]
- Sri Saran Balaji (@SaranBalaji90)
<[email protected]>
- Tabitha Sable (@tabbysable)
<[email protected]>
CNA documents are hosted by MITRE at https://cve.mitre.org/about/documents.html#cna, notably:
- CNA onboarding guides: https://cveproject.github.io/docs/cna/onboarding/index.html
- Also available in video form: https://www.youtube.com/playlist?list=PLWfD9RQVdJ6c4eMkdqbOKqF7zPCqXkgX3
- CNA Rules: https://cve.mitre.org/cve/cna/rules.html
A walkthrough of this handbook is also available in video form.
As of 2022, CVE IDs are dynamcally reserved from MITRE's CVE API. CNA-trained SRC members can use an open-source CLI to reserve new CVE IDs as they are needed. Newly reserved CVE IDs and those previously allocated the Kubernetes project are accessible to the Security Response Committee here
If a new CVE ID is needed to assign to a new issue, and reserved IDs for the current year are exhausted, you can use the command line client cvelib.
Once the CVE ID is received, add it to the tracking sheet as unassigned IDs for future assignment.
If you want to run cvelib in a container, use the following
# Don't quote the values
echo << EOF > env.txt
CVE_USER=${YOUR_EMAIL}
CVE_ORG=kubernetes
CVE_API_KEY=${YOUR_API_KEY}
EOF
cat << EOF > Dockerfile
FROM python:3-slim
RUN pip install cvelib
ENTRYPOINT ["/usr/local/bin/cve"]
EOF
docker build -t $USER/cvelib:latest .
docker run --env-file=env.txt -it --rm $USER/cvelib:latest
By not specifying any arguments, the help output will be displayed. You can then explore the various sub arguments in the CLI. To see the arguments for reserving a single CVE, you can run the following command:
docker run --env-file=env.txt -it --rm $USER/cvelib:latest reserve -h
To see help output on resetting your own API key, you can run the following command:
docker run --env-file=env.txt -it --rm $USER/cvelib:latest user reset-key -h
To see help output on creating a new CNA admin user, you can run the following command:
docker run --env-file=env.txt -it --rm $USER/cvelib:latest user create -h
When a vulnerability report is received, follow the CNA decision tree to determine if this is a valid vulnerability, in scope for the Kubernetes CNA, that has not yet been assigned a CVE ID, and if so, how many distinct vulnerabilities exist in the report.
If a reserved ID is not available, run the following to reserve a new CVE ID or a batch of IDs:
docker run --env-file=env.txt -it --rm $USER/cvelib:latest reserve -h
Assign a reserved ID to the issue, and add at least the following information in the tracking sheet:
- Date reserved
- Description
- Link to the tracking issue in https://github.com/kubernetes-security/security-disclosures/issues (created as part of on-call workflow)
-
Ensure there is a Kubernetes github issue labeled
area/security
whose title contains the CVE ID. This will appear in the issue query linked from https://kubernetes.io/cve. -
Once a vulnerability is made public, populate the CVE details in https://github.com/CVEProject/cvelist. This should be done as soon as reasonably possible after the vulnerability is made public (ideally, O(days)).
-
Generate the CVElist json file
-
See https://github.com/CVEProject/cvelist/blob/master/2023/2xxx/CVE-2023-2727.json as an example.
-
https://vulnogram.github.io/#editor is a useful tool for generating the CVE details, but should only be used once the vulnerability has been made public.
Fill in or update the relevant fields, including:
- State:
PUBLIC
- Assigner:
[email protected]
- Affects: List historical minor versions affected and "prior to 1.x.y" patch versions affected
- Credits: The vulnerability reporter's name
- Description:
The Kubernetes <component> command/component in versions <affected versions> <vulnerability>
- Impact: CVSS impact
- Problem type: Select a problem type from https://cwe.mitre.org/data/definitions/699.html if applicable
- References: Link to the Kubernetes github issue(s) (with type
issue-tracking
) and mailing list announcement (with typemailing-list
) - Source: Link to the Kubernetes github issue(s) and indicate if it was discovered internally or externally
- Work around: indicate workaround steps, if applicable
-
-
Once the cvelist json file is generated, request a review from a CNA-approved SRC member.
-
Once the json file is reviewed, a CNA approved member should run the following to push the update
docker run --env-file=env.txt -v ${PWD}/CVE-xxxx-xxxx.json:/tmp/CVE-xxxx-xxxx.json -it --rm $USER/cvelib:latest publish CVE-xxxx-xxxx -f /tmp/CVE-xxxx-xxxx.json
-
Once the cvelist json file in https://github.com/CVEProject/cvelist is updated, indicate in the tracking sheet that the CVE has been populated.
Once a calendar year has completed, all untriaged reports from that year have been resolved, and no new CVE assignments for that year will be made, update any reserved but unassigned CVE IDs for that calendar year to indicate they were rejected and unused.
-
Run the following:
docker run --env-file=env.txt -it --rm $USER/cvelib:latest reject -h
-
Update the tracking sheet to indicate those CVEs were rejected (see CVE-2019-11256 through CVE-2019-11267 as an example)
This is rarely required, but if later inspection reveals a single CVE was actually two separate vulnerabilities, or two separate CVEs were actually a single vulnerability, CVEs can be split or merged following the process described at https://cve.mitre.org/cve/cna/rules.html#Appendix_E