 Live from San Francisco, it's theCUBE. Covering RSA Conference 2020 San Francisco, brought to you by SiliconANGLE Media. Hey, welcome back, everybody. Jeff Frick here with theCUBE. We're at the RSA Conference downtown San Francisco, about 40,000 people. In the year, we're going to know everything with the benefit of hindsight. It's not really working out that way. So we're still going out to the events, getting the smartest people we can find to bring it in to you. We're excited to have our very next guest. He's Steve Chin, the Senior Director of Developer Relations for JFrog. Steve, great to meet you. Okay, no, thanks very much for having me here at the conference. Absolutely. So for people that don't know JFrog, give them kind of the 101. So I think the simplest way to describe our company is we're the database of DevOps. The database of DevOps. I don't know that that would be the simplest way. But basically when companies want to deliver software faster, when they're looking at how to speed up their feature development, how to re-expand quicker to security, we provide an end-to-end DevOps platform, the JFrog platform, which accomplishes this for companies. Right. Okay, so a lot of people know about DevOps. A lot of people have experience with rapid iteration on their apps. They don't know why they have to keep uploading updates all the time. There's a ton of great benefits to that in this really revolutionized the software industry. That said, the other kind of theme here at RSA in a lot of the security conferences is you can no longer bolt security on. It can no longer be a moat around the castle. It can no longer be a firewall on the edge of the network that it has to be baked in all the way through the product. And that goes right back to kind of what you guys do and on the DevOps. How do devs who didn't necessarily get trained on security, don't necessarily want to know about security, probably would prefer not to have to deal with it. They probably liked it better when they could just push it off. But kind of like they used to push it off to prod, that's not the way anymore. They have to bake it in. So how do you help them do that? What do you kind of see in terms of trends in the space? Yeah, so I think what we're seeing in the industry is that companies want to deliver, they need to deliver software more quickly and more rapidly just based on user requirements. So if you think about your phone, your car, like pretty much everything is updating constantly and it's not even a choice anymore. Updates get pushed to you because you need new features, you also need security fixes for things. And this is happening weekly, daily, hourly, as new threats are exposed. And for companies, the standard processes which might have been used in the past to have security reviews, to run complicated scanners, to have different checkpoints, that doesn't work in an environment where you're continuously deploying. And really if you think about it, the only way you can accomplish rapid iteration, high security, is to be doing security scouting as a part of your workflow, as a part of your DevOps workflow and shifting left. So going towards the developers and giving them more tools which give them information about potential security risks. So as an example, developers code an IDE or some sort of visual environment and if you can present the information upfront right there and tell them, hey, this open source library you're using, it has a security vulnerability, there's a new version you should upgrade. Or hey, this component that has an incompatible license, like this doesn't meet our security requirements. Those sort of things, if they're caught while you're developing new features, it saves time and money there, but it delays potential slippage, risks, pushback from the security team at the other end. The next step is when they check in code or when they're executing a build, you want to be scanning upfront. Scan the build, scan the binaries really far up the chain and that way you're catching security vulnerabilities during the iterative development process. By the time you get to like QA to stage to production, security vulnerabilities shouldn't be a surprise. It should be something which the teams upfront know about their addressing and you're using tools which are designed in that workflow to really give early off and feedback to the teams up the chain. It's the only way like all the large companies doing continuous deployments. This is how you have to approach it. You use multiple techniques, you use binary scanners, you use source code scanners, even runtime scanners and you make sure you shift as much left as possible which is exactly what the JFrog platform enables development teams to do. So what percentage roughly is just making sure you've got the first thing that you described, that you've got the right libraries that you're using the right tools that have already gone through some security protocol check versus just writing in a bad sequence of steps or a bad API call or opening up some hole via just bad code choices. Yeah, so I think increasingly as companies depends more on third party libraries, open source libraries. If you think about your average application, you're bundling in hundreds of different components and libraries which you have relatively little control over. And a simple way to look at this is if you created a Docker container today, you load it up with a bunch of Debian packages, maybe a few application bundles, within a few days at the end of a month there will be full of security vulnerabilities. So that container you built one month ago. It will be full. Is outdated, you'll have hundreds of security vulnerabilities just in a month. Just because of outdated patches or because people see it and attack it? Well, the thing is you constantly have folks releasing new software, identifying vulnerability risks, patching those risks. And if you don't stay current, if you're not constantly updating your software to stay up with the latest security patches, you're putting your customers in your own business at risk. So I think today that is the number one issue with software is we all depend on open source libraries and components which are used by a lot of companies, are constantly being improved and then patched. And the most important thing is knowing when there's security vulnerabilities, identifying the risk of how those impact your customers and then patching as quickly as possible. Right. And then the other piece of it is just APIs to lots of other people's software that I don't necessarily have access to, rights to. So the fact that so much of this stuff is all tied together now interdependent, this opens up kind of a whole another layer of a potential attack surface. So are you seeing things change in kind of IoT as kind of OT and IT come together with IoT and a lot of those OT devices were not necessarily set up for patching. They weren't necessarily set up with easy to get into operating systems or maybe too easy to get into operating systems. How are you seeing kind of all the growth that's happening there impact this conversation? Yeah, so I think, especially with edge devices, I think what we've realized is that edge devices which aren't being updated are insecure edge devices. So if you don't have a plan for how you update and you patch and you address security vulnerabilities in your edge devices, they're subject to the same risks. Right, right. I mean, if they're running a variant of Linux, then they're running open source software. They're running a bunch of libraries. If they're on the network, they're open to network attacks. And we have even more complicated edge devices rolling around the roads now. There were some critical security patches in several of the self-driving cars with breaking systems, with obstacle avoidance systems. So if you don't have an aggressive plan on how you're patching your edge devices, you reach the same sort of challenge. And what that involves, again, is identifying what libraries and components you depend upon, assessing the security risk which those pose, and then having a distribution plan. How do you go from your systems through builds, through deployments, and then do the edge distribution to all the devices to get critical security updates to your end users as quickly as possible? I'm just curious, who do you see on the teams that ultimately has responsibility that this is ready to go or not go? Because we've seen too many instances of stuff that gets shipped that's not ready to go. I can certainly see the pressure to get stuff shipped and somebody says, well, that's okay, we'll just get that patch out. We'll get that patch out next week, or we'll get that patch out sometime down the road. And we've seen a ton of things go out that are super easily hacked. Children's toys and some of these things that have all kinds of really bad implications to it, is there somebody usually on the team that needs to give the stamp of approval? Is it more kind of a broad, a broad sort of execution? I think the traditional approach is having somebody within the company responsible for security, but increasingly to effectively address security, it needs to be the ownership of the whole team from end to end to make it successful. So the more the security team can be an ally of the QI team, of the development team, of the DevOps team, rather than being the gatekeeper, they want to be the ally of those teams, then the more successful it is. So arming the other teams in your company with knowledge about security risks, arming with tools, which provide visibility into different security vulnerabilities, that's the way in which you have a end to end secure product because when you get to the release, if the security team holds up the release, you're either making a bad decision or a bad decision. Catching it up front when you're building features, then you actually can address it and build the right security into your product, which is much better for your customers and your company. Well, Steve, interesting conversation, interesting times. The DevOps and the rapid deploy is certainly the way it is that we're here. So being able to effectively make that security is not only a good thing, but really a necessary thing. Cool, and that was a great chatting with you and the conference here is great to see all of these folks focused on improving security and taking us to the next generation with more secure edge devices. Yeah, I don't think there'll be any shortage of need for security professionals at any time soon. All right, well, thanks again, Steve. All right, thank you. All righty, Steve, I'm Jeff. You're watching theCUBE. We're at the RSA Conference in downtown San Francisco. Thanks for watching. We'll see you next time.