Patching the Unpatchable

Send us a text

PodMatch
PodMatch Automatically Matches Ideal Podcast Guests and Hosts For Interviews
Digital Disruption with Geoff Nielson
Discover how technology is reshaping our lives and livelihoods.

Listen on: Apple Podcasts   Spotify

Root.io


Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.

Support the show

Follow the Podcast on Social Media!

Tesla Referral Code: https://ts.la/joseph675128

YouTube: https://www.youtube.com/@securityunfilteredpodcast

Instagram: https://www.instagram.com/secunfpodcast/
Twitter: https://twitter.com/SecUnfPodcast

Episode Transcript

Speaker 1 (00:01):
How's it going, john?
It's great to finally get youon the podcast.
I know we've been trying to getthis thing going for a while
now.
It's definitely been in themaking for a while, and I very
inconveniently had my second kidin the middle of it, so that
hasn't helped anything, that'sfor sure.

Speaker 2 (00:17):
Thanks a lot, joe.
I appreciate that and I'mreally excited to be here.
Timing these kid things outalways kind of it's magic.
You know, you never really knowwhen they're going to come, but
it's important when they do, soI'm glad we could push it
around.
I'm certainly not as importantas that moment for you, so
congratulations.

Speaker 1 (00:35):
Yeah, thanks, it's.
You know, it's always like, atleast with my first, my first
born, and with my second one,now you know, they tell you one
date and then it's like threeweeks earlier, no matter what.
So this time around with myfirstborn, I wasn't ready at all
.
I didn't have the crib set up,I didn't have anything.
And so with this one I made ita point like okay, this time

(00:59):
around, like two months ahead,I'm painting the room, I'm
getting the crypto andeverything else you know.
So I refuse to be unpreparedfor this one.

Speaker 2 (01:09):
Anyway, early is super early for the first one
for that exact reason.
You know you got to.
You think you got a lot of time.
You don't really know how thepressure is going to be.
But yeah, I have three kids andthey came at all different
times, but the first one wasactually late for me, which gave
me a little more leeway.
I actually did a good job ofgetting the room ready in
advance.
And the second one doesn'tsneak up on you as much.
You've been getting any sleep.
You look awful awake forsomeone who's got new kids

(01:33):
running around the house.

Speaker 1 (01:34):
Yeah, yeah, so I've been sleeping pretty good.
It's the wife that does thenight shift, and so she's going
from nap to nap and you know,like when I, when I, when I do a
lunch with someone or something, it's always like all right,
let me bring you food, you know,because I know you're, you're
the one taking the sacrifice.

Speaker 2 (01:53):
She's doing an amazing service.
That's, that's hard work.
So you got a good, you got agood partner there.

Speaker 1 (01:59):
Luckily she's a teacher too, right.
So you know she takes hermaternity leave, you know, right
when the kid's born, obviously,or a little bit before, and she
gets it all the way through therest of the school year and
then she goes into summer break,you know.
So it's like, man, you'regetting like six months, you
know six months off from work,not like you're not doing

(02:19):
anything, but still it's prettyawesome she's definitely got a
job, but but still, it's prettyawesome.

Speaker 2 (02:24):
She's definitely got a job, but on her hands raising
the kids.
But that's really lucky, right?
That's a luxury.
You get to spend some qualitytime with your newborn and I
can't think of anything betterto do.

Speaker 1 (02:34):
Really, if you put it in the grand scheme of things,
yeah, yeah, you know, I startedmy career, obviously, like
probably everyone you know,going into the office, like like
everyone else, right, everysingle day, five days a week,
going into the office.
And now that I work from homeand I've worked from home since,
you know, 2020, like everyoneelse, basically I just couldn't

(02:55):
imagine going back into theoffice and how much I would miss
, you know, with with my kidsand everything I mean.
I'm there.
I'm there when my kids wake up.
I'm there when they come homefrom school, I'm there in
between you know like so goodit's so good.
Yeah, what a great time to be onthat.

Speaker 2 (03:13):
Oh, there's no number Like it's the most precious
time ever and, uh, the fact thatyou get to do that and do your
job and and do your podcast andall these things is like a
luxury, awesome thing.
I had my kids a little whileago and it was go to the office
every day and I was lucky enoughto have a wife who really
managed doing a great job withthem and keeping the family on

(03:35):
track with all the things, and Iwish it was different.
I missed some good time withthem and spent a lot of time
with them, coached all thesports and things like that.
So it paid off in the end.
But yeah, it's, it's.
It's cool to hear that you'reenjoying this time in your life.

Speaker 1 (03:50):
Yeah, yeah, I always, I always really do my best to
like enjoy the present and planfor the future, you know, so,
like that, that's kind of how Iapproach.
You know just about everythingright.

Speaker 2 (04:03):
It's amazing, like that's kind of how I approach
you know just about everythingright.
Amazing Zen, perfect tip forthe audience.
Yeah, that's how we all shouldlive.

Speaker 1 (04:08):
Very cool.
Yeah, yeah, awesome.
Yeah, john, you know I startedthis podcast.
Give you a short background,right?
I started this podcast becauseI wanted to talk to experts and
hear how they got into the field.
To experts and hear how theygot into the field, because I
remember when I was trying toget into cybersecurity, I had

(04:28):
the worst time trying to getinto it and no one would give me
guidance.
You know, no one really took thetime of day to to like, tell me
, like, hey, these are the topfive things that you need to
really work on.
You know, like, even when Iwould get rejected by employers,
you know, the only feedback I'mgetting is oh, you don't have
Splunk experience.
Well, thank you, because thatcosts 200k a year for me to run.

(04:50):
You know, in my home network ormy company network.
Yeah, I'm not going to be ableto get that, you know.
So I always start everyone offwith telling how they got
started, because everyone'sbackground is unique, everyone's
journey is unique, and I thinkthat it's valuable.
It definitely would have beenvaluable for me back then to

(05:10):
hear someone else's story that Imay be related to.
Maybe I said, oh, that soundslike me, that sounds like what
I'm going through and just giventhat little you know,
motivation to hear hey, if Johncan go through it and be
successful, maybe I can gothrough it too.

Speaker 2 (05:30):
That's, yeah, it's.
My journey is kind ofinteresting.
I think you know, buildcybersecurity companies that's
that's like what I've been doingfor the last 20 years.
So we start, and that's a lotabout imagining a better future
for you know, very importantcybersecurity use cases Like the
one I'm currently working on ishow do I help organizations
remediate vulnerabilities fasterin containerized workloads like
faster, better, more efficient,less work and energy expense in

(05:54):
the company.
That's what I'm currentlyworking on.
Now.
The journey to you know, fromsort of I've been around a while
.
I've been in the industry, like25 plus years, right.
The journey for me is theinteresting one in that I've
always been sort of a builder.
I was working in startupcompanies and my own company
since like 24 years old, right.
So like very early on I hadthis entrepreneurial bent and I

