Veracode Software Composition Analysis now also scans Docker containers and images to find vulnerabilities associated with open source libraries as dependencies of the base OS image and globally installed packages. If you’re interested in understanding how containers work, the different components that make up your container ecosystem, and how that differs from virtualization, we recommend this great overview by Docker.
Do containers introduce new risks?
Containers can introduce new risks to your application due to the installation of a base OS image that you may not have used without the container, but they can also give you greater access and knowledge earlier in the development process. The image itself will often depend on numerous open source libraries that can introduce new vulnerabilities to your application. In addition, containers allow you to install packages at the global level, which previously may not have been accessible to vulnerability scans. It’s also not uncommon for developers to build applications in different environments than what is in production, meaning any vulnerability scans in development may not mirror what is in production. By containerizing applications, developers are able to build in the same environment as the final production platform, allowing them to conduct vulnerability scans on a production-ready image.
Simply using containers isn’t the security risk – it’s not knowing which open source libraries are installed and the vulnerabilities they may present.
How does Veracode secure containers?
Securing your container infrastructure is a huge undertaking that isn’t always clearly defined. Every layer of the container infrastructure can introduce risks, including the hardware, host OS, kernel, Docker engine, registry, base OS image, globally installed packages, and the application. Look to your existing set of vendors and solutions to address each one of them in the same way that you’re addressing OS vulnerabilities on the rest of the network.
As an application security company, Veracode is focused on the application, the base OS image, and the globally installed packages.
Securing containers from open source vulnerabilities isn’t all that different from looking at vulnerabilities in open source libraries in your code. You need to be able to scan your container the moment it’s introduced, with all of its globally installed packages. This enables your development team to decide whether they want to proceed forward with the vulnerabilities present, introduce ways to mitigate the issues, update to a more secure version of the libraries being used, or explore alternative base images and libraries that are more secure.
Divide and conquer: vulnerabilities in application code vs. base OS image
To limit complexity, and to avoid waiting for all applications to be “Dockerized,” Veracode recommends that you divide and conquer the security of the application itself and the security of the container and its dependencies:
- Scan your code before you package it up in a container – fix all of the third-party vulnerabilities, and the flaws found in your first-party code.
- Once your application/code is in a state that is acceptable for production, containerize the application in your pipeline, and then run an open source security scan against the container itself.
Veracode Software Composition Analysis finds vulnerabilities in the base OS image and runtime dependencies
Veracode Software Composition Analysis now looks for vulnerabilities associated with open source libraries as dependencies of the base OS image (CentOS/RHEL) and any packages globally installed with the YUM package manager in a Docker container.
Containers are scanned automatically via an agent in the developer’s CI system, or manually in a developer’s CLI. You can scan your application prior to the containerization and the container itself separately. This provides a clear inventory of all of the dependencies and associated vulnerabilities before pushing it to production.
Finally, Veracode Software Composition Analysis keeps a history of what’s in the container and alerts you to new vulnerabilities, removing the requirement of rescanning the container unless you change its dependencies.
To learn more about open source libraries, and direct vs. indirect dependencies, read the Understanding Your Open Source Risk ebook.