-
Notifications
You must be signed in to change notification settings - Fork 28
Refine CVE check in check script for k8s version policy #779
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from 5 commits
d96edd7
0caf99d
ebfe951
e635411
a298678
cfc3dc6
54ee694
cc87097
38921f1
12987e5
1d332ae
11daeac
e62b347
5ab2bd0
5e2b764
3348960
4a59878
cea9840
c676f5f
f1674fe
f51a46c
48ba4d7
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -55,14 +55,31 @@ window period. | |
| In order to keep up-to-date with the latest Kubernetes features, bug fixes and security improvements, | ||
| the provided Kubernetes versions should be kept up-to-date with new upstream releases: | ||
|
|
||
| - The latest minor version MUST be provided no later than 4 months after release. | ||
| - The latest patch version MUST be provided no later than 2 weeks after release. | ||
| - This time period MUST be even shorter for patches that fix critical CVEs. | ||
| In this context, a critical CVE is a CVE with a CVSS base score >= 8 according | ||
| to the CVSS version used in the original CVE record (e.g., CVSSv3.1). | ||
| It is RECOMMENDED to provide a new patch version in a 2-day time period after their release. | ||
| - New versions MUST be tested before being rolled out on productive infrastructure; | ||
| at least the [CNCF E2E tests][cncf-conformance] should be passed beforehand. | ||
| 1. Minor Versions: | ||
| - The latest minor version MUST be provided no later than 4 months after release. | ||
|
|
||
| 2. Patch Versions: | ||
| - The latest patch version MUST be provided no later than 1 week after release. | ||
| - This time period MUST be even shorter for patches that fix critical CVEs. | ||
| In this context, a critical CVE is a CVE with a CVSS base score >= 8 according | ||
| to the CVSS version used in the original CVE record (e.g., CVSSv3.1). | ||
| It is RECOMMENDED to provide a new patch version in a 2-day time period after their release. | ||
| - New versions MUST be tested before being rolled out on productive infrastructure; | ||
| at least the [CNCF E2E tests][cncf-conformance] should be passed beforehand. | ||
piobig2871 marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| 3. CI Integration | ||
| * Trivy | ||
| - Providers should integrate Trivy into their CI pipeline to automatically scan Kubernetes cluster components, | ||
| including kubelet, apiserver, and others. | ||
| - The CI job MUST fail if critical vulnerabilities (CVSS >= 8) are detected in the cluster components. | ||
| - JSON reports from Trivy scans should be reviewed, and Trivy's experimental status should be monitored for changes | ||
| in output formats. | ||
| * nvdlib (Fallback): | ||
| - If Trivy fails or cannot meet requierements, nvdlib MUST be used as a fallback to query CVE data for Kubernetes | ||
| versions, laveraging CPE-based searches to track vunerabilities for specific versions. | ||
| - Providers using nvdlib MUST periodically query for critical cunerabilities affecting the Kubernetes version in production. | ||
|
|
||
| 4. TBD | ||
|
||
|
|
||
| At the same time, providers must support Kubernetes versions at least as long as the | ||
| official sources as described in [Kubernetes Support Period][k8s-support-period]: | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.