(06:15):
always kind of took my own pathto thing, and I think there's a
parallel we can help yourlisteners take along with them,
especially in this day and age.
So it's a very simple.
I'll super summarize this.
One of the early companies Ifounded was an internet service
provider.
Literally.
I had an ISP that I foundedthat had dial-up modems.

(06:37):
That's how long I've beenaround, right.
Dial-up modems, there was nocable internet access.
There was no cable internetaccess.
There was no big verizonnetwork doing this stuff.
It was mom and pops with a t1doing like internet access for
the neighborhood and the peoplearound you, right.
And so we had to deal with likeearly stage network security
stuff that like there was justnot a lot of information about

(07:00):
doing.
So we ginned up firewalls onservers and did all kinds of
things, and then checkpoint cameout with their firewalls on
servers and did all kinds ofthings, and then Checkpoint came
out with their firewalls.
So I kind of got pulled intobeing, like I'll call it, a
specialty.
Like myself and my founderswere networking guys I was
building, also building othernetworking products at a
different company that I hadfounded.
But basically I had to dosecurity well to do my day job

(07:21):
well, which was build a productthat was network service
provision.
So I had to do security well todo my day job well, which was
build a product that was networkservice provision.
So I had to learn a lot aboutnetwork security and to learn a
lot about securing theinfrastructure that we were
building.
So pretty straightforward stuff.
Now, fast forward.
That was a networking companyand slowly but surely my career
kind of transformed into beingfrom I'll call it hardware

(07:43):
networking and hardware building, hardware systems to building
software systems.
And along that journey I got.
We built a software company.
At that time we got a malwareattack that kind of did damage
and we were building softwarefor other purposes, with
software towards networking.
But it was like the first timeI'd encountered a meaningful

(08:04):
attack on me that the root of itwas software security.
I couldn't get through thatmalware attack and so I really
took it on as like a petinterest.
I said you know what?
That's never happened to meagain.
This is my new passion, and Iliterally at that moment flipped
the corner and said I'm onlygoing to work on security
problems right now and I need tostop this.

(08:26):
This is terrible.
It revealed itself to me as awow, this is a really dangerous
thing for anyone, especiallyorganizations that can be
subject to this.
You know the Internet was athing, now right, and it was
easy to mess up, and I thought,wow, I have some purpose in this
, I really feel like I can makea difference.

(08:47):
And since then I really notstarted thinking about anything
other than I not stoppedthinking about software security
, web security, web applicationsecurity, saas security, you
name it and it sort of led medown a really fun, interesting
and great career path where I'vebuilt now several big
businesses and companies, bothstarting them from small and

(09:09):
growing them to raising venturecapital and building companies
like I'm doing now, to running ahalf a billion dollar
cybersecurity business in Cisco.
And I would say the takeawayfor that, like let's bring this
down to ground right, like sothat sounds like a lot of stuff
happening fast.
It wasn't.
I really invested in learning.
I studied everything I could.

(09:29):
By that time, the internet hadvolumes of information.
I read a lot of books like howto hack.
I wanted to think like a hacker, I wanted to act like a hacker.
So I took I'm an engineer right, I'm a curious engineer with
good programming skills, withgood hardware engineering skills
.
I know how networks work.

(09:49):
I know how software works.
I have background inengineering degrees and stuff
like that.
So I really made it my petpassion and then turned it into
my business passion and businessfocus.
And it started with the petpassion which was hey, can I
learn how malware works?
Can I investigate that and tryit myself?
And I'm telling you, if I hadAI on my desktop to work with

(10:11):
back then, it could haveaccelerated my learning a ton.
So I would say, like, for anyonewho wants to get into it, be
curious, find something thatyou're passionate about, put in
the work and effort to learn it,learn it really well and make
it so that you can demonstratethat learning.
And I think in today's worldthat's you know, like, make a

(10:36):
GitHub repo of your examples.
Like build something thatactually demonstrates your
knowledge or demonstrates theproblem, or, you know and again,
you're a guy who does blogs tohelp people learn like put it
out there, put it on yourLinkedIn, put it, you know.
Like learn in the open andreally get people to recognize
that your passion's there andthat you're putting in the
energy.
And I'll tell you, incybersecurity you got someone
who proves they know something,shows they want to work hard,

(10:59):
can demonstrate their value.
There's like a million jobs incybersecurity that are unfilled
around the world.
I mean like I think you canactually build it yourself by
rolling up your sleeves.
And that's pretty much myjourney.
It's taken me a long way.
It's really, really fun.

Speaker 1 (11:15):
Yeah, yeah, that's.
It's a fascinating journeyBecause I feel like everyone
knows what to do right or how todo it to be successful, but not
a lot of people go down thatroad, right, right, right, you
know you said you kind ofmentioned that you're like a

(11:38):
lifelong learner.
You know, you really dove intothis thing, you know head first
and I really relate to that forsure.
Like security isn't justsomething that I do nine to five
.
Right, in case people didn'trealize, you know, like the
podcast hints it a little bit.
But you know I'm alsochallenging myself significantly
in other ways.

(11:59):
Right, so I'm getting my PhDand securing satellites with
zero trust to prepare them forquantum encryption?
Right, like that.
All three, all two areas ofthat category, right, zero trust
, I know, yeah yeah, yeah,that's the only thing I'm
bringing to the table.
I know zero trust, butsatellites never touched them,

(12:19):
never looked at them, neverresearched them.
Quantum I didn't even want tolook at it.
I didn't looked at them, neverresearched them.
Quantum I didn't even want tolook at it.
I didn't.
I mean, even to this day.
Like you know, I finished, Ithink, like my 50 page 50-ish
page section of my dissertationon quantum.
You know, just giving a basefoundation, doing my best to not
sound dumb while talking aboutquantum.

(12:41):
Right, I just finished it, soI'm not even trying to think
about it now.

Speaker 2 (12:45):
For the rest of the year, but doing those things—
Congratulations, by the way,that's a huge part of the lift
on getting to that point in youreducation, right?

Speaker 1 (12:54):
The dissertation and— .
Yeah, my research plan actuallyjust got approved, I think like
maybe last week, and I was tornwith emotion because I was like
man, I kind of hope that theywould have like denied me and
said, no, this will never work,you know, just leave the program
.
But unfortunately they, theyapproved it and so now, you know

(13:17):
, I told my chair, I was like itlooks like I actually have to
do this stuff now.

Speaker 2 (13:20):
Congratulations.
I hope that I'll be calling youDr South here next time we do a
podcast together.
That'd be super fun.

