Cesium ion Uses Iron Bank Container Images for Software Security
Introduction
Cesium ion SaaS and Cesium ion Self-Hosted utilize containers to provide Cesium ion. Containers are cloud-native, lightweight, and stand-alone software packages that include everything needed to run a piece of software: the code, runtime, system tools, libraries, and settings. This encapsulation ensures that the software runs consistently across various computing environments, from development to testing and production, regardless of the underlying infrastructure. At the heart of any container is the base image, and Cesium has recently updated base images to use the Red Hat Enterprise Linux Universal Base Image as deployed by Iron Bank. Because containers are smaller than virtual machines, it reduces the surface area to patch and update as part of the software stack.
Containers are smaller than virtual machines, reducing the surface area to patch and update as part of the software stack.
Why Iron Bank?
Iron Bank was created and is maintained by the US Department of Defense (DoD)’s Platform One group. The goal of Iron Bank is to provide trusted and vetted container images that can speed up deployment of commercial and open source software across the DoD. This is possible because there is an open process by which images are created and because the images are continuously monitored and continually updated for Common Vulnerabilities and Exposures (CVEs) as part of the process that builds these images. Trust is an important part of what we do at Cesium, so it’s important that we are able to trust the source of our base container images and that our users are able to trust that we work to ensure a secure product for them.
Mitigating CVEs
CVEs don’t exist only in the base image itself, although that is where most of them are found. To ensure we stay on top of security reports and prevent releasing vulnerabilities to our users, Cesium also scans for CVEs. CVEs are tracked through various internet databases, with contributions by companies, security researchers, and developers. CVEs generally are reported against software as they are discovered and can appear at any layer in your container—the operating system, your build tools, or your software dependencies. At Cesium, we use open source tools like Grype to identify CVEs and then mitigate them by constantly updating our dependencies or removing unnecessary pieces of software from our containers. We run these tools in our continuous integration/continuous deployment (CI/CD) pipelines, so that no release happens without security checks.
Creating a trusted software supply chain
Another important consideration that has received more attention lately is the software supply chain. People consuming software are now more concerned about where their software comes from, how it’s built, and what other software is packaged inside the software they bought. With Iron Bank as the base image, there is a known and open source of the bottom layers of the container stack, including the system libraries and programs that are built on top of the operating system.
Additionally, Cesium takes great care to analyze the JavaScript libraries we’re directly dependent on, as well as those that may be nested inside, to ensure that we are looking at what licenses the software is bundled with, if it contains any vulnerabilities, and if there are updates we should be using. To do this, we generate a Software Bill of Materials (SBOM) using Syft, which analyzes not just the software we’re using but also the dependencies of that software. Using those SBOMs and a tool called Grant, we can determine what licenses our dependencies have so that we can avoid any unfavorable licenses. A full view of what this scanning looks like is illustrated below.
Container image scanning pipeline.
Monitoring continually
In addition to monitoring for CVEs, Cesium also continually monitors our software for security vulnerabilities through Static Application Security Testing (SAST) and secret scanning. SAST analyzes application code to identify potential security vulnerabilities that can be mitigated prior to release. It looks for things like SQL injection, cross-site scripting, and buffer overflows. Secret scanning helps ensure that authentication parameters are not stored in the code, containers, configuration files, or other areas in the released product. The reports generated from these tools allow us to harden our code and provide assurances to users about the security of the Cesium ion environment.
Conclusion
Software security can be hard, and it’s important to be vigilant and confident in the measures taken to ensure your software and your users’ data are secure. In addition to vetting our own software, vetting containers and their stacks can be very complex. Fortunately, we can rely on a solid base with Iron Bank and use sophisticated tools from the open source community to ensure that we are always following security best practices.
Use Cesium ion Self-Hosted to support corporate policies or create air-gapped solutions that meet strict security requirements and can be deployed to remote, disconnected environments. Learn more about using Cesium in your own environment.