Container Security

Containerized applications are not very different from other types of applications, except that they are packaged in a container. As the means of distribution is different, there are some security concerns that are specific to containers. Also, the security tools and practices are different.

There are two aspects of a container's security:

• The security of the container's content, i.e. the Docker image. This is not much different from the security of any other software. But containers play an important role here, as they have standardized the way we package and distribute software. There is an ecosystem of tools and services built around containers, that we would focus on in the first part of the book.
• The security of the container's runtime, i.e. the container itself, and the host machine. This is more specific to containers. As containers share the same kernel with the host machine, there are some security concerns that we need to be aware of. We will discuss these concerns in the second part of the book.

Containers unified the toolbox for different types of applications. Back in the day, a Java developer perhaps wouldn't use the same tools as a Python developer. Now, they use Docker, perhaps DevContainers, a tool to scan the Docker images for vulnerabilities and license compliance, and a tool to deploy the whole thing to Kubernetes.

Vulnerability Scanning

Java developers remember Log4Shell as the most critical vulnerability incident of 2021. It was a vulnerability in the Log4j library that allowed remote code execution. Log4j is a Java logging library that is used in many Java applications. It's also used in many Java libraries, like Apache Kafka and Apache Spark. It's so popular I have never seen a decent Java application that doesn't use it. When the vulnerability was discovered, it was already exploited in the wild. It was so critical that it was assigned the highest CVSS score of 10.0.

But what's a CVSS score? CVSS stands for Common Vulnerability Scoring System. It's a standard for assessing the severity of security vulnerabilities. It's a number between 0 and 10. The higher the number, the more severe the vulnerability is. Security vulnerabilities not only have a CVSS score, but they also have a CVE number.

CVE stands for Common Vulnerabilities and Exposures. It's a list of publicly disclosed cybersecurity vulnerabilities. It's maintained by the MITRE Corporation, MITRE being a not-for-profit organization that operates research and development centers sponsored by the federal government of the United States. The Log4Shell vulnerability was assigned the CVE-2021-44228 number. You can look it up on the CVE website: https://www.cve.org/CVERecord?id=CVE-2021-44228.

There you can find information about the vulnerability, including some description, the CVE number, and the affected software. To get more details one can confer NVD's website: https://nvd.nist.gov/vuln/detail/CVE-2021-44228. NVD stands for National Vulnerability Database. It's a database of security vulnerabilities maintained by the United States' National Institute of Standards and Technology (NIST).

With Log4Shell shaking the Java world, the adoption of Software Bill of Materials (SBOMs) has become a hot topic. SBOMs are a list of all the components used in a software project. As an example, the U.S. government has mandated that all software vendors should provide SBOMs for their products.

But what's an SBOM exactly? As discussed earlier, every piece of software has dependencies. And these dependencies have their own dependencies. And so on. An SBOM is a list of all these dependencies. If your final product is a Docker image, then the SBOM is a list of all the packages installed in the image, including the OS packages and the application packages.

Having a Docker image at hand, you can generate an SBOM with the syft tool:

$ syft docker://<image-name>

Docker integrated syft into the Docker CLI, so you can also generate an SBOM with the docker sbom command:

$ docker sbom gitweekly/git-weekly

---

Note. The docker sbom command which is included in Docker Desktop, is softly deprecated in favor of Docker Scout: docker scout sbom gitweekly/git-weekly. Still, you can use the docker sbom command in the Docker Desktop, and by installing the SBOM CLI plugin.

---

SBOMs are important for security, as they help us to identify the vulnerabilities in our software. There are tools that can scan SBOMs and generate reports about the vulnerabilities in the software. We will get to those in the next chapter.

Exercises

1. Using either Docker CLI or Syft, generate an SBOM for the ubuntu image.

2. Using either Docker CLI or Syft, generate an SBOM for the alpine image. How does the list of dependencies differ from the ubuntu image?

3. Using Docker Scout CLI, list the CVEs in the gitweekly/git-weekly image:

   $ docker scout cves gitweekly/git-weekly
   

   Choose one of the CVEs, say CVE-2023-24540, and look it up on the CVE website: https://www.cve.org/CVERecord?id=CVE-2023-24540.
   Then look it up on the NVD website: https://nvd.nist.gov/vuln/detail/CVE-2023-24540.
   Docker Scout also has its own CVE website where you can look up CVEs: https://scout.docker.com/v/CVE-2023-24540.
   What's the CVSS score of the CVE?