Speaker 1 (13:27):
I'm sure we'll do one more before I actually get that
accolade.
Okay, cool, quickly there.
And I think of a few friends ofmine that didn't put that time

(13:48):
in and now they're unemployed,and now they're in a situation
where they're looking like, youknow, the other million, two
million candidates out there forthese jobs, when companies
really want someone that ispassionate about it, you know,
and it's doing the little thingsthat show that interest, that
show that knowledge and thatpassion outside of your nine to
five.
Like you said, a GitHub projectspeaks volumes.

(14:11):
It speaks so many more volumesthan an interview ever will.

Speaker 2 (14:16):
And it's also an open book on your work that people
can look at and collaborate withyou on, and even see into your
soul, so to speak, on how youthink and what you do, and
that's like the best livingexample of your work, right?
I'll mention one other thing.
I was lucky to get mentorsearly in my career, like people

(14:37):
that invested, you know likebelieved in me and invested time
in me to help me, whether itwas a person at my company that
I had been working for, like mypartners in building companies,
or we got acquired several times.
I've had five of my companiesacquired, so, like one of the
early ones, I was still a youngguy.
I was like you're not even 30yet and we got acquired.
And I saw it happening in thisorganization a lot, where

(15:00):
younger people with ambitionwould easily go under the
attention of someone withexperience and they would take
them under their wing.
And I had the luck of havingthat several times through my
career, through theseacquisitions, or even through
customers and partners, me.

(15:36):
I've had this happen lots oftimes, several times, where
somebody will LinkedIn me aperson that's just out of
college and ask me questionsabout my career, what I'm doing,
or say hey, john, I'd love totalk to you for 15 minutes.
See, like I want to go downthis path.
Can you talk?
And I do it like I do it andnot as much as I'd love to do it
.
But I, when it comes up, I'mlike you know that's a chance to
give back.
And when it comes up, I'm likeyou know that's a chance to give
back.
And I think if you ask peopleto help you out, they do, and so
I think that's another lessonfor people like who might be
trying to go down the securitycareer.
It's like you know, go to asecurity meetup in your area and

(15:58):
just talk to people, ask themwhat they do, be curious, put
yourself out there and say, hey,I want to get into security.
Can you give me some advice?
And I bet that pays off hugelybecause join the Cloud Native
Compute forum, join OWASP.
It's like 50 bucks, right.

(16:20):
Join OWASP.
Be curious, show up to themeetup in your townago's got a
great like oauth community rightand go be around security
people.
They'll guide you.
Uh, contribute to an oauthproject.
It's out there to do like.
I know, for instance, stevespringett like a close colleague
.
He runs open oauth dependencytrack, it like 1,800 different

(16:45):
organizations that use it like amainstream product.
He's in Chicagoland, that'swhere he lives.
Go to the OWASP meetup, talk toSteve.
Go, show that you knowsomething about Dependency Track
and I bet you one of those1,800 companies would love to
know your name.
Simple stuff like that.

Speaker 1 (17:02):
Yeah, yeah, that is actually really true.
You know, putting yourself outthere is probably 90% of the
battle, right, Like I rememberwhen I was getting started, I
would go to those meetings justto meet people, learn something,
you know, and I would bring astack of resumes with me and I'd
hand them out.
You know, like what do I haveto lose?
Someone going to turn me down?

(17:23):
Exactly right, I went to one ofSomeone going to turn me down.

Speaker 2 (17:25):
Exactly right.
I went to one of those in NewYork City probably six months
ago and half the audience werecollege kids from one of the
universities in New York.
They were all graduating in thecybersecurity program from that
university and they were outthere talking to like grizzled
old professionals like me andall the guys there.

(17:47):
But you know they've linked inwith me now.
They send me notes.
I have like a.
You know, you meet someone andyou get a little like investment
in, in, in their, in their nameand what they do, and you're
like, ah, I saw that guy at thething.
Yeah, you remember it.
That little bit of ingenuity itgoes a long way.
It makes the people take notice.

Speaker 1 (18:08):
Yeah, yeah, yeah.
It's interesting alsoleveraging, you know, your
network right, like buildingthat relationship, really really
diving into that.
I take a lot of pride when Imake a recommendation, you know,
to someone for another personthat they've never met.
You know, and I give thatrecommendation and you know the

(18:30):
person I'm giving it to says,you know, automatically it's a
yes because Joe recommended themRight, like that's that really.
I feel like that speaks volumes, you know, to my own reputation
within the industry where it'slike, you know, when I say
something I really do mean it,I'm not just saying it just to
say it Right, and I personallytake a lot of pride in that.

(18:53):
You know I like helping outpeople and I always try to go
out of my way and do it.

Speaker 2 (18:57):
I think that's a paid forward moment right.
Like you, especially if you'reinvested in the industry and the
cause, I don't takecybersecurity as just like a day
job.
I really want to make ameaningful impact on the future
of cyber safety for my money andreally is a battle of good and
evil.
I hate to be too trite withthat, but it is really that

(19:31):
right and so paying it forwardso that you help the next
generation of people coming inthe industry to drive the good
guys forward is good work, sosomething to be proud of.
I think helping people out inthis field is, is, is.

Speaker 1 (19:48):
Yeah, absolutely.
Well, you know, John, talk tome about the problem that you
know you identified.
That led you on the path tocreating root IO and the
solution and the product behindit.

Speaker 2 (20:03):
Yeah, it was a very practical and very practical and
close to my heart problem.
So, as I've mentioned, asidefrom starting startups with
three guys, four guys and anidea, which we did with Root,
I've also run some pretty bigbusinesses inside of Cisco and
inside of CloudLock and othersno-transcript infrastructure and

(20:32):
cloud-native applicationsrunning in AWS and in custom
infrastructure, etc.
We've been buildingcontainerized software for a
long time, since the dawn ofcontainers and Kubernetes.
We've been building on that andbuilding that really like, for
instance, applications that werein my in the product area that
I ran at Cisco had, you know,like millions of users and

(20:52):
hundreds of thousands ofcompanies using it.
Cisco Umbrella was one of theproducts and it was a really
popular product.
Security is paramount there.
Right, I take seriously theproducts I build for the value
they create, but I also takeseriously the fact that that's a
security product.
It needs to be really friggingsecure, right Like super secure.
So it's always been near anddear to my heart to do a great

(21:14):
job with AppSec for theseapplications we build, and one
of the challenges I had at Ciscoand at other companies we've
been building cloud-nativeworkloads is how hard it is for
organizations to get a handle onthe software supply chain,
security and the vulnerabilitymanagement for these
applications.
So specifically, what Root doesis it helps organizations

(21:35):
remediate vulnerabilities andlower the attack surface on
containerized workloads.
So you know your containerimage is the embodiment of your
software supply chain, like itis the running implementation of
the software you build and thesoftware you use.
So if you look at any containerimage, it's like 95% open
source software Linux, python,python libraries, etc.

