Add guidance on when to handle reported vulnerabilities publicly and semi-publicly #28
Conversation
k8s-ci-robot
added
cncf-cla: yes
k8s-ci-robot
added
the
size/XS
security-release-process.md
Outdated
|
|
||
| If the CVSS score is under 4.0 ([a low severity score](https://www.first.org/cvss/specification-document#i5)) or the assessed risk is low the Fix Team can decide to slow the release process down in the face of holidays, developer bandwidth, etc. These decisions must be discussed on the security@kubernetes.io mailing list. | ||
|
|
||
| If the CVSS score is under 7.0 (a medium severity score), the Fix Lead may choose to carry out the fix semi-publicly. This means that PRs are made directly in the public kubernetes/kubernetes repo, while restricting discussion of the security aspects to private channels. The fix lead will make the determination whether there would be user harm in handling the fix publicly that outweighs the benefits of open engagement with the community. |
There was a problem hiding this comment.
If the CVSS score is under 7.0 (a medium severity score), or with the agreement of the PSC, the Fix Lead...
CVSS scoring is a very imperfect tool. We should acknowledge there's also some discretion here.
security-release-process.md
Outdated
|
|
||
| If the CVSS score is under 7.0 (a medium severity score), the Fix Lead may choose to carry out the fix semi-publicly. This means that PRs are made directly in the public kubernetes/kubernetes repo, while restricting discussion of the security aspects to private channels. The fix lead will make the determination whether there would be user harm in handling the fix publicly that outweighs the benefits of open engagement with the community. | ||
|
|
||
| If the vulnerability requires [User Interaction](https://www.first.org/cvss/user-guide#5-4-User-Interaction), especially in client components like kubectl, the Fix Lead may choose to disclose the vulnerability before a fix is developed if they determine that users would be better off being warned against a specific interaction. |
There was a problem hiding this comment.
Should we generalize this to include vulnerability with straightforward mitigation strategies? The implication being that if it requires user interaction, the mitigation is "don't do it" or "be careful"?
There was a problem hiding this comment.
Yeah, if we are pretty sure that a mitigation is ~always possible and mostly not disruptive, I think that falls into the same category.
I worry about making assumptions about how "straightforward" given mitigations are...
There was a problem hiding this comment.
Added some more generic language.
security-release-process.md
Outdated
|
|
||
| If the CVSS score is under 7.0 (a medium severity score), the Fix Lead may choose to carry out the fix semi-publicly. This means that PRs are made directly in the public kubernetes/kubernetes repo, while restricting discussion of the security aspects to private channels. The fix lead will make the determination whether there would be user harm in handling the fix publicly that outweighs the benefits of open engagement with the community. | ||
|
|
||
| If the vulnerability requires [User Interaction](https://www.first.org/cvss/user-guide#5-4-User-Interaction), especially in client components like kubectl, the Fix Lead may choose to disclose the vulnerability before a fix is developed if they determine that users would be better off being warned against a specific interaction. |
There was a problem hiding this comment.
Would this only apply to Medium and below, or to any vulns?
I have no opposition for Medium and below; in general, I'd be concerned about sharing until there is a fix available.
There was a problem hiding this comment.
I didn't intend to restrict it to Medium and below. I could conceive of some Critical vuln that we would be better off spreading as quickly and as widely as we can, even if the fix wouldn't be out for a week.
Silly example to try to highlight what I'm thinking: If kubectl --v=9 caused your credentials to be sent to a random place in plaintext, we would want to tell as many people as quickly as possible "Don't use --v=9 w/ your kubectl calls." (that contrived example gets me a 9.3 CVSS score)
I couldn't think of a reason why withholding that info until we had a patch would benefit anyone. With some "client-side" things, I worry about their use in server applications (e.g. using kubectl or the client libs in an Operator). But, when rolling out a full mitigation is no harder than rolling out a patch, I don't think we gain anything by waiting for the patch to be available.
I don't think this flexibility applies to vulnerabilities that aren't easy to mitigate. E.g. if the vuln was "any kubectl call using client certs exposes keys," we can't just tell people "stop using your authN method."
There was a problem hiding this comment.
Got it - it just looked like it followed as another rating category. Suggest you maybe rephrase to, "No matter the CVSS score, if the vulnerability..."
Expand scope of "pre-fix" announcements to potentially include anything w/ simple mitigation Clarify that "straightforward mitigation" category applies no matter the CVSS score.
k8s-ci-robot
added
size/S
|
/lgtm |
k8s-ci-robot
added
the
lgtm
|
/lgtm We separately should document what semi-publicly means because I think new release managers, rightfully, are a little confused by how we have handled them in the past. |
|
Let's see if I'm allowed to self-approve... |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cjcullen The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
approved
6 participants
We've had a few recent vulnerabilities that we ad-hoc chose to handle "semi-publicly." I think this was the correct choice in those cases, but our process doesn't mention "fix in the open but quietly" as an option, and I want to make sure we aren't choosing to handle publicly just because we're tired of dealing with other critical vulns. I want to codify our "public option" a little more, both to be more transparent to the rest of the community, and to help guide our own decisions.
@tallclair also made a good point about client-side stuff having slightly different implications, so there's a sentence about that as well.
I'm hoping to talk about this at sig-auth on 5/1 to get some more input from folks who may have thought through this in other places.