kubernetes/committee-security-response

Document guide to interpreting CVSS for Kubernetes

tallclair opened this issue · 6 comments

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/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
  • After 30d of inactivity since lifecycle/rotten was 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