After following Bret Fisher’s lectures about docker containers and Kubernetes, we get to the chapter about security, a topic that I have always liked a lot, at least to take it into account when developing software. Let’s face it, very few development leaders in the consulting world and perhaps in the world of creating software products really take security seriously. In the consulting world I would even say that they see it as a resource to grab clients by the balls, so they can bill the client more and make them see that they are irreplaceable.

Obviously we have to avoid these companies, because they will only act if they are directly affected, for example when they are affected by a case of Ransomware, especially if you are a company that sells security.
The problem with security is that it is very difficult if not impossible to achieve perfect security, you can only try to minimize damage, entry points, follow good guidelines when developing software, be aware when a vulnerability is discovered, of any kind, have a dedicated security team and have the development, CI/CD and security teams talk regularly.

One of the things we can use is to have in the CI/CD process a scanner that tells us the security issues discovered when generating a Docker image.

For example, some time ago I made a small program for a friend, basically a mini web application that loads into RAM a series of values that are in csv format. A super simple thing, a containerized jar using Docker. Two years ago or more I made it, uploaded it to and forgot about it. Well, I just went through trivy and the result is shocking:

  1. Total: 255 (UNKNOWN: 0, LOW: 124, MEDIUM: 122, HIGH: 9, CRITICAL: 0)

This is the source code of the project, by the way.

If we look closely, the application warns us of a series of vulnerabilities discovered in libraries of the operating system that contains the java application that contains the logic, and then there are the vulnerabilities of our app itself. Specifically, the vulnerabilities that appear due to the use of a deprecated version of some library.

We can and should look at these things when maintaining software, have these types of scanners in our CI/CD flow at least and establish measures such as not building the jar or container at least until the critical measures have been resolved, to establish a sensible policy in the company. For another time, I will talk about another type of scanner where I will warn us about good software development practices.


Github allows you to scan your projects for vulnerabilities in your code. Snyk is another company that does the same, I don’t know which one is better, but it’s always good to have alternatives.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s