A
Handle vulnerabilities by using Vulnerability Management
Vulnerability Management includes patching, but so much more. It includes assessing the vulnerability and assessing mitigation actions (of which patching is one) in the control environment.
Do you just take the NIST CVSSv3 score as-is?
Well, yes. There is no need to change the core assessment of the vulnerability, but the CVSS score does not tell you what you should do about it. You need the CVSS score as part of the risk assessment, but you still need to assess the risk in the control environment in which it exists.
For example, if there is a vulnerability that can only be exploited over the network, and the machine does not have the ability to connect to a network, then that threat is mitigated.
It gets more Complex than that
When most people raise this type of question, they are expecting that the Complex problem is meant to be solved with a Simple solution ("Just Patch"). But when patching is not practical, how do you perform a risk assessment that does not end up exposing hidden risks due to the team's lack of experience or perspective?
We all know that the risk assessment can get complex since the technology, the vulnerability, and the control environment can be so complex that people might not ever trust their ability to perform a risk assessment properly or completely. So, when you have to start "making it up as you go along" to meet your unique and situational needs, you need expert advice and carefully chosen layers of controls (Identify, Protect, Detect, Respond, Recover) to prevent the unintended consequences of ad hoc controls in a complex environment. And that's all part of Vulnerability Management, too.
Docker/Containers
So, a Docker or any other containerised environment does not change the fundamentals. Containers can be exposed externally, or not, they can be exposed internally, or not, or they can be restricted to the local host, or not. Just like any other service. You still need to assess the control environment. And when you do, consider the future use of that machine, container, or service. Whatever vulnerabilities you permit to exist counts as a debt that you will have to resolve if you change the use case or the control environment that you used to allow the vulnerability to remain unpatched.
The quick answer
Patching is the simplest, most straightforward, and recommended default action to take. You should have a policy/standard where you patch unless there is a compelling reason not to and you engage compensating processes (Identify, Protect, Detect, Respond, Recover) that take the current and future control environment into consideration.
Rule #1: When in doubt: patch.
Rule #2: When patching presents a material risk to objectives: make sure you know what you are doing.
Rule #3: If you are not sure you know what you are doing: see Rule #1.
