committee-security-response
committee-security-response copied to clipboard
Document guide to interpreting CVSS for Kubernetes
It's not always clear how CVSS maps to Kubernetes. To help ensure consistency and reduce decision fatigue, we should document how we interpret and use various adjustments to rate vulnerabilities.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle stale - Mark this issue or PR as rotten with
/lifecycle rotten - Close this issue or PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/triage accepted /lifecycle frozen
I would scope this not at a "Kubernetes" system level - but to each "component" of K8s - ie this should probably be tightly coordinated (if not coupled) to the ongoing SBOM efforts
of course there could be an aggregate roll up of CVSS scores into a single score from those component-scoped scores
@bjornsen is working on this
Here's a document I put together with scoring thoughts. Please have a read and comment.
This issue has not been updated in over 1 year, and should be re-triaged.
You can:
- Confirm that this issue is still relevant with
/triage accepted(org members only) - Close this issue with
/close
For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/
/remove-triage accepted