(upbeat music) >> Welcome to the Q3 "AWS Startup Showcase", I'm Lisa Martin. We're going to be talking about new breakthroughs in DevOps, Data Analytics and Cloud Management Tools, with WhiteSource Software, at least for the DevOps track. I'm excited to welcome Susan StClair, Director of Product at WhiteSource software to the program. Susan, it's great to see you! >> Oh, very excited to be here, Lisa, thank you. >> We've got a lot of stuff to talk about today, but ultimately, the theme that Susan's going to talk to us about us is, winning developer's trust is key to scaling-up open source security for the enterprise. We're going to unpack that. You talk about, that winning that trust is key, shifting left won't work without developers buy-in. Susan, help us understand this. >> Yeah, sure, so- on some of the topics we have later but you look at the rate of applications of being the pool of how fast that is, and you look at development teams of hundreds and you have the OpSec teams of five or ten, and they just can't do it all, so, really, you need to leverage everybody who's part of the application to really be able to make sure that you're developing and deploying and releasing a secure application. So, that's the Shifting Left. Unfortunately, I think what's happened is, because application security is overwhelmed and because they're like, "Oh, we have all of these developer teams over here, and it's their code, and they should fix it." And they just kind of dumped application security on them and the poor development teams are like, "but that's not what I do, I don't have any expertise in there." So if you really, truly, want a Shift Left to work, you do need to build that buy-in, you do need to build the trust with your extended team, for lack of a better word. And, really start to look at things that are important to them. So automated tools, making sure that they work with their tools sets and their processes. Looking at automation, not just in terms of scanning but also remediation. You just really need to start to work with them and think about application releases in a different mindset. >> And your recommendation here is also to build that trust gradually, and to let developers control the pace- >> Absolutely >> And the level of automation. Talk to me about why it's important to give the developers that control? >> Yeah, sure. Again, I think nobody likes to be told what to do, I certainly don't, don't tell me how to do my job. So, I think, that because historically application security and development have really been at odds. It has been somewhat of a confrontational relationship, so, I think as you're starting to build that trust, you do need to go slow. Where does it make sense to add in auto-remediation solution like WhiteSource, right? Where does it make sense? We don't want to do it everywhere, we don't want to overwhelm development teams with this. So, really start to look, let them control the pace, build that trust, build that. This is a good thing for everybody. And, again, I think with tools like WhiteSource, the solution software, you can pick and choose, it's not an all or nothing. We're going full automation, full remediation, one-stop-shopping, I mean you can kind of control the pace as you start to build that trust between the various teams. >> Is that differentiator for WhiteSource the ability for this auto-remediation tool to let them control that? >> Yeah, it definitely is, and I know it just rolls off the tongue, doesn't it? Just rolls off the tongue. >> It really does. (both laughing) >> Say it ten times fast >> I'm afraid to. >> Exactly, exactly. So, no, it actually, absolutely is a differentiator for us. And again when we look at, looking at our customer base and enterprise and we look at, even maybe smaller teams that trust is really made us successful and the key to that trust is really that controlling the pace with auto-remediation. And, some of the other automation pieces to the solution. >> And speaking of customers, you guys have 23% of the Fortune 100 as customers, give me an example of one of your favorite customers that you think really shows the value that WhiteSource is giving to those developers by giving them that control. >> Yeah, sure. So I feel like we're like the big company or bigger company that nobody has heard of outside of this space. But, not naming names, but large financial customers and really shifting application security, open-source application security, to the hands of the development teams. So they've actually, again, small application team, they've really pushed it out to the development teams as part of a repo-integration for scanning, for ticket creation, for auto-remediation, and that's really, let them scale beyond, just one or two teams to thousands of repos, for example. I mean, that is, in my opinion, a huge use case or huge validation of that this works. This isn't just somebody talking about how cool their software is and it's not based in reality. >> A stat that I read about WhiteSource offer that I wanted to get your feedback on, is that, "WhiteSource goes beyond traditional detection, providing dependency and trace analysis and that this helps organizations eliminate upto 85% of security alerts." That's a big number. Talk to me about how you guys do that and the advantages that delivers. >> Yeah, sure, so I think like the one of the challenges with, historically, with open-source solutions, is that they scan and they get this result, and you could have hundreds and thousands of insecure libraries and you're like, "Holy moly, where do I even start?" It's just completely overwhelming. And then you dig into little deeper and again starting to build that trust with development teams, and the development teams comes back to you and says, "Well, hey, guess what? Yeah I know that library is insecure, but I'm not using that part of that library." So, it's really kind of a false-positive. So, what this dependency tracing does and how it helps with prioritization, is it says, "Okay, we see this particular library, this vulnerable open-source library, and it is in your execution path, we can see that you're using it." So then, you're able to say, "Okay, I should definitely fix this, because we're using it, or maybe not." Maybe, again, it's part my backlog yes, we should always keep up-to-date, and be completely secure. But having that ability to prioritize where to start and having the alerts based on that really reduces the noise. And again, it builds the trust between the teams. >> So, we talked from the beginning about shifting left isn't going to work without developers buy-in, the idea of using auto-remediation tools to let developers control that pace, the OpSec folks, the Dev folks, we also have for, I believe, it's the fifth consecutive year now, a huge gap in cybersecurity skills. I think I've seen some reports estimating that there needs to be another three million professionals in the next five years to help fill that gap and at the same time we're seeing the security landscape changing dramatically. Talk to me about how the cybersecurity skills gap is affecting developers, OpSec folks, and what your seeing as a tool that can help remediate some of that. >> Sure, yeah, no, that's, I mean that is the challenge. And I would even say that there seems to those skills gap on the development side too. But, I think that in terms of some of the challenges with that, so you have to look at ways, how can we be smarter about things. So, we don't have people, large teams where they know everything about application security and open-source security that we can really rely on to drive remediation, but, also to use these tools that all of us bought that do different things, that aren't correlated but to kind of provide that glue. So, where WhiteSource, I think is trying to address this is, again, if I don't have the people, and I don't have the skillsets, first of all automation, right? So, the more that we can automate, the better. But, not just again, automating on the scanning side, I think that's certainly a part of it, but again, looking at how we can help development teams that are maybe not security experts, and keeping them up-to-date and giving them, again, automatic remediation so that they can fix things without having a really depth that you would expect in a cybersecurity professional. >> I'm sure they appreciate that, not having to have that depth, because there really isn't, in terms of developers, there isn't the time. Speed is always of the essence there. One of the things too that I know, is there's lot of tools being used, you mentioned that. How can WhiteSource Software help the developers to better utilize some of the tools that they have or not just be buying tools to check boxes? >> Yeah, sure. So, yeah it's sad fact, I think, within our industry, probably more than just our hours, but really a lot of decisions, purchasing decision are based on the, "Well, I need to scan because somebody told me to and I that I had to, and I'm going to check the box. I'm not really interested in fixing anything, I just need to check that box." And, I think, historically, when it comes to tool selection, again, because application security is really focused on that check-the-box because they need to do that for a compliance or governance reason, they really haven't taken into heart the teams that would actually be using them and having to make the magic happen. So, they would prioritize things that, again, maybe OpDev wouldn't, so, again does it work with my tools? As a developer, I live in my IDE, I live in my code-repo, I live in my ticketing system, security doesn't typically care anything about that. So, I think with WhiteSource, again, providing the tools that the OpSec team needs. So again, the compliance reports and the policies and all this stuff we love. Also providing, again, the way to easily fit into developer workflows, that's how we're helping to move beyond, okay, we're checking the box but we do want to actually fix something and we want to move the target along. So we're really, I think, helping address that need as well. >> I know you guys did a DevSec Ops Insights Report recently, unpack that a little bit with some of the key findings that have come out of that. >> Yeah, no, that's great, so it's very interesting. First of all I think we in the industry we talk a lot about DevSecOps and that security is part of the DevOps process and everything is good. But when you actually talk to people, I think, two things, one, it's very much a work in progress, absolutely, and a lot of that is part of the tooling. I think, too, like what we've found as a part of this survey, is that the developers, are often, they feel forced to, okay, I'm shifting left, you're telling me I own security, but you're also telling me that I need to get this application out the door. I need this to compete. So, they're really being forced into hard choices of which one to prioritize, and that really comes down to a culture thing. What is more important to you. Being secure or being competitive? And how do you weigh that? So, I thought that was actually very interesting, I think that we tend to give OpDev teams a bad rap but they're really doing the best they can and they need clear guidance and there needs to be a security culture for them to operate in. >> Right, that's a really big one that you just hit on, that cultural impact. It's hard to change. In the last 18 months, we've all been through so much change, personally and professionally. We've seen this massive acceleration in digital transformation, so probably more pressure on developers who need to be able to be productive from work, from anywhere environments, that that cultural change, is really critical. I'm curious if you have some feedback from customers that have done it successfully or are in the process of doing it successfully that you can share? >> Yeah, change is hard, no matter where it's at. Absolutely. So, I think, like where we've seen the most successful of our customers, around this specifically, it truly is both a top-down and bottom-up approach. From a top-down, you can't just give lip-service that application security is important. You can't just say, "Oh, again from a compliance check-the-box, point-of-view, we scan, and we're looking, and, oh look, we have these statistics. You have to really have to live it. And what I mean by that is, when you're developing new applications it's just as important as the feature list. Security bugs are just as important as any other type of bugs. So again, it goes into the workflow of the application development teams and you don't make them make these hard trade-offs all the time between security and release. And then, from the bottom-up, again, you need to be where your teams are at. You can't ask them to go into another tool, or another thing, or another this and that. They have things to do. You have to be where they are. And you, have to give targeted, actionable, not things they have to go research, a guidance, and automate as much as you can. Again, both on the scanning as well as on the remediation side. >> Meet them where they are and facilitate that automation. Susan, thank you so much for joining me today, talking about- >> My pleasure. >> How WhiteSource Software is helping that, and also for the challenge of saying auto-remediation 10 times in a row, fast. (Susan laughing) I might practice that later. But it's been great talking to you. >> That will be my home work. Likewise. >> Exactly! Thank you so much for joining me. >> My pleasure. >> This has been our coverage of the "AWS Startup Showcase", New Breakthroughs in DevOps, Data Analytics and Cloud Management tools. For Susan StClair, I'm Lisa Martin. Thanks for watching. (gentle music)

