Share and learn in the Docker community.
Hi all, I’m working on a RHEL 9 server where we have a Docker container setup for our Django app.
I’d like to scan, identify, and fix any vulnerabilities in Docker containers/images.
From my research, I’m considering Trivy and Docker Scout but would love to hear about others’ experiences or any additional tool suggestions. Ideally, the tool would be lightweight and work well with our existing RHEL 9 environment.
Thanks in advance!
Both options are reasonable in terms of applying an image assurance policy, however there are other tools and approaches.
You also (may) want to think about run-time protection given that there are other types of vulnerability which won’t be detected by static scanning (even though that’s a good start).
One thing you haven’t mentioned is whether this is just for your own personal projects or whether you are thinking about this in the context of your work environment ?. If it’s the latter, and depending on the size/security culture, you may have existing security policy(ies) that are maintained by your CISO and require some level of compliance. You may also be part of a regulated industry which can also have a bearing. I’m not saying that there should necessarily be a difference in tooling or approach, but there might be. For example, a company may already have an existing contract for something like GitHub Advanced Security (GHAS) or Snyk or AquaSec (the full product) or … in which case it would make sense to use that.
I assume you are mainly talking about ‘custom’ images (i.e. those maintained by you / your company). However, I would advise not overlooking ‘official’ images published by various organisations since these very often contain vulnerabilities and the route to remediation offers different trade-offs. IMO you should always adopt a zero-trust policy (trust but verify) regardless of the image source, even if you decide to operate different policy depending on vendor.
You will also want to think about how you integrate security vulnerability scanning into your build and deploy automation (CI/CD pipelines/workflows whatever your flavour of that is) to ensure that you are able to detect problems early and prevent deployment (and potentially recall and patch deployments that are later shown to be vulnerable - remember a scan is a ‘point-in-time’ activity and both risks and rules change).
You will be aware that RedHat maintain a repository of ‘approved’ images which include image assurance, so that may be of interest.
HtHs
Fraser
Hi Fraser,
Thank you for your detailed insights.
To address your points:
While we don’t currently have a CI/CD integration for scanning, we are planning to establish a process for consistent vulnerability detection and mitigation, including patching and rescanning as part of our workflow.
Appreciate your guidance on this.
Hey there,
host vulnerability scanning is a whole different ballgame, albeit just as critical for a ‘defense in depth’ approach. But for now I’ll limit my comments specifically to container images and running instances since thats enough to deal with 
It sounds like you are on the right path. The first job is to establish a clear security policy around both vendor provided and custom (internally maintained) images. It is not uncommon for your policy to differ depending on your overall risk appetite (or those of your security team and/or business sponsor). Ultimately it will always be a ‘business risk acceptance’ call. So first off, define what scanning you want to do, when (in the life-cycle), what the policy is in terms of acceptable and non-acceptable risk (typically detection of vulnerabilities within specific severity levels) and then what happens when vulnerabilities are detected and how you evidence that they have been remediated (even if that means ‘won’t fix’).
You also need to think about vulnerabilities (at least) in terms of potential exploits because of the software itself (packages, 3rd party library dependencies, custom application code, etc) and configuration (e.g. risk sensitive data - aka: secrets). Some tools can cover more than one of these (or claim to - caveat emptor !) but most have a primary focus. For example, if you use GitHub, the Dependabot service may cover off SCA (Software Composition Analysis) of your source code whereas GHAS is used for vulnerabilities and secrets. Similarly products like Snyk have separate modules for dependencies, IaC, container, etc.). Invest some time in making sure that you have detailed the vulnerability types you want to mitigate and then compare that against the tools you want to evaluate.
IME, choices around tooling comes afterwards otherwise you are in danger of having your policy dictated by the capability of a particular tool(s). That said, you will typically have to trade off capability against any tooling constraints (many open source tools in this space are very capable but you still get what you pay for to some extent and/or there may be limits on usage or functionality).
In my experience, being consistent both in policy and implementation is probably the most important thing. I would certainly advice against runnning multiple tools although you should abviously do sufficient due dilligence to ensure that the one you select doesn’t ‘paint you into a corner’. That said, as I hinted at above, you may need more than one to ensure you cover off all vulnerability types, just make sure you are clear about what you are using each tool for and ignore any overlaps.
I’ll stop for now because I’m sure you would much rather hear about specific tech than security policy. I too am always drawn to the allure of tech, but unfortunately someone has to describe the context in which security will be applied. Its boring, but ultimatley more important and has a much greater shelf-life than the latest ‘shiny’ tool 
Such is the lot of a Security Eng (my last position).
I chip-in later if there seems like a reason too.