(21:58):
Like the world of open sourceprovides and it provides all
that free software free as inspeech, not beer, it's not free.
You know you still have to payto use it effectively, like it
costs you to secure it but itdidn't cost you a license fee
and ensure you didn't freely use.
I always say that software ismore like free puppies you get

(22:20):
them and then you got to do alot of work to make the puppies
successful, so to speak.
But anyway, that challenge ofputting I'll call it
vulnerability-free and low-riskprofile containers into
production was really hard forthese companies to do and it
puzzled me.
Like in 1,000 engineers we had,like you know, a massive
organization and we were goingthrough things like FedRAMP

(22:44):
compliance and we were doing alot of like really strict
security management on thesethings.
And I'm like why, with all theresources we have at Cisco and
all the know-how and the greatengineers we have, why is this
so hard to do?
We get our vulnerabilityscanners scanning these
containers, we get these longlists of vulnerabilities and
then we go okay, let's try toget our handle on how to fix
these.
None of the tools couldremediate.

(23:04):
So, first of all, the biggestproblem, like problem number one
a lot of scanners tell youabout vulnerabilities and none
of them do anything to fix it.
Basically and I think that'slargely still the case today and
then changing out the operatingsystem or moving to a new
version of the operating system.
Operating systems are wheremost of the vulnerabilities come
from.
By the way, it's probably somein the know-know, but it's like

(23:25):
the base image typically haslike 80% of the vulnerabilities
in it.
It's getting to be the pointwhere libraries also have lots
and lots of vulnerabilities.
But you can get a lot of banksfor the buck if you just fix up
the Debian layer in thecontainer, or the Debian layer
plus the App Foundation layer.
I saw our engineers strugglemightily to get any progress in
that, like why can't you changethe OS.

(23:47):
Well, if we do that, thisdependency will break or it's
going to take us.
You know we can't build thenext three features that you
want to deliver in six months toget our customers happy if I do
that job.
So which one do you want me todo?
Do you want me to fix the, makethe software secure, or do you
want me to ship the features?
There's always this.
And then, of course, you gotSEC engineers like you know,

(24:07):
people that I, like you know,like I revere, like saying you
got to fix this stuff, man, I'mnot going to be able to do the
Fed ramp.
All these pressures fromcompliance and security
governance, which is good, meansthat you're building secure
stuff was at odds with myroadmap.
And then, when you get theengineers to work on this stuff,
they don't like the work.
They'd rather make features,not fix debt.

Speaker 1 (24:30):
And this is security debt, right.

Speaker 2 (24:31):
So it's like they don't want to work on fixing
these things, and so I searchedaround for a lot of solutions.
There was nothing and westarted this thing like four or
five years ago and what Irealized was, look, if I'm going
to make I kind of went on likefirst principles approach to
this Me and my co-founders werelike what would be the most
beautiful experience that youcould ever have.

(24:52):
That would make, that would becost effective.
It would solve the solutionfast.
Meaning like organizationswouldn't have to have some heavy
lift, they could work in thesame workflows that they have
now.
Meaning like they didn't haveto change their build tools or
they didn't have to switchoperating systems, like from
debian to alpine, or they didn'thave to like do a heavy lift
and I didn't put a bunch ofshift left work on the place of

(25:14):
developers and I know they don'tlike to do it right, they don't
want to fix that shit, theywant to build new shit, right.
So I'm like what is the perfectsolution?
What would really move theneedle and make it easy for
organizations like mine to havethis?
Like low effort, high efficacy,security for container images,
get to zero vulnerabilities, butnot create a new pile of work

(25:37):
to get that job done, and soRoot AVR was born.
This product we have, and at thecore of it, it gets to the
heart of the matter very quickly.
What we do is we patchcontainer images.
We patch them so they get tozero vulnerabilities, and we do
it fast.
Fast forward to now.
We came up with that likenirvana solution that I wish I

(26:01):
had when I was working at Cisco.
Took a while to figure out,worked really hard, got a bunch
of smart people together, me andmy co-founders.
I've been passionate for thisthing, but in the end we
achieved that.
What I said, which is can Ibuild a solution that can take
any container image that we haveand convert it into, patch it

(26:21):
into a zero vulnerability imagein five minutes, in less than
five minutes?
And that's what our productdoes it makes container images
go to zero vulnerability.

Speaker 1 (26:30):
So, okay, that's really fascinating to me, right?
Because I'm someone that youknow has been on the security
side, that was over there buyingdevelopers and engineers drinks
and lunch just to get them to.
I know it very well, job that Ireally need them to do

(26:56):
desperately.
Right?
It's like, hey, I can, yes, Ican technically do this, like I
know how to do it and I probablyeven have the access.
But please can you just do thisfor me, like put that feature
on hold for one sprint.
So talk to me about how that'saccomplished, right?
So from what I understand fromcontainer images is essentially,
you know a file, right, andthen you're probably and correct

(27:17):
me if I'm wrong you're probablyupdating the different
components of that file, andthen when the container because
containers are supposed to beshort lived when it, you know,
goes down and then it startsback up, it's using that new
patched image and it kind ofjust rolls through the
environment, like that.

Speaker 2 (27:34):
That's generally right.
I'll dig in a little bit more.
I'll go like a layer below that.
That's like directionally veryright on.
Again, I mentioned that at theheart of our solution is this
ability to patch images and wedo that on an image and it's
your image.
So at its edges, our systems,kind of schematically, it works

(27:55):
at a high level like this youattach us it's a SaaS service,
so it's a patching service youattach us to your registry where
you keep your images andtypically we start by operating
on an organization's base images.
Think of, like Node on Debian orNode on Alpine or PHP on Debian
or Elasticsearch on Debian.
Like you have these kind of appfoundation images where you

(28:18):
have like a Node or Pythonenvironment or you have, like
I'll call it an infrastructureapplications like Redis,
postgres these are the kinds ofimages I'm talking about that
you start with and that cleansup, by the way, when you get
these to be clean, that takes aton of vulnerabilities out of
the environments, because theseimages get propagated over and
over again.
Right, be clean, that takes aton of vulnerabilities out of
the environments Because theseimages get propagated over and
over again.
Right, you build your as acompany.

(28:38):
You build your images on thesefoundational images and you
derive a lot of yourmicroservices from the same base
images if you're doing yourDevOps homework right.
So we focus on those.
I'll call them foundationalimage sets.
They're the 10 or 15 or 20 coreimages you use to build your
SaaS from and you derive from.
As you know, with images youcan in Dockerfiles and other

