When producing the Docker images that will run as containers, development organizations find themselves with unprecedented influence over the application security posture of their organization.
Whereas in traditional SDLC a programmer only delivers his or her own code, now a programmer can deliver Docker images that contain, in addition to the application code, elements of the base operating system, supporting components, and built-in configuration. This means that the security of operating systems and server components is no longer determined at time of deployment. It is decided much earlier.
Take, for example, a controlled Server environment, where the operating system is selected carefully, patched frequently and configured according to security best practices. Then, a Docker image is deployed and run as a container. This image is a black box, it is running on a well-configured server, but brings with it a completely different operating system and application stack.
To put it in real terms: your extremely well-configured CentOS is now essentially running a version of Ubuntu, taken from the Internet, with an unknown configuration. Adding to the risk is the inability to patch in-place, the speed in which images move through the pipeline and the dynamic way containers are deployed.
The separation of duties between Development and Security -- that division between writing the code and securing the runtime platform -- is no longer sustainable. Development and Security must come together and collaborate in a proper way to move secure, well-built application stacks through the continuous delivery pipeline.
There is a series of steps that organizations can take in order to bring Development and Security closer together:
- Establish and communicate clear and consistent lists of approved base images, application components and coding practices.
- Evaluate image security at development and adopt a practice that will fail the build if the image fails to meet vulnerability thresholds and other security standards.
- Continue to evaluate the security of the images at each stage of the CD pipeline.
- Restrict the ability to update existing images at rest, either on the registry or inside the Docker engine.
- Make the security stance of running containers known to all stakeholders: from application owners, to security and developers.
Experience has taught us that relying on humans alone for the rigorous application of security procedures delivers, at best, patchy results. Where possible, procedures should be automated. This has never been truer than in container-rich DevOps environments, where the speed of delivery and the number of changes are greater than ever before.
A solution that automates and tracks Docker image security – from their inception to their instantiation as containers in runtime environments – must span both the development and runtime environments. While there are many solutions out there that can scan Docker images for vulnerabilities (including open-source tools) they fail to provide a continuous, automated solution to the entire lifecycle of the image. This is where Aqua’s solution can help, with its full lifecycle automation, integration with CI/CD tools and image policy enforcement in runtime - we call it Continuous Image Assurance™.
