 Welcome to the DockerCon Cube coverage here in the main stage, Suhindra Rao, development manager at JFrog. Welcome to theCUBE, you guys have been on many times with JFrog on theCUBE, great product, you guys are doing great, congratulations on all the six things that are coming on theCUBE. 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 by, within DevOps and DevSecOps in the planet. It's all over the news. A real challenge, open source is growing so fast and so successful with cloud scale and with automation. As you guys know, 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 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 built 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 then there are a few other elements to it. All these central repositories are prone to single point of failures. And we have all experienced 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 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 I got to ask you because security these days is like, don't trust anything. You know, here it's 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 know, you got data, you got software injections and you got containers and Kubernetes right here helping. All this is on the table now but what is currently being done to solve the problem because it's really hard. Yeah, it is a really hard problem. And currently, right, when we develop software we have a team which we work with and we trust whatever is coming out of the 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. We just independent of where the software was produced versus where it is going to be used. We need a way to have 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 use. 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 it 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, I doubt it's going to be always a backdoor. 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 similar ideas in mind of how do we make this trust mechanism available to anyone who wants it whether they are 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 that is Docker being used currently people don't have to change those behaviors or change those code lines, right? Because 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 Dockerflow and Dockerpush 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 project. What is the project and where's the commercial JFrog Docker intersect? Take a break that I had to step up with the project first. 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 interests of JFrog and Docker? Yeah, my favorite topic to talk about. So the project is called Persia. Persia 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 contributing. 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 Git so that you have the packages that you are using available at your nearest peer. 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 law. 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 customers needs as quick as they happen. And we feel that our emphasis on open source is key here because given our experience, you know, 80 to 90% of software that is packaged contains open source. And there is no way currently which are no engineering mechanisms currently that give us that confidence that whatever we are building and whatever we are dependencies we are pulling is actually worthwhile putting it into production. I mean, you're really, it's a great service. I mean, think about like all that's coming out of 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 capital is 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? Because again, my question is all gonna 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, persia.io, P-Y-R-S-I-A.io. And you'll find all kinds of information there. We have a GitHub presence. We have community meetings that are open to public. We are all doing this under the 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 an 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 will 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. So Hydra, 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 persia 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 26th, May 24th to 26th. So hope to see you there. Just hope to discuss more about persia and see what he will do with this project. Thank you. All right, thanks for coming on the queue. Back to the main stage. I'm John Furrier with theCUBE. Thanks for watching. Thank you.