(29:00):
means you can derive from so youcan do like a multi-stage build
.
The first thing is you do, youbuild your base and then you add
more layers to it as it goes,and that's kind of a pragmatic
way to organize around thesebase images.
So we plug into your registry,so you just put a registry
integration into our system.
You can tie us into your CI CDpipelines.
You can trigger us to runwhenever you build a new,

(29:21):
whenever you want us to create anew base image for you or I'll
call it AVR, your base image,patch, your base image.
These base images often comefrom places like Docker Hub or
it's something somebodygenerated that first Docker file
for.
But a lot of times they comefrom community sources or public
sources and then they getmodified.
But we start with those imagesand then, if you want us to act

(29:42):
on it.
You just tell us to go and acton the image by triggering us
with your CICD pipeline orthrough our UI, and I'm happy to
do a demo later on in thesession to show you exactly what
it looks like.
But once we run, we literallypull the image into our system,
into our SAS.
We open it up, we analyze itscomponents.

(30:03):
I'll say largely we use asimplistic model, but containers
are layered.
This is because they havesomething called a layered file
system, right, and the baseimage lives in whatever layer
was specified, and so on.
You build up some containersI've seen that have as many as
like 100 layers, but on averagethey have like four or five, six
, eight, something like thatSmall number of single digits

(30:24):
number of layers.
So in a simplistic model, mostcontainers that go to production
have like a four macro sets ofstack.
It's like the operating systemor the very base layer.
It would be like DebianBookworm, right.
And then you have another layer.
I'll call it macro layer.
It could be multiple containerlayers.
But the next thing is likeapplication foundations or

(30:47):
applications.
So that's where Redis would fitin to the container stack.
Or Python, the app foundation,the library, python, right, like
Python you might install onyour computer with its basic
packages.
Layer three of that stack wouldbe like the Python libraries I
need for my requirementstxt toactually build the application

(31:08):
that I'm trying to build.
And the fourth is calledfirst-party code.
It's code you write that usesall that stuff just like you do
it on a computer but in acontainer.
We worry about first-party code.
It's code you write that usesall that stuff just like you do
it on a computer but in acontainer.
We worry about third-party code, those first three layers of
that stack, making that secureand patching that.
And, as you mentioned, we applypatches.
So we apply two different kindsof patches.
Our system can automaticallyapply patches to those first

(31:31):
three layers by simply doingupgrades, and we have a patch
planner that knows how to dothat.
In a way that's very lowlikelihood of breaking your
application.
We look at the composition ofthe container and we choose
upgrades that are safe.
That's kind of a cool tech thatwe've created that kind of.

(31:51):
Does some estimation on that?
And then, even if you do aperfect job at that, there's
going to be lots ofvulnerabilities left over,
because many vulnerabilitiesdon't have patches in the
ecosystem.
Debian is notorious for this.
About 70% of all the containersin the world are based on
Debian that run in cloud-nativeenvironments.
There's a large number ofvulnerabilities that are
critical and high that Debiandoes not have patches for,

(32:13):
because they've decided to deferpatching those to future
versions of their operatingsystem and they kind of leave it
up to the community to figureout.
But no one does so.
The other part that we do is wego make patches where they don't
exist in the world and we havea very big library of patches
we've developed you can't findanywhere else.
Really, wow, library of patcheswe've developed you can't find

(32:38):
anywhere else really.
Well, we, uh we've built anagentic ai system that that
augments our research team andit does this extremely
efficiently and extremelyaccurately.
We've invested a lot inautomation and a lot in agent
technology over the last yearand a half to make use of the
cutting edge of ai tech to dothis.
It's a really complicated thing, meaning like making these
patches requires, well, we patchtimes, hundreds of libraries

(33:02):
and it would be like nearlyimpossible for engineers to
understand all of those.
Like we literally have tounderstand all the source code
in those libraries, like it'shundreds of open source
libraries.
To patch, expert knowledgerequired.
We have a great research teamof expert patchers, guys who
know how to do this work reallywell and they like doing it.
The first thing is nobody likesto do this work.
I got guys who like to do thiswork and we've made agents that

(33:25):
love to do this work and itturns out that Agentic AI is
really good at this problem.
For instance, claude Anthropixagent.
They've spent a lot ofinvestment in making Claude a
really good coder and it turnsout this is one of those coding
problems that we figured out howto make these AI tools be
really, really good at.
Now, obviously, we know how todo it and we're really good at

(33:45):
it.
We have lots of examples and wehave lots of training data and
we have lots of things.
But at the core of our systemis this ability to create
patches where none exist andthen patching a way that doesn't
break things, be reallysurgical with all the upgrades
and patches, and then, third,our system automatically applies
them to the container image bycreating a new container layer
where all the patches go.

(34:06):
We then generate, we build.
Once we figure all that out, weget all those patches there.
We then build a new image andthen push it back to your
registry and we just tag it withunderscore, root, io and the
combination on an average like,say I can show you later a
Python image that we do this forthe amount of hours, it's

(34:28):
dozens and dozens.
If you could even figure it outlike we can patch an image in
three minutes, that would takeany team like literally any team
with any other competitivesolution or approach days, maybe
weeks, and our system can do itin like I'll show you while
we're on this call.
Now that's the culmination of alot of really cool research and

(34:50):
work and engineering andbuilding this massive software
factory in the back end of oursystem.
We've got a SaaS platform thatmakes it really easy to interact
with and connect it to yourworld.
Everything's got APIs, butthat's pretty much the high
level thing Container in,analyze, plan, apply patches to

(35:11):
wherever we need them,reconstruct the container, emit
the container and you're done.
It happens in about threeminutes For the average
container.
Your mileage may vary dependingupon the size of the container.
Now, the other thing I shouldmention is that as soon as we
see your image and that's yourimage, by the way, I didn't make
you change over to my image.
That's your image.
Whatever image you chose todirect us to try this on

(35:33):
Competitive solutions, imagewhatever image you chose to
direct us to try this onCompetitive solutions, most of
them are image libraries.
They sell you a bunch of images.
They're super expensive.
The way they deliver them issuper expensive for them to do.
That's why they pass thosecosts onto you and it requires
you to rebase your images.
So to start with thosesolutions, you got to go back to
your engineering team and gohey, listen, I got a great
solution.
Everything's going to be great.

(35:53):
All you need to do isre-engineer all the images.
We have to use this newoperating system.
It's going to break everythingin the beginning, but that's
okay because as soon as we getover that massive toothache,
things are going to be good.
But they actually don't turnout good because many
applications can't port.
Like, if you're on Debian orUbuntu, you try to go to Alpine,
stuff just breaks and you'vegot this massive lift.

(36:16):
It takes you months to getstarted with those solutions.
This was also one of my goals.
I want anybody to be able tostart in five minutes and with
our solution there's none ofthat.
You start with your images, thestack and applications that you
love and already know.
Your engineers are all tooledup on it.
You have all your DevOpsscripts and languages and all
the things lined up.
Your cicd pipeline understandeverything that's going on.

