AI
Why Rubrik’s Vulnerability Count Became Unmanageable
Rubrik runs 1,200 unique containers in production. With 1,000 engineers committing code daily across dozens of branches, vulnerability scanners were generating tickets faster than anyone could close them. The security team’s answer: stop engineers from introducing vulnerable packages at the source.
The design target was a system that sat inside engineering’s existing workflow, not a parallel process imposed by security. Tickets were the problem. Code was the interface. The moment a developer checked in a build, the system had to be already there.
Building a Pipeline That Engineers Actually Use
Before the pipeline, upgrading an old Ubuntu base image required full manual QA: upload the image, load the software, test everything by hand. That took months. Now Rubrik injects one of its pre-hardened base images directly into a team’s Jenkins server, downloads their software automatically, auto-patches every vulnerable package, and runs the result through the team’s own QA suite. Engineers touch nothing.
“we can build containers within minutes,” — Brian Chong
The system handles roughly 30,000 image builds per week across the company. A package upgrade that passes QA ships silently. Only a genuine breakage, which Chong says happens rarely, generates a ticket.
Business Impact: Customer Complaints and Ticket Counts
Rubrik’s product includes a client component that installs at customer sites. Those customers run their own scanners. When Rubrik shipped software with unpatched CVEs, customers filed complaints. Automated patching closed that gap: patches now ship fast enough that customer-facing vulnerability reports dropped sharply. Internal ticket volume fell by more than 95%.
A secondary benefit arrived with AI-assisted coding. Engineers increasingly let AI suggest packages without checking versions. The pipeline catches those too, enforcing approved versions at build time regardless of what the AI recommended, before anything reaches production.
Getting Buy-In Across 1,000 Engineers
Chong’s team showed engineering leadership their own open vulnerability numbers before pitching the system. Those numbers were bad: thousands of open tickets, images running months behind on patches. That context made the sell simple. Committing to a 50-90% reduction in specific metrics gave leaders a concrete reason to free up engineering time.
Retrospective: bring engineering into the design phase months earlier, and set metric targets at the start. Chong’s summary: communicate early and often, and use metrics that matter to the audience you’re addressing.
Notable Quotes
And it was only a dramatic decrease of over 90 plus 95 plus%. Brian Chong · ▶ 7:43
we can build containers within minutes, Brian Chong · ▶ 8:21
save thousands of hours from their time. Brian Chong · ▶ 8:52
Key Takeaways
- Rubrik automated patching for 1,200 containers, cutting vulnerability tickets by 95% and build time from months to minutes.
- Security teams that adopt engineering’s own build and QA tools get adoption; those that impose their own tools do not.
- Show engineering leaders their open vulnerability counts before pitching automation, then commit to explicit metric targets.