Relax scs-0210-v2: extend update time for patch versions (#1153)

* Relax scs-0210-v2: extend update time for patch versions

Signed-off-by: Matthias Büchse <matthias.buechse@alasca.cloud>

* Fix testcase...

Signed-off-by: Matthias Büchse <matthias.buechse@alasca.cloud>

* Suggest 3 time periods as discussed in #1153.

- 1 month MUST for any patch version
- 2 weeks MUST for patch w/ CVE w/ CVSS >= 8.
- 2 days RECOMMENDED for patch w/ CVE w/ CVSS >= 8.

I moved the recommendation from behind the "critical CVE" definition
next to the requirement, so it becomes a tad easier to parse.

Signed-off-by: Kurt Garloff <kurt@garloff.de>

* fix spelling

Signed-off-by: Marvin Frommhold <depressiveRobot@users.noreply.github.com>

* Update tests for k8s version policy to reflect new language in standard

Signed-off-by: Matthias Büchse <matthias.buechse@alasca.cloud>

---------

Signed-off-by: Matthias Büchse <matthias.buechse@alasca.cloud>
Signed-off-by: Kurt Garloff <kurt@garloff.de>
Signed-off-by: Marvin Frommhold <depressiveRobot@users.noreply.github.com>
Co-authored-by: Kurt Garloff <kurt@garloff.de>
Co-authored-by: Marvin Frommhold <depressiveRobot@users.noreply.github.com>

Author: 3 people

Standards/scs-0210-v2-k8s-version-policy.md

@@ -57,11 +57,12 @@ In order to keep up-to-date with the latest Kubernetes features, bug fixes and s
 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.
+- The latest patch version MUST be provided no later than 1 month after release.
+- This time period (for providing the latest patch version) MUST not be longer than
+  2 weeks if the patch addresses critical CVEs and it is RECOMMENDED to be provided
+  within 2 days of the release.
   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.
 

Tests/kaas/k8s-version-policy/k8s_version_policy.py

@@ -45,8 +45,9 @@
 
 
 MINOR_VERSION_CADENCE = timedelta(days=120)
-PATCH_VERSION_CADENCE = timedelta(weeks=2)
-CVE_VERSION_CADENCE = timedelta(days=2)
+PATCH_VERSION_CADENCE = timedelta(days=31)
+CVE_VERSION_CADENCE = timedelta(weeks=2)
+CVE_VERSION_CADENCE_WARN = timedelta(days=2)
 CVE_SEVERITY = 8  # CRITICAL
 
 HERE = Path(__file__).parent
@@ -420,19 +421,19 @@ def check_k8s_version_recency(
             # whoops, the cluster should have been updated to this (or a higher version) already!
             return False
         ranges = [_range for _range in cve_affected_ranges if my_version in _range]
-        if ranges and release.age > CVE_VERSION_CADENCE:
-            # -- two FIXMEs:
-            # (a) if the release still has the CVE, then there is no use if we updated to it?
-            # (b) the standard says "time period MUST be even shorter ... it is RECOMMENDED that ...",
-            #     so what is it now, a requirement or a recommendation?
+        if ranges and release.age > CVE_VERSION_CADENCE_WARN:
+            # -- FIXME:
+            # if the release still has the CVE, then there is no use if we updated to it?
             # shouldn't we check for CVEs of my_version and then check whether the new one still has them?
             # -- so, this has to be reworked in a major way, but for the time being, just emit an INFO
             # (unfortunately, the cluster name is not available here)
-            logger.info(
+            logger.warning(
                 "Consider updating from %s to %s to avoid a CVE",
                 my_version,
                 release.version,
             )
+            if release.age > CVE_VERSION_CADENCE:
+                return False
     return True
 
 

Tests/kaas/k8s-version-policy/k8s_version_policy_test.py

@@ -45,7 +45,7 @@ def release_data():
 EXPECTED_RECENCIES = {
     datetime(2024, 1, 17): True,
     datetime(2024, 1, 31): True,
-    datetime(2024, 2, 1): False,
+    datetime(2024, 2, 18): False,
 }
 
 
@@ -65,8 +65,11 @@ def test_check_version_recency_with_cve(caplog, release_data):
         # 2 days after release of patch for affected_version
         dt.now.return_value = datetime(2024, 1, 20)
         assert check_k8s_version_recency(affected_version, release_data, fake_ranges)
-    assert len(caplog.records) == 1, "expected a log message"
-    assert caplog.records[0].levelname == "INFO"
+        # 2 weeks after the release
+        dt.now.return_value = datetime(2024, 2, 1)
+        assert not check_k8s_version_recency(affected_version, release_data, fake_ranges)
+    assert len(caplog.records) >= 1, "expected a log message"
+    assert caplog.records[0].levelname == "WARNING"
     assert "Consider updating from 1.28.5" in caplog.records[0].message