0

When building my own Docker container, if I use a base image such as Debian 10.6 (stable) there are times when high vulnerabilities are found in the OS packages, that have not been fixed in this stable release, yet.

At the point of getting ready to release the container, if high vulnerabilities are found, but there is no way to resolve it (as the packages are up to date in apt), should a release be stopped until the fix is available?

This is an issue when trying to move towards continuous delivery, as the failing tests would identify a high issue, and fail the pipeline, but there would be no way to resolve the issue (other than waiting).

avres
  • 3
  • 3

1 Answers1

0

The answer to this question, as with so many in security is, it depends on your threat model.

What I'd say is that some container vulnerability scanning tools are slightly unusual in that they flag "unfixable" issues for which there is no patched version in the distributions repositories, by default. For example Synk, Trivy, Anchore and Clair, all default to this approach.

Standard Vulnerability assessment tools used for Virtual machine or physical server VA such as Nessus, do not flag CVEs if there is no patch available, by default.

So you have a couple of choices here :-

  1. If your container VA tool has the option, tell it to ignore unpatchable issues (For example, Trivy has the --ignore-unfixed option. For most setups, this is probably the correct choice

  2. Assess each unpatchable issue and decide whether it's relevant to your environment, then add it to a list of "thigns you're not worried about" if it's not.

  3. Compile packages manually to address the CVEs.

One other point to make is that there's a couple of ways of reducing the incidence of these issues

  1. work to minimize the number of packages used by your container images. Things like multi-stage builds are good for this

  2. If possible, consider using things like using static binaries in scratch images, which will largely remove this issue (although it does come with it's own challenges)

Rory McCune
  • 60,923
  • 14
  • 136
  • 217
  • Can you please provide an official reference for the statement "Standard Vulnerability assessment tools used for Virtual machine or physical server VA such as Nessus, do not flag CVEs if there is no patch available, by default" ? – Enos D'Andrea Oct 28 '20 at 14:51
  • Just run any container image through clair/trivy/anchore/synk and then run it through Nessus and Nexpose, the differnce can be easily checked :) Last time I checked debian:stable image Tenable's SAAS container scanner and Rapid7's got 0 results and the others got 48-148 vulns. – Rory McCune Oct 28 '20 at 15:09
  • The easiest one to check would likely be Trivy as it can scan a local filesystem. Just get a debian host, patch it fully and run Nessus and Trivy side by side. you can't easily test Nessus' container scanning, as it's only available (AFAIK) via their SAAS service, I had an eval. for the testing I did. – Rory McCune Oct 28 '20 at 15:11
  • Interesting response, thanks. Food for thought. – avres Oct 28 '20 at 16:24
  • @EnosD'Andrea if you're looking for more info. https://raesene.github.io/blog/2020/11/22/When_Is_A_Vulnerability_Not_A_Vulnerability/ has some. Also has a process to confirm, just compare a Nessus essentials against the output of Trivy and you can see the differences. – Rory McCune Nov 22 '20 at 13:50
  • @RoryMcCune Can you please provide a full report of Trivy whose corresponding Tenable report was empty? I am dubious on whether the medium vilnerabilities reported by one one of the tools are false positive, have no practical impact and/or only refer to misconfigurations. – Enos D'Andrea Nov 22 '20 at 17:48
  • In the post I mention that this is unfixed issues, i.e. CVEs which exist but which there is no patched debian/ubuntu package. That's why Trivy provides the "--ignore-unfixed" flag to address that exact issue. trivy is easy to download/run and it works on any VM or container, so easy for you to validate. – Rory McCune Nov 22 '20 at 19:36