2022 Public Container Report

This time last year, we dissected the top 100 public containers on Docker Hub and published our inaugural public container report. We were surprised to find that even the most commonly used public containers – which have been pulled in Docker Hub more than five, six, seven billion times — have large numbers of vulnerabilities.

As 2022 has suddenly become the year of software supply chain security, our industry has become more invested in the principal components and contributors in our software systems and the associated ripple effects.

Download the 2022 Slim.AI Public Container Report (PDF).

We conducted further research this year because we wanted to believe that it was possible not only to understand the software that you are shipping to production, but also to take actionable steps to make it secure and easy to work with. Excellent security shouldn’t come as a trade-off for developer experience and productivity.

There are automated and easier ways to keep the software supply chain healthy, and not put the burden entirely on the developers to solve the security problems at hand.

We’ve now published a sequel to our original report—the second annual Slim.AI Public Container Report—and in it we’ve explored the delta on that data set from 2021 to today. Let’s find out if a “zero-vulnerability world” is realistic given the current state of container security.

Here's what we found.

Finding #1: There are more high and critical vulnerabilities than ever across all categories.

The report shares that 60% of top public containers have more vulnerabilities today than we saw a year ago. Although we did see certain incidents resolved, new incidents are detected 4 times faster than our “remediation rate.” Most notably, the issues we resolved were mostly negligible, low-severity vulnerabilities, whereas the new ones we found are mostly critical and high-severity. We saw a 50% increase in high-severity instances, followed by a 10% increase in critical vulnerabilities. Today's average public container has 287 vulnerabilities, 30% of which belong to a high/critical category, up from 20% last year.

Finding #2: Component complexity has risen significantly over the past year.

On average, we detected 13% more packages per container. The average container now has almost 400 packages. Considering that each package may have hundreds of thousands of dependencies, as seen in multiple academic studies, this number is supposed to be the tip of the iceberg. Not only are the package counts that are worrisome, but we also saw 2.5 times more licenses and 4 times more layers on average. Using open-source scanning tools takes almost 2 times longer, resulting in wasted time in our CI/CD systems.

Finding #3: A disconnect was found between executives and front-line engineers on their organization’s software supply chain security efforts.

There was a discrepancy between these roles on how difficult it is to remove vulnerabilities. Among executives, 49% in our survey think containers are slimmed and hardened, but those who do the actual work, the front-line engineers and managers, report significantly lower numbers. Our survey found that 88% of developers admit it is challenging to remove vulnerabilities. Moreover, less than 26% say they understand how to slim and harden containers.

Today, many companies and governments are demanding a world with zero vulnerabilities, but our research reveals just how out of reach that goal is given current awareness, tools and techniques.

Download the full report (PDF).

What’s the methodology?

We have been observing and deconstructing hundreds of thousands of containers since 2020 to understand how they are changing over time. This year’s report was a combined effort between our dissection of thousands of popular containers and a developer survey we conducted with a research firm. The second portion is new this year, we partnered with Dimensional Research on a global study of 300 developers, DevOps practitioners, and engineering executives.

We leveraged a dataset on the world’s public containers that’s been a year-plus in the making, consisting of the analysis from more than 17,000 unique container images. Our initial set of 165 containers was selected based on both quantitative data (i.e., pull volume) and qualitative data (interviews with engineering teams) to best represent current usage in the cloud ecosystem. We examine a combination of base images (including language-specific ones like python:latest) and standalone applications (like grafana).

Only the ‘latest’ tags were included in our analysis, or equivalent for all containers for the sake of comparison. We acknowledge these are often larger and less secure than `alpine` or `slim` alternatives, and that those more minimal images often have a cost in terms of productivity.

Conclusion

If executives are under the impression that their containers are more secure than they actually are in practice and developers are not armed with the additional skill sets to secure the apps they are building, where does that leave us? While reaching a zero-vulnerability environment may not be entirely obtainable, we make significant strides in visibility, tooling and communication to make significant improvements to the current ecosystem.

It’s more important now than ever to know what’s in your software. We are no more secure today than we were this time a year ago. Securing containers for production is not getting easier, yet we are seeing a demand from customers for zero-vulnerability supply chains as a reaction to supply security breaches. As our survey results show, some 70-percent of developers said their customers are demanding that software contain zero vulnerabilities. Yet, only 23-26 percent said they had the skills to slim or harden their containers for production use. This implies skills and a learning gap among developers that may be difficult for organizations to overcome.

A push towards generating SBOMs and scanning containers for vulnerabilities has helped increase awareness, but a larger investment in developer tools is required if we are going to make supply chain security a problem developers can solve. Our team believes in two additional steps to a safer software supply chain – slimming and sharing.

• Sharing – knowing what to focus on as a developer is important. Cut back on the noise, vulnerability scanners can represent a lot of noise, and knowing what to focus on as a developer is important
• Slimming – reduce the number of vulnerabilities to only what you need to focus on to make security easier to handle.

The key takeaway? Ship only what you need to production.

Remove all of the fluff and cruft from your containers for a reduced attack surface. We are now more aware of these security issues than ever before. Across the world, there are competent, relentless, brilliant teams losing sleep thinking about these problems and creating solutions for the software ecosystem. For this reason, we’re confident that there will be a much better analysis to share in our future container analysis.

Download the full report (PDF).

Want to discuss these findings with fellow container enthusiasts?

Join us on Discord at: https://discord.gg/uBttmfyYNB.