Organizations face numerous primary threats and security concerns
when it comes to their container environments. Those issues extend into their build environment, an area which organizations need to protect
because it’s usually the least secure aspect of their container infrastructure. They also extend into other areas, including inside the containers themselves.
Acknowledging that exposure, organizations should test the code and supplementary components that will execute within containers. Various security features for the software supply chain have arisen since 2017. So too have third-party vendors begun helping to validate container content before and after deployment. These outside tools supplement the process controls and digital signing services offered by base container management platforms with different types of capabilities like static code analysis and known malware signature checks.
Here are six methods in particular that organizations need to make sure they incorporate into their container security testing and validation processes.
Container Validation and Security Testing
Organizations must refrain from running container processes as root, as doing so would provide attackers all-too-easy access to the underlying kernel. They could then leverage that access as a direct path to target other containers and the Docker engine itself. To prevent these threats, companies should use specific ID mappings with restricted permissions for each container class. This will be an ongoing process, as roles and permissions do change over time.
Security Unit Tests
Unit tests are a useful tool for container security. Organizations can run them against specific modules of code without needing to build the entire product for every test case. Overtime, they can help prevent vulnerabilities from creeping into the containers’ code, especially if those tests are implemented during the build process.
Companies should implement some form of code scanning to make sure the code inside the containers are secure. They can do so using third-party products that perform automated binary and white box testing. Alternatively, they can use new tools that function as plugins to Integrated Development Environments (IDEs).
It’s important that organizations check their libraries and supporting code against the Common Vulnerabilities and Exposures (CVE) database in order to determine whether they’re using vulnerable code. Docker and other third parties provide access to tools that make these checks easy. Ideally, these utilities should be integrated into the build pipeline.
In general, it’s a good idea for organizations to adopt a “lean base image” approach, that is, keeping the bare minimum of what’s needed for an application to run. Towards that end, organizations should check for unused items in a container. They should also keep an eye out for hard-coded passwords, keys and other sensitive items. Companies can implement these checks using manual scans or security tools. If they discover something of interest, they can then work with development to verify and remove them.
Container Signing and Chain of Custody
“Image to container drift,” or the addition of unwanted or unauthorized items, is the last thing an organization needs when it comes to their container security. As such, companies need to ensure that a developer didn’t subvert their process with untested code. They can do so by creating a cryptographic digest of all image contents and tracking it to disallow unapproved changes. This is especially key during building, a process where organizations should create specific keys at each phase, sign code snippets on test completion and store the keys securely.
One Piece of the Puzzle
Scanning the contents of a container for vulnerabilities, unused items and other weaknesses is an important part of a container security strategy. But it’s not the only component. Organizations can do much more to secure their containers. For more information on these other aspects, download The Complete Guide to Container Security