 Have you ever felt infinitely small in front of something vast and complicated, like the midnight sky? Ever since I was a little girl, I've been fascinated by complexity, especially how complexity emerges from simple, humble beginnings, from elemental particles to galaxies. When as a researcher at MIT focusing on emerging technologies, I was fascinated, captivated by research like Steppen Wolfram and John Canemay's Game of Life, tying the computer systems with biological worlds, with life itself. After all, what could be more complex than biological systems, right? What may be Kubernetes? If Kubernetes is the organism, then containers are the cells. And maybe that takes the analogy a little too far, but we know that containers are being used all the time everywhere in nearly every software development project across all verticals. See, I'm an ad-developed engineer. I'm a data scientist working for a startup called slim.ai. At slim, we are obsessed with container optimization and security. And we scan hundreds of thousands of containers regularly. This year alone, we have scanned more than 900,000 containers. And as a data scientist working with this data, I would like to provide you a window into the world of containers as developers experience it often for the first time. I'd like us to expand our senses about this world. I would like us to look at some perspective-shifting data about this world. Take, for example, the 60%. That's the percentage of top publicly available containers that have more vulnerabilities in them today than they did a year ago, 60%. And this is after a year of intense focus on software supply chain security in the aftermath of multiple security incidents. The rest of the containers haven't improved that much, and we'll be talking about that in a moment. But before, let's couple this inside with this other statistic here. This one is from a global randomized study that we designed asking questions to developers and DevOps engineers. 70% said their customers are asking, demanding their containers to have zero vulnerabilities. On top of that, 88% of the developers said it is getting more challenging to remove the vulnerabilities from their containers. The number one contributing factor being the complexity. The numerous components with dependencies in them. So as you can see, there's a story that's unfolding before our eyes. Containers are becoming more vulnerable. Customers are demanding perfection more than ever, and developers are feeling the pressure. And although developers are in the heat of the battle, there is an undeniable rising tide when it comes to developer interest in Kubernetes and containers. And container adoption across companies large and small. In fact, developers are beginning to look at a technology like Docker as native to their workflows like a tool like Git or an IDE. Going to Stack Overflows 2022 developer survey, Docker is the number one technology developers love and want to learn. And we can see this in the usage stats as well. The old-time pools on Docker Hub has tripled in just a year. But while there are lots of tutorials out there to learn about shipping and building containers, there is precious little understanding around what's in them. Like cells, containers are being seen as these atomic units, building blocks of living organisms where requests go in, data comes out. It's just that simple. But then something like log four shall happen. And before we know it, 2022 becomes the year of software supply chain security. And we are all more invested in understanding not only the principal components of our software systems, but also their second-order effects, their dependency trees. So how did this renewed sense of awareness change the container landscape? My research team at Slim.ai have been deconstructing, analyzing, observing containers in an effort to understand what makes these containers developer-friendly and production-ready. Last year, around this time, we put a magnifying lens onto the top publicly-available containers on Docker Hub and published a report with analytical insights. We had some shocking findings in that report, and I'm not going to list them all. But I'm going to tell you this. As container enthusiasts, we were expecting to see some outliers. Certain containers, certain container categories having a large number of vulnerabilities, packages, libraries, licenses, spatial permissions, what have you. But even the averages were surprisingly high. One thing to note about these containers is that, yes, there are 10 million images on Docker Hub with more than 318 billion pulls, but this top 165 containers account for more than 30% of all use. So it's a very spatial cluster. So today, we published a sequel to that report, this time focusing on the delta between last year and this year. So let's go ahead and look into the data and some of our learnings' findings. The first finding is that we have more high and critical vulnerabilities than ever across all categories. Now, I already mentioned that 60% of the containers have more vulnerabilities today than they did a year ago. And yes, we did remediate certain vulnerabilities, certain incidents, but we are detecting new incidents four times faster than our remediation rate. And the new ones, the new incidents that we detect, are mostly high and critical vulnerabilities. The high severity vulnerabilities have increased by 50% this year. So today, the average container has almost 300 vulnerabilities, 30% of which is high or critical, up from 20% last year. And we thought 20% was too high. Let's move on to the next finding. Component complexity has also increased significantly. The average container today has 400 packages. And if you think about it, this number is supposed to be the tip of the iceberg. Every package might have thousands, sometimes hundreds of thousands of dependencies, as shown by multiple studies. But it turns out that even the tip of the iceberg is an iceberg. And it is not just the packages. The licenses have increased by 2.5x. The containers have more layers. The larger the skinning of these containers takes longer times. And even the metadata, their S-bombs have increased by 40%. Now, don't get me wrong. These tools, these packages are necessary for experimentation. It helps developers to debug and test and build and have fun. But they also represent attack surface and implied in need to have an automated process to remove this so that that attack surface never makes it to production. Is data, but what's the impact on our people? How does this more complex and more vulnerable landscape impact our DevOps engineers and developers? I mentioned that 88% said they find it more challenging to remove the vulnerabilities. Only one in four developers said they fully understand how container slimming and hardening works. And interestingly, that seems to be a mismatch, a disconnect between executives and the front line engineers. 49% of the executives said they are slimming and hardening containers in their companies. But the people who do the actual work are reporting significantly lower numbers. Governments and companies may be demanding a world with zero vulnerabilities, but that land feels out of reach, given our tools and techniques. The sobering bottom line is that we are no more secure today than we were back in 2021. The silver lining, however, is that we have woken up and we are more aware of these challenges than ever before. For us at slim, we believe you should know what's inside your container and you should ship only what's needed to production. We are seeking to solve this challenge for all of the world's containers through automation and intelligent optimization. And look, I do not think complexity is the enemy here, ignorances. There are times where we need to take a step back and enjoy the poetic beauty of the complex systems around us. There are other times where we need to step in fearlessly and deconstruct and redesign. We have to resolve the decision intelligence, the willpower to solve these issues. And most of the decision makers are in front of me in this room. My friends say I'm an incurable optimist, but that's not why I think the future is bright. I know there are relentless, brilliant, competent teams around the world who are losing their sleep thinking about these problems. So many teams that I couldn't even fit the names that we leverage for this project alone in my thank you card here. And as humans, when we gather, like we did at this fabulous location, when we put our hearts and minds together, we can make even ridiculously tough beats look easy. And that's why I know when I'm on this stage next time, I will be bringing better news. Thank you.