streamline CVE handling in SCS-0210 with SCS-0124#1099
Conversation
In SCS-0124 we write: --- Critical (CVSS = 9.0 – 10.0): 3 hours High (CVSS = 7.0 – 8.9): 3 days Mid (CVSS = 4.0 – 6.9): 1 month Low (CVSS = 0.1 – 3.9): 3 months --- Our Policies should be the same where possible, so adjust this to match IaaS. Signed-off-by: Felix Kronlage-Dammers <fkr@hazardous.org>
fkr
requested review from
depressiveRobot,
garloff and
mbuechse
as code owners
|
This was noticed by @janeczku and raised in our RKE2 session at the hackathon. |
|
I agree that it may be beneficial to harmonize the two standards, but as far as I can tell, scs-0210 came first, and now I'm wondering why scs-0124 takes precedence. |
Signed-off-by: Felix Kronlage-Dammers <fkr@hazardous.org>
It does not take precedence, but it actually explains the chosen scores much better. Why did we pick 8 for critical in this standard? Technicially only >= 9.0 is critical. High is 7.0 - 8.9 - the IaaS standard explains this and also points to the BSI C5 common criteria. I've updated the change to explain this better. Thanks for highlighting this! |
mbuechse
left a comment
mbuechse
left a comment
There was a problem hiding this comment.
If we now include CVEs with scores 7 through 8, this makes the regulation stricter, but the rule in question is only a recommendation, so we should be good.
or we explain why we chose 8 - that was the question that initially started this discussion and why i looked up what we do for IaaS. |
depressiveRobot
changed the title
Signed-off-by: Felix Kronlage-Dammers <fkr@hazardous.org>
depressiveRobot
changed the title
depressiveRobot
added
kaas-hackathon
KaaS
|
I think this has enough overlap with #1098 that we should link the two? |
|
@depressiveRobot we also said in the session that we should likely introduce a v3 |
Signed-off-by: Felix Kronlage-Dammers <fkr@hazardous.org>
|
I've added a v3 and incorporated the suggestions from @depressiveRobot |
this was a suggestion from @depressiveRobot in #1099, since we link the same document/passage here, adopt this. Signed-off-by: Felix Kronlage-Dammers <fkr@hazardous.org>
This was a suggestion from @depressiveRobot in #1099. Since we link the same document/passage here, adopt this. Signed-off-by: Felix Kronlage-Dammers <fkr@hazardous.org>
| 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. |
There was a problem hiding this comment.
we wanted to drop this, didn't we? I don't see a point in having this for patches that don't contain important security fixes.
There was a problem hiding this comment.
I didn't manage to find concrete resources on Kubernetes patch releases on the hyperscalers. I think they say basically that they do it regularly, but don't give deadlines. I currently would say that we should maybe change it to 4 weeks instead of 2 weeks. This will ensure that providers regularly ship new versions, but also doesn't create too much pressure.
In case someone has a valid reason why 2 weeks are better, I'm totally fine to keep it. I have found to specific reason though why it would be mandatory.
cc @garloff
There was a problem hiding this comment.
We did some research again on this and concluded based on what e.g. BSI C5 says about CVE's with low importance, as well as what some big players say about it, that "less than one month" would be a good compromise. "Less than two weeks" seems extremely harsh looking at the proposed handling of CVE's in the industry and for compliance.
IMO we could open a PR to just change this. Currently "no later than 2 weeks" to then "no later than one month".
There was a problem hiding this comment.
Sounds good to me... Let me open the PR real quick. Also close this one according to the decision by SIG Std/Cert yesterday.
| a new patch version in a 3-day time period after their release, this is in | ||
| accordance with the BSI C5:2020[^1]. | ||
|
|
||
| - This time period MUST be even shorter for patches that fix critical or high CVEs. |
There was a problem hiding this comment.
what does "must be even shorter" mean? Either let's write "must be 3 days" or something else shorter than 3 days.
There was a problem hiding this comment.
I think this is a botched edit, compare w/version 2: https://docs.scs.community/standards/scs-0210-v2-k8s-version-policy#decision
There it makes sense, because the "even shorter" is just an introduction, and the concrete period is stated in a later sentence within the same bullet point.
Signed-off-by: Marvin Frommhold <depressiveRobot@users.noreply.github.com>
|
Closing as decided by SIG Std/Cert yesterday. |
4 participants
In SCS-0124 we write:
Our Policies should be the same where possible, so adjust this to match IaaS.