(soft music)
>> And welcome to the DockerCon CUBE coverage
here in the main stage.
Sudhindra Rao, Development Manager at JFrog.
Welcome to theCUBE.
You guys have been on many times with JFrog and theCUBE.
Great product you guys are doing great.
Congratulations on all the six.
Thanks for coming on the cube.
>> Thank you.
Thank you for having me.
>> So I'm really interested in talking
about the supply chain package management,
supply chain and software workflow, huge discussion.
This is one of the hottest issues that's being solved on
with in DevOps and DevSecOps in the planet.
It's all over the news, a real challenge.
Open source, growing so fast and so successful
with cloud scale and with automation, as you guys know,
(laughs) you got to know what's trusted
so you got to build trust into the product itself.
So developers don't have to do all the rework.
Everyone kind of knows this right now,
and this is a key solve problem you guys are solving.
So I got to ask you, what is the package management issue?
Why is this such an important topic
when you're talking about security?
>> Yeah. So if you look at how software is built today,
about 80 to 90% of that is open source.
And currently the way we pull those open source libraries,
we just have blind trust in repositories
that are central, and we rely on whatever mechanism
they have built to establish that trust
with the developer who is building it.
And from our experience,
we have learned that that is not sufficient.
That is not sufficient to tell us
that that particular developer built
that end product and whatever code
that they build is actually coming out in the end product.
So we need something to bridge that gap.
We need a trustworthy mechanism there to bridge that gap.
And there are a few other elements to it.
All these central repositories are prone
to single point of failures.
And, in, we have all experience
what happens when one of those goes down
and how it stops production
and how it stops just software development, right?
And what we are working on is how do we build
a system where we can actually have liquid software
as a reality and just continue to build software
regardless of all these systems,
of being live all the time, and also have an implicit way
of mechanism to trust what is coming out of those systems.
>> You know, we've talked with you guys
in the past about the building blocks of software
and what flows through the pipelines, all that stuff's part
of what is automated these days and important.
And what I got to ask you, because security these days
is like, "Don't trust anything."
Here you're trusting software to be in essence verified.
I'm simplifying, obviously.
So I got to ask you what is being done to solve this problem?
Because states change, you got data,
you've got software injections, and you got,
we got containers and kubernetes right here helping,
all this is on the table now
but what is currently being done to solve the problem?
'Cause it's really hard.
>> Yeah, it is a really hard problem.
And currently, right?
When we do develop software
we have a team which we work with and we trust
whatever is coming out of that team.
And we have a,
what do you call certified production mechanism
to build that software
and actually release it to our customers.
And when it is done in house,
it is easy because we control all the pieces.
Now what happens when we are doing this with open source,
we don't have that chain.
We need that chain, which is independent of where
the software was produced
versus where it is going to be used.
We need a way to provenance of how it was built,
which parts actually went in making the end product.
And what are the things that we see are continuing evidences
that this software can be used?
So if there is a vulnerability that is discovered,
now that is discovered, and it is released in some database
and we need to do corrective action to say
that this vulnerability is associated with this version.
And there is no automated mechanism.
So we are working on an automated mechanism
where you can run a command which will tell you
what has happened with this piece of software,
this version of it,
and whether it is production worthy or not.
>> It's a great goal.
I got to say, but I'll tell you, I can guarantee
there's going to be a ton of skeptics on this security people.
"Oh no, I doubt, it's always got a back door."
What's the relationship with Docker?
How do you guys see this evolving?
Obviously, it's a super important mission.
It's not a trend that's going to go away.
Supply chain software is here to stay.
It's not going to go away.
And we saw this in hardware and everyone kind of knows
kind of what happens when you see these vulnerabilities.
You got to have trusted software, right?
This is going to be continuing.
What's the relationship with DockerCon?
What are you guys doing with Docker and here at DockerCon?
>> So when we actually started working on this project,
both Docker and JFrog had had similar ideas in mind
of how do we make this trust mechanism available
to anyone who wants it, whether they're interacting
with Docker Hub or regardless of that right?
And how do we actually make it a mechanism
that just provides this kind of trust
without the developer having to do something.
So what we work with Docker is actually
integrating our solution so that anywhere
there is Docker being used currently,
people don't have to change those behaviors
or change those code lines, right?
Because changing hand, changing the single line of code
in hundreds of systems, hundreds of CI systems
is going to be really hard.
And we wanted to build a seamless integration between Docker
and the solution that we are building,
so that you can continue to do Docker Pull and Docker Push,
but get all the benefits
of the supply chain security solution that we have.
>> Okay. So let's step back for a minute
and just discuss about the pro, what is the project?
And where's the commercial JFrog Docker intersect,
take the, break that out hard.
Just step up the project for us.
What's the intended goals.
What is the project?
Where is it?
How do people get involved?
And how does that intersect with the commercial interest
of JFrog and Docker?
>> Yeah.
My favorite topic to talk about.
So the project is called Pyrsia.
Pyrsia is an open source project.
It is an effort that started with JFrog and Docker,
but by no means limited to just
JFrog and Docker building.
We already have five companies contributing.
We are actually building a working product,
which we'll demo during our talk.
And there is more to come, there's more to come.
It is being built iteratively, and the solution
is basically to provide a decentralized mechanism
similar to how you do things with Gade,
so that you have the packages that you are using,
available at your nearest PI.
There's also going to be
a multi load build verification mechanism,
and all of the information about the packages
that you're going to use, will be available
on a provenance log.
So you can always query that
and find out what is the latest state of affairs
what vulnerabilities were discovered
and make quick decisions.
And you don't have to react after the fact,
after it has been in the news for a while.
So you can react to your customer's needs
as quick as they happen.
And we feel that our emphasis on open source is key here,
because given our experience, 80 to 90% of software
that is packaged, contains open source,
and there is no way currently,
or no engineering mechanisms currently, that give us
that confidence, that whatever we are building
and whatever dependencies we are pulling
is actually worthwhile putting it into production.
>> I mean, it really is, it's a great service.
I mean, you think about like all that's coming out
open source,
open source has become very social too.
People are starting projects just to code
and get in the community and hang out and just get
in the fray and just do stuff.
And then you see venture capitals coming in,
funding those projects.
It's a new economic system as well, not just code.
So I can see this pipeline beautifully up for scale.
How do people get involved with this project?
'Cause again, my question is all going to be
around integration, how frictionless it is.
That's going to be the challenge, you mentioned that.
So I can see people getting involved.
What's, how do people join?
What do they do?
What can they do here at DockerCon?
>> Yeah, so we have a website, pyrsia.io,
P-Y-R-S-I-A dot I-O,
and you'll find all kinds of information there.
We have a presence.
We have community meetings that are open to public.
And we are all doing this under the umbrella
of Linux foundation.
We had a bootstrap project within Linux foundation.
So people who have interest in all these areas can come in,
just attend those meetings,
add comments or just attend our standups.
So we are running it like a agile from process,
we are doing standups, we are doing retrospectives
and we are doing planning
and we are iteratively building this.
So what you'll see at DockerCon is just a little bit
of a teaser of what we have built so far
and what you can expect to see in future such events.
>> Sudhindra thanks for coming on the queue.
We've got 30 seconds left
put a quick plug in for the Swamp Up, coming up.
>> Yeah. So we will talk a lot more about Pyrsia,
and our open source efforts
and how we would like you all to collaborate.
We'll be at Swamp Up in San Diego on May 24th to 26th.
So hope to see you there, hope to discuss more about Pyrsia
and see what you will do with this project.
Thank you.
>> All right, thanks for coming on theCUBE,
back to the main stage.
I'm John for theCUBE.
Thanks for watching.
(soft music)