(36:37):
Your scanner understandeverything.
We start with that image.
We patch it to zero.
You have your image but betterin five minutes.
And so you know, I checked, oh,we checked all the boxes on our
like wish list of how we couldmake this good for john amaral.
You know, four years ago atcisco, cisco, and here we are
doing that Now.
As soon as we see your image,if any new vulnerabilities come

(36:59):
up because we know your image,we go patch it.
We find, like as soon as a newone comes, our software factory
and our AI agents kick off aprocess where they go figure out
what to do automatically.
So you've been in security along time.
Patching SLAsas, right, arepretty strict like depends on on
the regime, but you know, withfederated it's like seven days

(37:19):
for a critical um.
You know what do you do when nopatch exists.
Well, you're kind of like yougot to do a polam.
You're going to be on the hookto like for con, bond, right,
right, etc.
Our, our, our autonomoussoftware factory has always got
your back.
So it it's like you're you know.
It's like you take theengineers out to lunch.
You try to get them to like payattention to the security stuff

(37:40):
you want done.
Our system doesn't need lunch,it just needs like electricity
and it wants to solve all yourpatches for you.
You don't even have to take itout to lunch.
So that's how it worked.
You know questions, comments,thoughts.
I'd love to hear your take onall that.

Speaker 1 (37:57):
I mean, I think it's really, really fascinating.
You know you're kind of teasingme here.
Now I want to dive into thetool.

Speaker 2 (38:04):
Let's go, let's go.
I'm going to do a screen share.
Good thing we tested thisearlier.
I know it's going to work, sothat's cool.
I'm just going to press, go onthe screen, share and, uh, yeah,
when you said a screen shareearlier, I was like, ah, we need
to test that, cause I've neverdone that before.
All right, we're forging newground on the uh on on this

(38:24):
podcast.
I'm going to do uh, this guyright here.
Nope, it's not on that onethere we go Share.
Hopefully it works twice.
Are you seeing my screen?
Yeah, cool, and hopefully it'szoomed in enough so the audience
can take a look.
All right, so I'll get in andcertainly stop me, joan, I don't

(38:49):
have.
This is covering your face now,so I wish it wasn't that way,
but it is Just yell at me tostop so you can ask questions as
we go.
So basically, there's a bunchof parts to this solution.
One is we've got this dashboardthat's trying to, you know,
give you a high-level view ofall the good work that this
solution does for you.
You can see and this is just atest account I test all kinds of

(39:10):
containers in here, but in theprofile of containers I've done,
you see that I've had a 73%vulnerability reduction across
all issues.
It saved like 77 days worth ofwork, 270 vulnerabilities that
are remediated.
I sometimes throw stuff at this.
That are really hard tests forit, but in general it works very

(39:33):
well at remediating and youhave an easy way to see what's
going on.
The system really, you know,kind of runs from this point.
This is the remediation tab.
This is where you get started.
It allows you to connect abunch of registries, so we have
pretty much every registry underthe sun.
As I said earlier, first thingyou do is you tie us to your

(39:54):
registry.
If you want us to work on yourprivate images, we also work on
public images.
You can start by pickingsomething on Docker Hub.
That's what I'll do for this.
But when you connect this up,you just put a registry token
here, a security token, and then, once we have access, we write
access to that registry.
When we remediate an image, wejust push an image right back to
that same registry but taggedwith root IO under it For public

(40:18):
images.
This is like a super simple wayto test and anyone can sign up
and use this platform.
There's no gating on it.
You can go check it outyourself.
You can do all the things I'mshowing you here without any
intervention from our company.
We don't ask you to call us fora demo.
You just sign up, try it andit's easy.

(40:38):
I'm going to pick Python.
I talked about that earlier.
You just select one of theseimages or you can pick from
whatever tag you want up onDocker Hub.
Today we support, as I mentioned, debian, ubuntu and Alpine
images on AMD64.
Pretty wide support setup andthen you just click the
remediate button.
It's going to bring up a modaldialogue here that kind of tells

(41:01):
you what's happening.
So we first pull the image, wescan it.
We have the trivia scannerunder the hood.
We also create an SBOM of thatimage.
Once we do that, we go intothis evaluation mode.
We look at the containercomposition, the packages, the
vulnerabilities and we make thatpatching plan.
I talked about where we dopatch selection.

(41:22):
From the upgrade list try toselect patches that have a low
semantic version difference fromthe package that's in your
image.
But our goal here is to kind oflike preserve the packages you
have from a major and minorversion perspective and bring
I'll call it very small changeupgrades to it, just targeting

(41:46):
those vulnerabilities.
Now, the goal of this is not toupgrade functionality, it's
literally to patch away thevulnerability.
So we're very targeted in thatand of course we also select
from those root patches, thoseroot patches that we've
generated that we can use withthe same mindset.
It's like bringing thesepatches to bear to literally
target elimination ofvulnerabilities so that your

(42:08):
risk profile in the containerand your ability to meet
compliance for vulnerabilitycounts in SLAs is made easy.

Speaker 1 (42:17):
Yeah, it's fascinating because I'm
wondering how long it took youto train the AI model, to build
up to the point where it kind ofknew what to do right, where it
was becoming more effective foryour use cases.
Can you talk a little bit aboutthat, potentially?

Speaker 2 (42:38):
We're pushing to roots registry.
That's what it should do for apublic image.
So now it's scanning.
So let me take off from hereand then I'll answer your
question in a minute.
Okay, so it's scanning theimage.
Now it pushed it to an internalregistry that we have, an ECR
registry, where we create atemporary location for it.
This is a public image, so itdidn't have your registry to
push back to.
We scan it again after we doall the patching and then we

(43:03):
then present the findings and alink for you to be able to go
and retrieve the image.
So part of this is we generateVEX and S-bonds for everything
we do.
So the VEX statements actuallyhave a very detailed record of
everything we patched, all thenew packages we applied, and you
can use that VEX file to informyour scanners of these package

(43:28):
changes, because natively, mostscanners don't understand these
package changes as we'vegenerated them.
Natively, most scanners don'tunderstand these package changes
as we've generated them.
We make it really easy andtransparent for users of our
system to be able to do that.
And voila, here you go.
We've got an image that had onehigh and critical and I'll show
you more about this in a seconddown to zero highs and
criticals.

(43:48):
Now that image was a curatedimage that already had like a
bit of a risk surface reduced.
And then here is a full commandfor Docker that you can go and
grab that image yourself, drillin and get the full report and

(44:09):
further.
It just didn't get rid of thehigh and critical, it got rid of
all the mediums.
So this container has zerohighest criticals and mediums.
This is a very typical resultfor the image, for these
operating system images thatI've shared.
It could be Python, node,whatever, php, but we have very

