Today, we are excited to share our Sysdig 2020 Container Security Snapshot, which provides a sneak peak into our upcoming 2020 Container Usage Report
As containers and Kubernetes adoption continue to increase, cloud teams are realizing they need to adopt a new workflow that embeds container security into their DevOps processes.
Secure DevOps, a variation of DevSecOps, embeds security and monitoring throughout the application lifecycle, from development through production. This sets you up to deliver applications that are secure, stable, and high performing. This workflow plugs into your existing toolchain and provides a single source of truth across DevOps, developer, and security teams to maximize efficiency.
Dig in to learn about security insights we’ve uncovered from observing real customer environments running containers in production.
What are the top image distros?
Modern software is assembled, not built from scratch. Developers typically use open source base images from various Linux distributions when building their containerized applications.
Sysdig’s data collected from more than 100,000 scanned images highlights that Alpine is the most popular image being used by developers today. This makes sense because Alpine is known for images with a minimal footprint. But ironically, the largest image that was running that we found was also an Alpine-based image that was 10GB!
How big are images?
Although image size depends on the application, based on our data, the average image size observed is 376 MB. The large 10GB Alpine image seems to be an outlier, as it is not a good practice to have a large image unless absolutely necessary. Large images not only take longer to deploy, slowing down release velocity, but they also expose more opportunities for attack.
How many layers are part of an image?
Docker images are composed of several immutable layers, and each one is associated with a unique hash ID. Each layer corresponds to certain instructions in your Dockerfile. These layers are generated when the commands in the Dockerfile are executed during the Docker image build.
What we see is that the average number of layers in a given image is roughly ~ 9.5. The maximum layers observed in the wild was 107! Adding additional layers (for example, via a RUN/ADD/COPY command in a Dockerfile) can impact the performance of your build process, and can also be harder to debug.
What are the top 3rd-party libraries?
Developers also pull in code from open source third-party libraries (non-OS packages) to save time when building and deploying applications. Our data shows npm is the most popular open-source non-OS package.
Where are images typically pulled from?
Images from public sources can be risky, as few are checked for security vulnerabilities. Docker Hub, for example, certifies less than 1% of its nearly three million hosted images. However, we found that 40% of images are pulled from public sources.
What types of vulnerabilities matter?
OS vulnerability snapshot: We noticed that 4% of OS vulnerabilities are high or critical. Although this may seem low, if an OS vulnerability is exploited, it can compromise your entire image and bring down your applications. This is also why there is a heavy focus on scanning for OS vulnerabilities, especially by cloud providers that provide this capability as part of registry scanning (i.e., ECR, GCR, etc.)
Non-OS vulnerability snapshot: What many teams don’t check for are vulnerabilities in third-party libraries. We found that 53% of non-OS packages have high or critical level severity vulnerabilities. Developers might be unknowingly pulling in vulnerabilities from these non-OS open source packages, like Python PIP, Ruby Gem, etc., and introducing security risk.
How common are risky configurations?
While teams understand the need to scan for vulnerabilities, they may not be scanning for common configuration mistakes. What we see is that 58% of images are running as root, allowing for privileged containers that can be compromised.
From talking to our customers, in practice, even if risky configurations are detected at runtime, teams don’t stop containers in order to continue deploying quickly. Instead, they run within a grace period and continuously monitor for deviations from security policies.
Conclusion
When reviewing this year’s data, it’s apparent that security needs to be top of mind for DevOps teams, especially given that open-source components that are widely adopted.
Key data highlights the importance of scanning early in the CI/CD pipeline, both for OS package vulnerabilities and non-OS vulnerabilities that have a large 53% of high/critical severities. 58% of images are also running as root, requiring teams to continuously monitor their containers at runtime and enforce security mechanisms to detect and prevent such risky configurations.
Teams ultimately need to adopt a secure DevOps workflow to ensure they address security across the container lifecycle. To learn more, you can read how to get started with secure DevOps, or sign up for a 30 day free trial with Sysdig. Also, check out our recent cloud native and security reports.