A constant source of debate I've seen between engineers and security teams is how to handle vulnerabilities in internal systems. Specifically, vulnerabilities in linux packages (like gcc, libcurl, openssl, libpng, etc.) inside Docker containers. Many times these packages are not used by the application and they just come with the OS, while other times the packages are used extensively. How do you handle prioritizing and fixing these vulnerabilities in systems that aren't accessible from the public internet? These images are things like databases, caches, internal-only apps, etc. Do you just take the NIST CVSSv3 score as-is? How does this change when the number of vulnerabilities to review is in the hundreds or thousands?

If you need a specific example, say a high severity vulnerability identified in the nfs-utils package on a database container.


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.


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.

| improve this answer | |
  • Thanks for the answer @schroeder! I completely agree that patching is easy and important. I do have a couple follow ups though. 1) how would you convey the importance to engineering teams of patching something like nfs-utils on a database image? I'm often met with the counterargument "since its internal, you would need local access to exploit this, and at that point you're already exploited". 2) You outline a great process for risk assessment, although it is time consuming. Where do you draw the line on performing risk assessment vs too many vulnerabilities to analyze for say, a 5 man team? – JoshA Dec 11 '19 at 19:15
  • 1
    1) exploit chains: they would be correct, but different exploits can chain to allow an external actor the ability to exploit the local-only vulns. But again, you need to map that out. 2) yes, it can be time-consuming, that's why I'm encouraging you to not do it :) - when the automated actions are a barrier to objectives, then you have to spend some time balancing cost/benefit of patching or other mitigations. The more you can standardise those other mitigations and have a resilient environment that allows "safe-fail" conditions on failed mitigations, the better. – schroeder Dec 11 '19 at 19:47

Vulnerability Assessment is the key factor here. I disagree with using the term Vulnerability Management. You cannot manage vulnerabilities as they are not something dependent on your management. It's like saying you want to manage the burglars coming to your store. You don't manage them, you asses what they could do and try to prevent that.

Vulnerability Assessment should take into account two main factors:

  • the severity of a vulnerability (how much can it affect, how much damage can it do if it manifests)

  • the chance of a vulnerability to happen (as in the statistical probability for it to be exploited in your organisation)

Putting the two above together gives you the final rating (details at the end).

For this to work you need to identify the assets and define the risk and critical value for each device. It’s important to identify at least the importance of the device that you have on your network or at least the devices that you’ll test. It’s also important to understand if the devices can be accessed by any member of your company at any time or just administrators and authorized users. This has a great impact on the chance of a vulnerability occurrence part.

You also need to understand the strategic factors involved and have a clearly defined risk tolerance level, a business impact analysis, well established risk mitigation practices and policies for each device type. Also, you need to establish countermeasures for each device or service.

You need to have/gather information about the systems before the actual vulnerability assessment process. Minimal example: review if the device has open ports, processes and services that shouldn’t be started, understanding about the drivers and software used on the devices and their basic configuration.

At this point, you can actually perform vulnerability scans by using the proper tools for the proper target areas.

Finally, make a report on the findings that should include:

  • name of vulnerability
  • date of its discovery
  • a detailed description of the vulnerability
  • details regarding the affected systems/services
  • details regarding the process to correct the vulnerability
  • a proof of concept (PoC)
  • the score, based on the 2 points specified above and the CVE rating (if it exists)

Note: the score should be calculated using established intervals. For example: severity can be chosen between 100 and 500. Chance of occurrence between 1 and 100%. Severity itself can take into account multiple factors, for example: will it affect one device, a few devices (low severity) or all of them/ the whole network (high severity); will it cause something annoying like an error that can be ignored (low severity) or will it cause data loss (high severity).

Final score can be obtained from simply multiplying the two.

As for the patching, it's a good practice but sometimes you will not be able to do it so you will have to relay on your ability to adapt to the situations.

| improve this answer | |
  • 1
    That's not what "Vulnerability Management" means ... you manage them once they emerge ... you don't manage in order to prevent them. Assessment is a stage in the management process, followed by actions. So, yes, if you have burglars in your store, and you can expect more to show up every week, you really do want to manage them. – schroeder Dec 11 '19 at 16:16
  • Your answer also appears to be talking in hypotheticals, as in a high-level risk assessment. Not in terms of identified vulnerabilities, as the question asks. – schroeder Dec 11 '19 at 16:19
  • In the end, I'm not sure if this answers the question and it does not seem practical for the situation offered. And it seems to reflect a traditional server-based environment, and not a containerised environment. In an DevOps environment, and the nfs-utils pkg has a vuln, I have to do all that work for each and every system? And when each "system" is actually a container, how do you do all those steps? – schroeder Dec 11 '19 at 16:23
  • Yes, you still do them, even if at container level. – Overmind Dec 13 '19 at 7:31
  • How do you run a vuln scan on container OS's? Are you expecting an agent installed on each container to report? – schroeder Dec 13 '19 at 7:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.