(44:29):
good success across a wholebunch of images.
I'll show you the kinds ofimages we operate on and we have
a big list of those that wetest on and offer, as I'll call
it, convenience images forpeople.
But we don't sell images.
We sell this service.
You can run this on your images.
If you have a Python versionthat's on Debian that you use
for your base or node or youname it, you don't have to

(44:53):
rebase.
You just run our tool and youget a new image that has much
less vulnerabilities Behind thescenes.
Here we added 18 of these rootpatches, these custom patches
that we developed using ouragentic AI system and our really
fabulous research team.
And something to note Imentioned that these semantic

(45:15):
versions are very close and infact, this libcap2 vulnerability
has no patch in Debian.
That's why it's a root patchand we actually provided a patch
to the exact library you hadwith our root extension and we
probably only changed a fewfiles in kind of a small number

(45:39):
of lines of code probably lessthan 100 lines of code is
typical that we'd have to change.
It's very surgical.
It doesn't change anything withthe package that would make it
any compatibility issue.
All of the capabilities, filesignatures.
We regression test theselibraries so we know they work
exactly like the version didprior to patching.

(46:00):
So it's an exact fit, exceptthe vulnerability has been
patched away.
And that's what we do.
We work on the who's who ofimages.
Just one more thing, sorry, youcan come in and look at our
image catalog.
These are all images that wehave done extensive testing with
to show that our AVR works wellacross those operating systems.

(46:24):
In fact, these images are also.
They're not patched by us, butwe do offer these as images that
we've curated a bit because, um, I think if you just go
download these from, like youknow, public registries they'll
have.
Like you know, some of themhave hundreds of vulnerabilities
.
We've done a service to the, tothe world, to make these, like

(46:46):
you know, something much smallerand much more, um, I think,
lower vulnerabilities, because Idon't think you should start
with that 500 bones but then youcan run these and patch them
down to near zero or zero withour system.
So if people want to use these,they can, but it's not
necessary.
You can just use what you gotand run it through our system,
and that's how people do it.

Speaker 1 (47:07):
So with the patches that you showed on the previous
screen?
So with the patches that youshowed on the previous screen,
are you essentially?
Is that considered backportinga patch into?

Speaker 2 (47:18):
the package Exactly right.
That's a backported patch andour agentic AI system and our
researchers.
What they do is, for instance,for that one I showed you, lib,
libcap, and this is true forevery one of those patches.
Our research, we have two, twoagents.
We have a research agent and apatching agent.

(47:38):
The research agent goes out andresearches the vulnerability
and it researches theeffectively.
It scours the internet.
It knows you know good startingpoints to, but it goes and
looks for code commits to thisecosystem of libcap.
So it could look at themaintainer's GitHub repo where

(48:04):
all source of code comes from.
Or it could go look in Debian'srepos you name it.
It could look in Ubuntu's reposTheans repos you name it.
It could look into Ubuntu'srepos.
We look for places where we finda FIX in a later version of
that library or we look for aFIX that may exist that's never
been merged with that library,and these happen in two forms.

(48:28):
And then backporting happenswhen we find those and then we
basically analyze our patchingagent.
Once the analysis is done bythe research agent, the patching
agent takes that research andit does code analysis on a place
where that fix exists, maybe anewer version of the software
say LibCap was version 1.3.5.

(48:51):
If 1.2 has it fixed, but 1.3.5.
If 1.2 has it fixed but 1.35doesn't.
We look at 1.2's code.
We have our patching agentexamine it, understand the
changes that were made relatedto the commits around that fix.
We deduce all of that.
We then look at the code in1.3.5, and we fit those changes

(49:12):
into that code base, build a setof commits for that, merge it
in and then run extensive testson that library to make sure
that we didn't break anythingand also verify that the patch
worked, meaning that it actuallydid mitigate the vulnerability.
So there's a lot of testing andthere's a lot of this

(49:33):
backporting and codeidentification.

Speaker 1 (49:38):
But that's, exactly how it works.
Is there?
I mean, maybe I'm just not asfamiliar with like container
security patching overall, right, Is there a possibility of
running into or inducing issueswith this kind of style of

(49:59):
patching and maintaining thoseimages?
I ask kind of twofold, right,if something does go wrong, how
do you go backwards?
And two, is it even likereasonable to think that things
would go wrong, which soundsvery weird from a security
perspective?
Right, because in securityyou're always assuming

(50:22):
something's going to go wrong,something's going to break.
You know there's going to besome sort of issue, right?
So you always have to have likethat backup plan in your back
pocket just in case?
Yeah, so that's a good questionback pocket, just in case.

Speaker 2 (50:32):
Yeah, so that's a good question, a good multi-part
question.
I'll unpack it.
So first of all, as I mentioned, we're extremely surgical with
these changes.
This kind of patching is notI'll call it exotic or foreign.
This is what you do when youneed to patch stuff.
We're simply using upgrademechanisms that are built into

(50:55):
package managers, etc.
The sophistication here isfiguring out which patches to
apply and also building patches.
It's not uncommon I think maybethat's an understatement.
It's common and universal thatfolks pick up new container
images when they want to haveupgraded packages.

(51:17):
I mean, if you got your imageoff docker, how do you wait for
the next version?
You got your patches there.
You take them right, or you runapk upgrade or you know, or you
know you run the upgrade on the, on the docker file, you build
a new image and that's your newimage.
So it's not uncommon to upgradethese things.
It's is all third-party code,so it's very unlikely it's
mostly never the case thatpeople have these libraries as

(51:40):
something they build.
When you use Debian, you don'tstart with Debian's source code.
You start with Debian's images,so you start with Debian's
distribution.
So patching this way incontainers is not foreign at all
.
It's actually quite natural,it's normal.
As for breaking, that's the.
We don't break images,basically because we really

(52:04):
manage to change scope, andthat's the key.
That's the art of this.
Backported patches have reallyhigh reliability and these
semantic version differenceslike these are just the only
code that changes is just thecode that's needed to fix that
patch.
And when we select upgrades, wealso look for really small

(52:25):
semantic version differences andthat means that these are just
security updates, which are, youknow, technically with a good
provider.
That semantic versiondifference means that they've
only introduced security fixesand the implicit guarantee is
that those don't have anyfunctional breaking changes.
Now we do a lot of verificationon this stuff to help make sure

(52:46):
that that's the case, but ingeneral, that's a good
assumption.
So we're doing kind of normalthings, we're doing them very
safely and we're really good atdoing it well.
Now how do you go back ifsomething breaks?
Well, you have the originalimage.
We only patched the one yougave us right.

