The cybersecurity industry has no shortage of ways to tell a developer that something is wrong. It can scan a container, grade its risk, color a dashboard red and open a ticket before lunch. The developer still has to decide whether the fix will break production. Ian Riopel has spent much of his career staring at that gap between a warning and a repair. Root, the Boston-area company he co-founded and led, was his attempt to close it.
His route to that problem did not begin in a startup accelerator. Riopel trained at the U.S. Army Intelligence School and served in the Army Reserve as a counterintelligence agent. He then moved through the commercial security world, working in federal sales at Enterasys, vulnerability management at Rapid7, cloud security at CloudLock and specialist roles at Cisco. It is a career organized around threat information, but also around the less glamorous question that follows: what is someone supposed to do with it?
There was an education in institutions running alongside the education in software. He learned the tempo of government buying, where trust arrives slowly and documentation is part of the product. He learned startup selling at CloudLock, then watched the company become part of Cisco. At Cisco he earned internal recognition for sales and work protecting public-sector customers. He later completed MIT Sloan's Advanced Certificate for Executives, studying there from 2021 to 2023. By then, he could see the same security problem from several seats: the operator trying to contain risk, the seller translating it, the executive funding it and the developer receiving the ticket.
By the time Riopel joined Slim.AI in 2022, software production had become a crowded relay race. Applications arrived assembled from operating-system packages, libraries and open-source dependencies. A single container could carry code maintained by people scattered across companies, countries and time zones. Scanners could enumerate the weak points. Coordinating a safe repair was another matter.
“What if containers could proactively fix themselves as part of the standard software development lifecycle?”Ian Riopel on the question behind Root's automated remediation
A smaller container reveals a bigger job
Slim.AI originally helped developers minimize and optimize containers. Smaller images offered practical advantages: fewer unnecessary components, less attack surface and a clearer picture of what software actually contained. Yet the team found itself pressed against a more consequential problem. Knowing which components were present made it easier to see vulnerabilities, but a cleaner inventory did not make those vulnerabilities disappear.
The company began working on a shared space where software producers and consumers could coordinate fixes. At KubeCon + CloudNativeCon North America, Riopel demonstrated that workflow in a conversation about how a once-simple exchange - one party ships software, another deploys it - had turned into a long negotiation about trust, evidence and responsibility.
The product thesis kept moving from coordination toward completion. Instead of merely showing two parties the same list, the software could act on the container image itself. It could identify a vulnerable package, select or create a compatible repair, preserve the surrounding dependencies and produce a new image without asking the customer to rebuild everything from scratch.
Riopel was one member of a founding group with complementary angles on the same bottleneck. CTO John Amaral brought a long record of building cloud-security companies. Benji Kalman and Mickey Gordon added open-source and security experience. The company also maintained Slim Toolkit, formerly DockerSlim, which kept the team close to the messy variety of real container images. Root's argument did not emerge from a pristine laboratory example. It emerged from watching developers assemble production systems from components that did not share a release calendar, a support contract or even a common definition of “fixed.”
That shift changed the identity of the business. Slim.AI became Root in 2024, with Riopel as CEO. The new name carried a tidy pun, but the strategic message was serious: move from trimming the container to addressing the root of the software risk. The job was no longer to help teams keep a better list. It was to shorten the distance between exposure and repair.
The ticket is a tax
Riopel's public argument is grounded in the economics of attention. Every vulnerability that lands with an application team competes with customer work, reliability work and the other chores that keep software alive. The familiar “shift left” doctrine pushed security earlier into development. Riopel came to believe that it had also pushed an unbounded maintenance obligation onto the wrong people.
Root called its alternative “shift out.” Open-source repair should happen as an automated service around the development workflow, with developers interacting as passively as possible. There is a useful provocation in the phrase. If a tool detects a defect and then assigns the repair to its user, the tool has automated the cheapest part of the job.
Automation at this layer cannot be jaunty. A patch that removes a listed vulnerability but changes runtime behavior has merely swapped a security problem for an outage. Riopel has described Root's approach as deliberately conservative: track dependency graphs, choose compatibility-aware patches, test remediated images against available open-source test suites and make rollback straightforward. The product's credibility sits inside that qualification. Fast is useful only after safe.
This is where his rhetoric becomes noticeably less futuristic. He is willing to talk about agentic AI and self-healing infrastructure, but he returns quickly to compatibility, audit trails and failure rates. The interesting personality of the product sits in that combination: an ambitious destination approached through fussy operational details. Root reported that fewer than one in a thousand of its automated remediations failed across thousands of attempts. The number was a company claim, but choosing to foreground it revealed the standard Riopel wanted customers to use. Judge the automation by what survives contact with production.
The other constraint is transparency. Regulated companies need more than a green badge. They need to show what changed, why it changed and whether the result meets policy. Root produced software bills of materials and security artifacts alongside the patch. This reflects Riopel's years selling into federal and enterprise environments, where a technically correct answer can still fail if nobody can defend it in an audit.
Watch Riopel demonstrate rapid vulnerability remediation at KubeCon + CloudNativeCon North America▶A military habit, translated
Riopel does not overplay his counterintelligence background, but it offers a useful lens on his operating style. Intelligence is not a trophy case of facts. It is material collected so a decision can be made under pressure. Cybersecurity's modern problem is that collection became abundant while action remained scarce. Vulnerability databases grew. Scanners multiplied. The cost of applying and validating a change remained stubbornly human.
His career also moved repeatedly between large organizations and smaller ones. CloudLock was acquired by Cisco in 2016, and Riopel spent six years across the two companies. At FXP he worked as an entrepreneur in residence while taking on partnership and customer leadership at Slim.AI. That mixture of field selling, customer operations and company building matters. Root's argument was technical, but its target was organizational friction.
“You can't optimize your way out of a broken paradigm.”Ian Riopel introducing Root's “shift out” thesis
Outside work, his public profile records another long commitment: organizing events for the Melrose Veteran Memorial Fund since 2014. The detail is modest and revealing. His professional story is filled with systems designed for continuity, whether the institution is a development team, a software supply chain or a local community of veterans.
The acquisition, and the unfinished idea
On June 30, 2026, Aikido Security announced that it had acquired Root. The fit was legible. Aikido had assembled a broad application-security platform; Root had concentrated on the difficult last mile of open-source vulnerability remediation. The announcement welcomed Riopel, fellow co-founders John Amaral, Benji Kalman and Mickey Gordon, and the rest of the Root team.
A few weeks earlier, members of the Root team had been on the floor at Gartner's Application Innovation & Business Solutions Summit in Las Vegas, inviting visitors to watch containers move toward zero known vulnerabilities. That public rhythm - booth conversations, technical demonstrations, long interviews and terse LinkedIn arguments - had been part of Riopel's method for years. He did not present automated remediation as magic. He presented it as a sequence a buyer could watch, question and measure. Joining Aikido gave that sequence a wider platform and placed Root's patching machinery beside tools that find risks elsewhere in the application stack.
Acquisition announcements tend to make a founder's path look straighter than it was. Root emerged through a series of adjacent discoveries: smaller containers exposed the need for better inventories; shared inventories exposed the coordination burden; coordination exposed the inadequacy of handing out tickets. Each step pulled the company closer to the repair itself.
Riopel's stated aspiration reaches beyond eliminating today's CVEs. He has talked about systems that anticipate where the next vulnerabilities may come from, while letting customers pull safe open-source software without surrendering their architecture to a vendor. AI sits on both sides of that future. It can accelerate the creation of attacks and the production of patches. Riopel's insistence is that production software leaves no room for a machine's confident fiction. A fix must be testable, traceable and reversible.
The practical lesson from Root is pleasantly unfashionable. A category can spend years improving its warnings while customers quietly drown in the work those warnings create. The next product may begin by treating the notification as an unfinished transaction. Riopel followed that logic from a container-slimming tool to a security company built around repair. The ticket had been forwarded often enough. It was time for the software to do some work.