Slim.AI: Automating Vulnerability Remediation for a Shift-Left World
These days, if you are producing software as containers, you have someone downstream scanning your container images for vulnerabilities, and that makes your job harder than it was in the past.
The world has plenty of vulnerability scanners, many of them great. What it doesn’t have is a scalable way to manage and remove vulnerabilities. Specifically, developers need a way to automate the process of identifying and removing vulnerabilities in container images during the build process, and DevSecOps professionals need a way to track and communicate what they’re fixing to every player in the ecosystem up and down the software supply chain.
Modern security depends on this, and right now, the process is broken.
Under the current climate of software supply chain concerns, organizations and development teams are struggling to keep up with managing CVEs (Critical Vulnerability Events) and are drowning in CVE noise. Questions they face include, “Which vulnerabilities are exploitable, and which ones aren’t?” and “How do we prioritize what to remediate first so that we’re effectively deploying our limited engineering resources?”
How do teams even make a dent in the problem when the average container has 284 vulnerabilities and companies are running hundreds or thousands of container images in their infrastructure at a time? According to our 2022 Container Report, four new vulnerabilities appear for every one that gets remediated.
The root of the problem is that what makes a container ideal for development makes it vulnerable in production. Tools and packages in the development stage make developers’ lives easier. When you move to production, however, you want to remove anything that doesn’t need to be there, because it inflates the attack surface and introduces potentially vulnerable packages that you simply cannot have in production.
My co-founder Kyle Quest and I use the mantra “ship only what you need to production” to describe what we’re trying to accomplish at Slim.AI. For the companies using our platform, that means creating a system for removing CVE noise automatically. It removes the vulnerabilities associated with software that’s not necessary for an application to run. By reducing this noise, we help teams prioritize vulnerabilities that do matter.
Helping Developers Reduce CVE Noise
This process of making containers ready for production is a profoundly difficult task for most developers. Vulnerability scanners are valuable and necessary tools to help secure your software, but having a strong risk reduction posture comes at a cost — namely, developer productivity.
In fact, according to our recent survey, when developers were asked “Which tasks are adding more work to your job?” — finding and removing vulnerabilities from containers was the number one task adding to their workload.
Organizations today are working to improve the signal-to-noise ratio on vulnerability scanning and to prioritize security fixes as efficiently as possible. At Slim.AI, we are working on ways to automate the reduction, management and sharing of vulnerabilities provided by scanners while also removing code that is not needed in production.
Current Solutions Are Necessary, Not Sufficient
Fig. 1: Tools to discover, optimize and manage containers pre-production leave a huge gap for developers to bridge on their own. Slim.AI is solving that problem.
There are several different approaches to addressing the need for vulnerability remediation, all with benefits but also with significant drawbacks.
Manual container optimization approaches like Alpine images start with a developer choosing a minimal base image and then adding all the tools they need for development. For production, they — hopefully — back those tools out of their Dockerfile and run it through a vulnerability scanner so the containers can be released to production.
If you’re an experienced backend developer or DevOps pro, you know both the need for this process and how to do it — without breaking anything. But as your organization begins to expand its adoption of cloud, these teams of specialized “developer experience engineers” or “cloud architects” can become hard to scale, as they’re expensive, rare and in high demand.
Additionally, many organizations have neither control over nor visibility into the base images being used by the vendors or upstream open source projects. And with new base images often come new operating systems that can add overhead to debugging low-level system issues with DNS and kernel libraries.
Vulnerability scanning, on the other hand, is a reactive or point-in-time solution. There is a long and growing list of vulnerability scanners, and many do a great job. The problem is, they don’t solve the root problem, because when you get a report of 200 to 300 vulnerabilities, perhaps even 1,000, in a given container, with hundreds or thousands of unique containers, that’s simply not actionable. It’s too much to reasonably address. Plus, you know that most of those vulnerabilities are irrelevant to the application you’ve built. Again, this approach is unscalable, because the signal-to-noise ratio is poor.
Another aspect of this problem is that vulnerability scanners can provide a false sense of security. There are plenty of aspects of “attack surface” that have nothing to do with CVEs. A “zero-vulnerability” image can still be exploited in certain conditions using things like shells, package managers, or tools like git and curl.
Policy engines are a powerful tool because they don’t allow anything into production that doesn’t meet criteria set by the DevOps or DevSecOps team. Examples might be if code or artifacts aren’t signed or if critical vulnerabilities rise above a certain threshold. Policy engines, like the Cloud Native Computing Foundation–sponsored Kyverno, are a good thing — even a critical thing — but they act like a wall: they block developers from shipping code to production and siphon their time away from coding into managing lengthy break/fix cycles.
It is my belief that successful organizations will find ways to push compliance upstream, putting the necessary tools in the hands of developers to adhere to their policies, in addition to having the requisite downstream checks to prevent security issues in production.
The Slim.AI Difference: A Developer-First Approach
Slim.AI recognizes the shortcomings of these current container security approaches and has built a platform for developers that automates the process of shipping slim, secure containers. The benefit of the Slim.AI approach is that it gives developers the freedom to use any image they want for development. With our tools, developers can use whichever base images and tools they prefer, then run their container through our automated process to generate a new, production-ready container, guaranteed to adhere to container best practices.
Additionally, the Slim.AI platform for proactive vulnerability reduction works with third-party images, so you can harden any images you are consuming from open source projects or third parties (or request they run their containers through Slim prior to shipping them to you). For example, we’re working with leading security provider BigID to harden their container images and provide their teams with valuable reports on the security profiles of their containers that they can share with customers.
With the Slim.AI platform, there’s no new code to write nor a new ecosystem to learn. You simply run our software in our cloud or in your existing infrastructure and automatically add a new layer of container security and visibility to your organization. Your security teams get the peace of mind that containers are adhering to security best practices (and automated reports to prove it), and developers can spend more time building awesome features and less time chasing down patches to random open source libraries.
Fig. 2: Slim.AI is actively removing vulnerabilities as part of an automated process that integrates with the tools and processes developers are already using.
Conclusion
At Slim.AI, we believe that successful organizations will be those that take the long view on software supply chain security with their containers, by automating vulnerability triage and remediation, reducing software attack surface and securing images.
We’re adopting the position that automation can empower developers. Supply chain security is such a critical issue that we need a solution that scales, and automating the security process in development is the only way to solve it.
By implementing the Slim.AI platform into your development workflow, your security teams benefit by knowing developers are taking every precaution to secure their containers in an automated way. And developers benefit from the tools, insights and automated processes to harden their containers, eliminating guesswork and “best effort” practices.
We’re bringing on new design partners every day to build the best platform we can, and we hope you will join us in doing so.