>>Welcome to this cube conversation which is part of our third Aws startup showcase of this year. I'm your host lisa martin and I'm pleased to welcome to the cube ceo and co founder of White Source Romney Sasse Rami, Welcome to the program. >>Thank you. Thank you so much for having me. >>I'm excited for our audience to hear about White Source, give us that high level overview of what the company is and what you how you're helping organizations. >>Sure. So we have software engineering teams keep track of their use of open source components sometimes referred to as dependencies and primarily focused on security aspect of those dependencies and are able to very natively and very quickly identify one all of the dependencies that are being used in a certain software that's being developed and alert to any known vulnerabilities that exist in those dependencies and then nick our users through the journey of finding them prioritizing them and fixing the vulnerability is such that their software when it gets released is not at risk, >>not at risk. And one of the things we've talked so much about In the last 18 months is the threat landscape. It's changed dramatically. We've seen a huge increase in ransom where huge increase in Ddos attacks. We also are in the fifth consecutive year of a cybersecurity skills gap. It's been there for a while. We know that there have been barriers between developers and security. How does White Source help address that cybersecurity skills gap. >>So we focus on automating as much of the security practices possible. Right. So basically our main premise is that we want to be the security expert for the engineering team so that they don't have to right? So we provide tools that automate the entire process of remediating the vulnerability so that we can save the developers effort and time in becoming security expert basically saying they don't need to become security expert, they can keep doing what they do best, which is developed software and provide more business value to their employer. And we will take care of anything that has to do with security in their software for them. So basically we're trying to alleviate the need for developers to develop any kind of security related skill set. >>I got to ask you how does that address? We talked about the skills gap but also the cultural shift required for developers to then kind of exhale and and put their trust in you guys and that's a big challenge to change cultures within organizations. How do you help influence that? >>Sure. So look, when you're talking about cultural shift, it always takes time. Like these things do not happen overnight And its gradual and so we are very well aware of it and we do not expect people to have 100% confidence in us immediately in day one. Okay, so our tools and and practices account for it and we help our users uh increasingly trust us more by proving ourselves to them by first starting with providing advice and allowing them to control the pace at which they automate more of the process. Right? So initially we will just tell them what they need to do and let them do it themselves until they are, they have gained enough experience without tools to just allow us to take the full cycle for them. That's one which maybe is even more important is that we rely very heavily on crowd sourcing, Right? So we have a very extensive customer base that is made up of some of the world's leading enterprise organizations that have very complex and a large environments and across those environments, combined with our ongoing and monitoring of everything that's going on in the large world of open source projects, we have compiled a very extensive crowd source database or knowledge base, if you will, that basically gives you intel on what others are doing with those vulnerable open stores dependencies, Right? And we can give you a lot of confidence when we see that the broader community of both commercial and free opens those users have upgraded a vulnerable dependency to a safe version and are speaking to the new version, right? They're not pulling it back there, not undoing that change. And so we give you a lot of visibility into all of that information and also, you know, when when things go bad, right? If we see that many people roll back some change and uh avoiding some dependency version, then we will warn you away from upgrading that version. So I think that the fact that we are establishing our recommendations on a lot of crowd sourced data is another way for us to provide more confidence, automating actions for our users. >>The C word confidence is absolutely critical. I got to ask you though Romney, something that you you mentioned, I was always, I always like to ask start ups, you know, what was the impetus to start the company? You're the Ceo and co founder? What were some of the gaps that were missing? Was it crowdsourcing? And was it the the lack of that community to really provide that visibility to developers that you guys saw as an opportunity to fix in the market? >>Alright. So at the risk of exposing my real age, Uh tell you that the company started over 10 years ago and was actually based on previous experience that as founders had in another company when when it was time to sell it. Right? So when we sold our previous company, we had to go through a two diligence process where we were required to provide a very detailed report of all the open source dependencies that we were using and we didn't have such a report and sort of caught us off guard and we had to spend a lot of time during, you know, the most stressful part of the due diligence, finding out which open source we were using and documenting it and coming up with the report. And so that was a very personal experience we had, but it was very obvious that it's not something that we did special. Right? Everyone is developing software is relying very heavily on open source and usually doesn't track it everywhere. Soon it initially started from just the very basic need for transparency, visibility and the ability to provide a, you know, simple bill of material that's now become a big thing right around S bahn Uh, but 10 years ago it was very difficult, it was very like manually laborious task to be able to come up with your bill of material and that's sort of the experience that big. Uh, the foundation of white suits >>got it and then talk to me about your relationship with AWS and mentioned in the beginning of this segment that this is part of our third AWS startup showcase of the year. Give us an overview of your relationship with AWS from a technology partnership perspective cells marketing product. >>Sure. So we've been working with us for a very long time and they are a wonderful partner to work with. It started right at the beginning where we are a cloud native company. Right? So we're staff solution provider and from the beginning we chose aws to be the infrastructure on which to no solution and we grew together with them over time over the last 10 years. We've been scaling again and again our environment and you know, the services that we provide and have been consuming more and more on AWS services, both for infrastructure and but also and very importantly for securing our runtime environment, which they do a great job at. But then it went even further and we are now integrated with a lot of AWS services and products and technologies. So our offering is very much integrated with several AWS offerings. And even beyond that, we are working closely as they go to market partner with AWS. So we have several co marketing initiatives with them and we are part of the startup coastal program. Such that AWS sales people can coastal white source to their customers. >>I imagine that is an advantage the partnership and the deep relationship that you have with a W. S in terms of getting those customers meetings and and helping them achieve the confidence in the technologies and the power of the two companies in 10 years. We're looking at 1000 customers and some big names. I saw from your website Microsoft Comcast, uh, Splunk 23% of the Fortune 100. Tell me how the aws partnership helps you give those developers the confidence that they need to trust in your technologies. >>Sure. So, first I think the synergy is very apparent, very obvious because both AWS and us sell to the engineering departments into the devil's people. All right. So we are catering to the same users the same customers the same, even decision makers. And so it's very easy to understand. It's also very easy to tell the better together story. Right? So, it's very easy for the the the THE AWS sales people to explain to their customers why it's easily integrate Herbal and it makes the sales motion easier and transparent and fluid and it makes the customer's consumption of the joint services easier. Right? So it's for them, it's easier to work with AWS is a window knowing that they can get all these added security features from them and gained the confidence of having this solution vetted by amazon and get us as a reference for us as a vendor also makes it easier for them to trust us and to use our services uh, with peace of life. >>Sounds like a synergistic cultures as well. I want to dig into something that I saw in the notes that you guys provided that white sources enabling organizations to eliminate up to 85% of security alerts. That's a big number. How do you do that? >>Okay. First, to clarify, we're talking about open source vulnerability or its rights are not in general. Not all security for open source security alliance. We've developed a deeper analysis that goes beyond just looking at your bill of material and identifying which dependencies are vulnerable and analyzes the way in which the developers are using those dependencies and what we've found over the last three years of running that technology with real customers? over many tens of thousands of development projects. Is that on average, 85% of the vulnerabilities in open source dependencies. I'll not reachable from your code. All right. So they are still there. You're still using the dependency but you're using some other function of it, which is not vulnerable. And the vulnerable function is never actively called in your code base. So this is like very specific. It's not some generic analysis. We had to analyze your code and figure that out. And so again, the average statistics statistics, is That just 15% of vulnerabilities are quote unquote, reachable form your code and makes your software vulnerable. Right? All the others are simply not exploitable. And so it can easily be eliminated for the need to remediate. Right? So you don't have to >>got it. How are you guys helping customers? There's been a lot of data that shows companies are spending millions uh annually using multiple web app and a P. I. Security tools on average but are still having problems with those tools being effective. How does white source help customers not waste time and resources and get right to being able to identify and remediate those vulnerabilities >>short. So look again in our philosophy, is that just detecting the problem? The security issues doesn't fix anything. Right. Doesn't help you solve your problem. Right, paramount to going to visit your dentist and having them find the cavity and maybe they do an x ray and they tell you exactly which tooth it's on and how deep it is. And then just send you home and you did you need to deal with it yourself. Right? So it doesn't really solve the problem. Your your mouth still painful. You have to fix the problem in order to get any kind of value for the security service of tool, you have to, you know, close the loop, finish the process and fix the vulnerability. And so by investing a lot in automating the remediation in enabling our tools to close that cycle right to finish the job and fix the vulnerability. We enable you to actually gain the value from the various tools that you're using and make sure that your software is not exposed and not vulnerable and not just give you a report with the vulnerabilities, right? Not just find them for you. >>Got It. Last question for you is if we look at your recommendations when you're talking to customers, especially as I mentioned earlier in the conversation, the threat landscape has changed dramatically in the last 18 months when you're in customer conversations, how do you advise them to start? You start with the developers. Do you start with security or do you start by saying you've got to bring everybody together. >>So we would normally start with security uh and you know, not necessarily the developers themselves, but the engineering managers. The heads of engineering again because our main effort is to leave the developers alone. Right. We want to get as little developer involvement as possible so that they can be free to do what they need to do. Security is something they have to right? It's a sure it's not, it doesn't add business value, it just protects the business from being exposed to greater risk. And so our approach and our practice is to be a sort of exception based tool for developers and only get them involved when you absolutely have to have them chime in and do something. Otherwise, we can fully take ownership and automate the entire process of identification, prioritization and remediation for the organization and just provide reports on, you know, how many vulnerabilities we fix this month and and give them better visibility into their security posture. Yeah, but you know, we invest most of our innovation attention resources as a company to automate as much of that process as possible so that the developers don't have to spend their time on security issues. We will do it for it. >>And I imagine developer productivity goes way up for your customers? I do have one more question for you, given that here we are in the fall of 2021, what are some of the things that you're looking forward to as we go into the new year? >>I love you in the new jewish year or then you >>Uh maybe both. I was thinking, you know, just as we go into 2020 to some of the things that you're excited about. >>Sure, so look, it's it's a little difficult to be happy about something that's a problem for other people, right? Because there is a growing threat for application security and there is more and more attacks going on in the world. But I'm really looking forward to helping more people be more protected while not wasting their time. All right. So it what drives me is the ability for us as a company to provide real value for customers and not be some shelf will not be a tool that just produces reports that no one knows what to do with. And the fact that we are able to steal our users and our customers away from risk and save them. The the hassle of being attacked, being hacked, having their data stolen or having the system broken into is what I mostly look >>and there's plenty of opportunities for you guys to do just that and really add that value for those developers And the company is like I said, big brands Microsoft Comcast block Romney, thank you for joining me on the program today, talking to us about white source and how you're really feeling the gaps in the cybersecurity skills landscape and helping really transform developer productivity where security is concerned. We appreciate your time. >>Thank you. Thank you so much for having me on the show. >>My pleasure for a missus I'm lisa martin. You're watching this cube conversation. Mhm mm mm.