(53:07):
So you've got our image.
You've got your old image.
If you've got DevOps maturityand you run tests and staging
and all that, you put our imageinto your normal DevOps flow.
As I said, people turn us onthrough CICD where they run us
and they and I'll stop sharingSorry, we're sitting here, so

(53:33):
you just run us through yournormal testing paces and and
away you go.
So again, I mentioned that weput all these fixes in one layer
in your container, so literallylike layers one through n are
your layers untouched by us.
Layer n plus one is our stuff,so everything is isolated there.
The cool thing about thelayered file system in images

(53:55):
and the way they build is youcan kind of modify any of the
layers from any layer, so tospeak.
That's an oversimplification,but all our changes exist in
that one layer.
If we break, you can try theold image.
It's easy to figure out what'sgoing on and then we have some
pretty cool ways to debug if yourun into problems.
But generally our customersdon't have any problems.

(54:16):
They're good.

Speaker 1 (54:18):
Yeah, that's fascinating.
You know, earlier on in mycareer I dealt with a lot of
backporting patches right andworking with my devs to get them
backported in.
And then you know the scans arestill failing right, because
the scans are kind of dumb inwhat they're looking for.
They're looking for thatversion change.
Well, if you backport, theversion doesn't necessarily

(54:40):
change.

Speaker 2 (54:42):
That's where the VEX comes in.
So we use these VEX files totransfer this and lots of
scanners can take VEX as inputnow, so that basically informs
them about the package changesand what we changed and that's
also a transparency measure foryou to be able to use that to,
or users of our platform to beable to understand our changes.
I will also add that every fixwe do, we subject it to standard

(55:05):
open source practices.
So we publish all of our fixes,all the code we change, into a
publicly available GitHub repo.
It turns out it's really hardto do anything with these
patches because the build stuffis really like we've got a
massive software factory and toreproduce all these patches in a
functional way from the sourcecode isn't that easy.
But we put it out there becausewe want people to see what we

(55:27):
change.
We want them to be able toreview it if they want, and our
customers want that.
They want to know that we'retransparent.
We're not a black box, we're anautomation system and we do a
lot of heavy lifting forcustomers to get those backports
done.
I'm sure that your experiencewith those backports is it takes
a long time to build them.
Engineers don't like to do itand it's fraught with risk and

(55:47):
I'll call it risk from gettingengineers to deliver is hard
because it takes expertise toknow how to backboard things.
We're really good at it and ouragents are really, really,
really, really good at it.
I don't know what your memoryis, but our agentic system can
produce backboards in like 10minutes.
Wow, it probably would havetaken engineers to do the set I

(56:11):
did.
I know how long it takes.
We did a bunch of them manuallybecause we like to learn.
You know, the average backporttakes three days, four days of
an engineer's time, maybe more.

Speaker 1 (56:21):
It depends how complicated.

Speaker 2 (56:22):
It is For really good research engineers that's like.
It can be hours to days, toweeks, depending upon complexity
.
Some of those patches wegenerated have a dozen, two
dozen file changes, five, tencommits that we got to figure
out how it applies to that olderversion, and our system is very
excellent at that.

(56:43):
Back to your question, though,I would say, yeah, we're getting
integrated with scanners, sothey naturally know about our
packages because we put thatrootio and we also have a feed
that matches up thevulnerability fixes and the call
it the, the effectivitystatements, like.

(57:06):
We fix this by doing thefollowing into a feed and
scanner vendors can take thosein and inform their databases.
So that's one way to tackle itand this is a very common way to
integrate with scanner vendorsso they know about this sort of
thing.
And then our VEX statements canbe imported into scanners
Trivia is excellent at usingthis Docker Scout's another one
that's excellent using VEX sothat you can inform your

(57:27):
scanners about what we fixed.
And, of course, our scanner inour platform, which is Trivia,
uses the VEX statements as well.

Speaker 1 (57:33):
Yeah, it's fascinating.
It's an interesting way ofapproaching this complex problem
that so many people just wantto run from it, right.
They kind of want to dodge it,and more and more of the
infrastructure on the internetis running off of containers,
and so people in security arejust like you know.
They're kind of at a loss,right, because they don't have

(57:56):
something that they can say.
Hey, you know this isn't goingto add an hour to your day or
add a week to your sprint orwhatever it might be.
You know you can still deliver.
You know your feature requests,your milestones and whatnot, as
well as maintaining security inthe product that's.

(58:17):
You know.
It's an interesting proposal,for sure.

Speaker 2 (58:21):
Yeah, and what you didn't see when I ran our tool
and this is exactly what ourcustomers experience is I didn't
have to ask some engineer tochange anything.
All you need to do is plug usin.
Engineer change anything, allyou need to do is plug us in.
We literally have customersthat do this for their 10, 20
base images, plug us into the CICD pipeline, get onto this SLA

(58:44):
easy button Because, again,we're fixing all the new
vulnerabilities that come tooand you're getting those as the
service runs.
And that's really the core ofthe service.
The core of the service ismaking it easy for you to very
quickly get your images to areally much better place, like
near zero vulnerabilities orzero, as I showed you, but then

(59:05):
making it so that asvulnerabilities come, we're
taking them on and fixing themas you go automatically.
So SLA is kind of the core ofthe service.
They get through doing this onall their images in a week, less
than a week.
Then most of it's just themintegrating it into their
workflows and getting CICD setup.
But we have customers thatliterally plug us into CICD in
four hours, run all of theimages, get through all of the

(59:25):
testings and be done in the sameweek.
Yeah, no engineering resourcesrequired, and this will save
them hundreds, if not thousands,of hours a year.

Speaker 1 (59:37):
Yeah, it's, that's definitely fascinating.
That's really interesting to todive into.
Well, john, you know,unfortunately we're we're at the
top of our time here and it'sbeen a fantastic conversation.
I really appreciate you comingon.

Speaker 2 (59:52):
I loved it.
I think I really appreciatethat you do this and kind of put
great information out there andexcited that you are kind of
caring for the community ofsecurity people out there.
I think this is a wonderfulservice.
So great to meet you and dothis today and happy to help any
way I can.

Speaker 1 (01:00:10):
Yeah, absolutely.
Well, I really appreciate that.
Well, before I let you go, howabout you tell my audience you
know where they can find you ifthey want to reach out and
connect and where they givetheir root?

Speaker 2 (01:00:22):
Sure.
So you can find us at wwwrootioand you can use the application
just like I did, with no hassleat approotio.
Approotio, r-o-o-t.
Like you know, the root thetree, and if folks want to reach
out to me, you can just hit meup at john at rootio.
I love connecting up on email.

(01:00:42):
Shoot me a note if you'reinterested or you want to talk.

Speaker 1 (01:00:45):
Awesome.
Well, thanks everyone.
I really hope that you enjoyedthis episode.
More to come.
Thanks guys.