DevOps Chat: Forrester Wave Leaders Discuss SCA
Forrester recently released its “Forrester Wave Software Composition Analysis SCA for Q2 2019,” highlighting the leaders in this fast-growing category. We had a chance to sit down with three of the companies highlighted in the Wave report to talk about why SCA is so important.
The term software composition analysis (SCA) may not be a familiar term to you. But SCA is what the analysts are calling the category of tools and process that look at the components that comprise up to 90% of code in our applications today. That’s right: up to 90%.
Most of these components are open source and are drawn down from repositories or GitHub projects. Because of the nature of open source, there are multiple versions of these components and the QA process prior to their release may not be as extensive. More frequently people just don’t update to the most recent version of a component because there is no “push” of the update.
Your organization is probably already using one of the tools in this Wave report. If not, you should look into it. Either way, this is a critical area.
Also, a word of caution: Like so many of these analyst reports, the leader may not be the right choice for you. There are factors that go into deciding the leaders in these reports that may result in the solutions at the top not being the right solution for you, so you should take them with a grain of salt.
That being said, congrats to all three of the companies we spoke with below in being in the report. Have a listen to what they have to say in this video, I think you will find it interesting.
Transcript
Alan Shimel: Hey everyone, this is Alan Shimel DevOps.com, MediaOps, Security Boulevard, Container Journal. Welcome to our video community discussion on software composition analysis or SCA. Not familiar with SCA you say? Don’t worry, you will be at the end of this conversation.
But before we start, I’m really happy that we have a truly all-star panel made up of some of the leaders in the software composition analysis field and I’m going to let them introduce themselves first to my right, Derek Weeks, Derek. Go ahead.
Derek Weeks: Hi, Alan. Thanks for inviting us. Always good to see you. Guys, I’m Derek Williams. I’m Vice President and DevOps advocate at some of the type. I’ve been with the company for five and a half years now. I’m the lead author around the “State of the Software Supply Chain Report” and our DevOps DevSecOps Community Survey, and also a co-founder of All-Day DevOps.
Shimel: Fantastic. Thanks, Derek. Next to Derek in your gallery view is David Habusha of WhiteSource. David, why don’t you introduce yourself.
David Habusha: Hi, Alan. Thanks for inviting me and happy to be here. David Habusha, VP of Product with WhiteSource. I’ve been with the company for two years and happy to discuss SCA with my colleagues.
Shimel: And these truly our colleagues, we don’t usually see this kind of mix, David. Thanks for being with us. And then last but certainly not least, we have Patrick Kerry from Synopsys and Black Duck, folks. Patrick, welcome.
Patrick Carey: Hi, Alan. And thank you for inviting me. Yes, my name is Patrick Carey, I am head of product marketing for Synopsys, formally head of product marketing for Black Duck, which I joined back in 2015 and I and my team are responsible for the marketing of Black Duck and the production of our open source security and risk analysis report.
Shimel: Fantastic. And thanks for joining us, Patrick. So guys, what brings us together today. As I mentioned before, was software composition analysis or SCA. What I, you know, and kind of the catalyst is this morning we saw the release. Well, I think it’s the first The Forrester wave. It’s the First Wave on software composition analysis for 2019 and I’m hoping at this point all three of you got a chance to take a look at it.
Yeah, yeah. Good. So, you know, there’s let’s let’s start off with the general level, and talk about software composition analysis. You know, I am thrilled frankly that finally at the one of the larger analyst firms, the industry as a whole has given a name to what it is. You guys really excel at, and more importantly, has recognized the fact that most of today’s applications and software are made up of components largely made up of components and those components are largely open source. So in some ways, it’s got to be a sweet validation for all three of you let you know interested in your take, Derek.
Weeks: Now, well, certainly when I got into some type and perhaps when Patrick got into Black Duck, the market wasn’t big enough for analysts to cover it. So you’re right. You know, seeing Forrester or seeing Gartner or 451 and others cover component analysis and actually cover it within kind of how they categorize markets, I think is important. An important validation for this software composition analysis has gotten a lot of headlines over the past couple of years since the Equifax breach. But I think, like you said, it’s really driven by what our customers are doing in their development teams using open source components across their, their development life cycle, whether that’s open source components or containers. And the more that they use those, the more than they’re concerned about the quality and attributes of those. So I think this just, you know, it’s a reflection of what’s happening in the market.
You know, analysts don’t necessarily create markets, they just report on markets as they happen. And I think we’ve all done a good job at elevating the attention of this market and, you know, certainly it’s on the type serving our customers in the process.
Shimel: Absolutely. David, any thoughts on you know any attention to, you know, PR, good or bad, it’s still PR any intention here, no matter how you doing the wave is it’s a good thing. Your rising tide lifts all boats.
Habusha: Yeah. Agreed. Well, I much agree with Derek, looking at the sheer growth of the open source usage in the industry in the last few years. And it’s pretty much everywhere, even in financial Institutions we see governments using open source. And the growth in the number of security vulnerabilities associated with open source and the compliance issues associated with open source as well.
There’s definitely, it definitely generates a room or a whole market that needs to be covered by analysts and we’re very happy to have Forrester covering this market. And looking at the way modern customers actually accommodate with the use of open source, looking at things like automation remediation reporting policies is the right way to cover these types of solutions today.
Shimel: Excellent. Patrick, rather than repeating what the other two said, I can’t imagine you disagree, but you know what? Synopsys has been a player here for some time, and then of course with the Black Duck acquisition really kind of, you know, fortified, no pun intended for to find those your credentials in your capabilities. You know, there’s more to it, of course, than open source, though. Yeah.
Carey: Oh, absolutely. And you know Synopsys acquired Black Duck a little over a year ago now.
And with a recognition that open source was in modern applications could constitute as Forrester cites up to 90% of the the code base in a modern application. But certainly we see now a much broader perspective where customers are looking at open source vulnerabilities in particular in conjunction with vulnerabilities introduced through proprietary code or even through the way the application is configured in and deployed and we think the analysts are starting to recognize that as well and see software composition analysis as being, you know, a first-class citizen in the application security toolkit and we’re very happy to see them recognizing what we already saw in the market.
Shimel: I agree. You know, let me put my old guy hat on here for a second, right? I remember launching when I helped found StillSecure a product called BAM in 2002 which was a vulnerability access management and and you know it was all vulnerability management and then we sort of saw the cleaving of vulnerability management and penetration testing with things like ___________ and stuff like that, right, and and then when WhiteSource—excuse me—when WhiteHat Security came out with Jeremiah — Jeremiah Grossman launched it all those years ago. And we really kind of saw for the first time, SaaS-based appsec scanning, if you will, but you know, then over the years. Now we’ve seen DAST and SAST, you know, static and dynamic and everything else and it always was sort of nipping at the edges of this reality, which is, software today is component-based. Right. It’s very much—Derek, as I’ve seen you talk about the assembly line—not very different in some ways from an automobile assembly line where we have third-party parts that get assembled into your car.
It is a, I think it’s a high water — hopefully not a high watermark, but certainly a day to remember where we see a Wave on SCA. But guys, beyond just scanning the open — okay, so now we’ll scan open source components and tell you it’s old, it’s vulnerable, you need to update it, what have you. So what we’re looking at is just another scanner or where the value adds to these scanners, if you will. And I don’t even know if scanning is the right word, but you know the value-add beyond just scanning. Patrick, why don’t we let you go first. You went last, last time.
Carey: Sure. Um, so I think what we see happening at the same time that the, you know, it’s hard to say that open source is growing anymore. It’s grown, but this whole movement towards adoption of more automated development and deployment capabilities, DevOps, and the, you know, the so called shift-left movement, you know, one of the challenges with more of a legacy approach to application security testing, it is, it was very reactionary. It came at the end of the process and just at the rate that software is being developed today. Teams have recognized that they need to move that detection and prevention of vulnerabilities way to the left, even to the developer desktop.
So where we see kind of the frontier for this is in three areas. One is in integration, with the other development tools that teams are using. So IDEs, CI tools, repos. The automation of policies, so rather than go into an open source governance board you essentially set the ground rules upfront and you allow the automation systems to enforce those. And the enabling of the developer to make the right decisions upfront—you know, that’s the cheapest time to remediate is before vulnerable code even enters your code base. And so the confluence of those three things and helping sort of thin out, you know, a sea of vulnerabilities down to one of the ones you need to focus on are really where SCA is heading in the upcoming years.
Shimel: Interesting. David, comments, thoughts, to that?
Habusha: Yes, again much agree though, I believe that first open source or software composition analysis is not just another scanner. It’s a way to approach modern software development lifecycle, and as Patrick mentioned, shifting left these efforts is a key to success. And it’s being able to automatically put the security and quality gates as left as possible, but it’s also how do you prioritize the right vulnerabilities to look at, to actually make it a manageable process from the engineering side and help the relationships between the DevOps and security teams and the engineering teams by: First, allowing developers to use their own natural environments integrating into IDs and repos, as Patrick mentioned. And also, giving them much less vulnerabilities to examine, to make it a more streamlined process and to help the corporation. Now, it’s not only that, because you can also automate the remediation, not just the scanning. So with open source, there’s a lot of tools because you’re integrated into the pipeline to actually automate the remediation, and sometimes even by a single click, update to the latest non-vulnerable component or apply different techniques, that you cannot do actually with the SAST or DAST tools because you need to go through the whole process again. So open source, actually creates for the first time, not just the, you know, one time or periodic scanning, but a continuous environment where you can scan and fix vulnerabilities automatically and put these security gates automatically, so you can make them a clean and secure software easily.
Shimel: I don’t disagree. Derek thoughts?
Weeks: Yeah, you know, you mentioned, is it just another scanner? I think scanning is really just one part of it. And I think David and Patrick have, you know, talked about different aspects of that. But I think getting back to what you are saying, Alan, about, you know, this is basically representative of the use of open sources representative of software being, you know, akin to modern manufacturing, you’re using parts. And if you’re a development team, what you want to understand is, I’m using the latest parts, I’m using the best versions of those parts, I’m using the best part within a category of hundreds or thousands of open source parts that are similar, you know, in the market. I’m using the right licenses, and I think it’s really about taking information about what those best attributes are, of any part of your development organization is, and automating the governance of those, so you can have guard rails for your developers throughout their development life cycle and, you know, for years, I’ve reported on the state of the software supply chain. What–why this is really coming to bear isn’t just because we can do it, and we have this capability. But organizations are seeing our developers are downloading, you know, half a million open source components into our development lifecycle each year. In some cases, millions. I’ve seen as high as 16 or 17 million open source components consumed annually. And when you’re using all of these parts within a development practice, you can’t just say, “Hey, all parts are created equal.” You have to understand some have known vulnerabilities. You might be using 27 or, you know, 55 different versions of a part, well, why don’t you actually streamline your manufacturing and use the best version, or the best couple of versions of that; rather than having 55 different versions across your organization that your developers are trying to use or trying to integrate continuously. So it’s really about, you know, how do we increase the velocity of the manufacturing process, while keeping quality at the highest standard?
Shimel: But nevertheless, guys. We could say it’s not a scanner, and I get that it’s not a scanner, but some of the same issues that we had with scanning and vulnerabilities, kind of rear their head here, right? And you know, to you the Forrester folks, they do. They called out some of these in the report, things like speed of scanning versus false positives, right? Scalability of scanning, and then, here’s a really important–not that the other two aren’t important–but another really important thing is the ability to do something “actionable intelligence,” I call it, right? All right, you scan something and you’ve got a vulnerable open source component, how do I go about updating that? And that’s really important, as we talked about shifting left, and throwing this on to developers and so forth, right? How do we fix that? And it’s a problem. It’s a problem. Derek, I thought we lost you there, great to have you back. Patrick, I mean, what do you think Patrick?
Carey: Well, if you look at where SA evolved from, so when Black Duck really got into this, back in 2004, when the company was founded, the main problem was teams wanted to find every bit of open source in the code base to make sure that they weren’t violating–
Shimel: Licenses.
Carey: And so the, you know, the bias was towards identify every single piece of open source, just to eliminate that risk. Now, flash forward, you know, 15 years and open source uses have exploded. So now we have teams that have the opposite problem, where the amount of open source vulnerabilities that are surfaced, are too many to take care of all of them. So they want help in prioritizing and reducing the time to remediation. And unfortunately, you know the the gold standard for the longest time has been a national vulnerability database. And it’s, it’s still probably the single, most common resource that the teams use. But if you look at the records in the MVD, for developers it’s really sort of hit and miss. The records may not be completed in a timely manner, relative to one the vulnerability is disclosed, and even then, the guidance in there could be fairly cryptic. And so, this is another area where products like ours, and the others on this panel are working on, is to enhance the vulnerability data that is in the NBD, to help identify PAT, optimal past remediation, whether that’s which component to upgrade to, evidence of attack or evidence of compromise, things that help teams prioritize and shorten that race that they’re in, between when a vulnerability is publicly disclosed, and when they find it and fix it in our code base.
Shimel: Fair enough. David, false positive speed of scanning, how important is that to a white hat?
Habusha: WhiteSource. I think it’s important–
Shimel: WhiteSource, excuse me. I apologize.
Habusha: Yeah, it’s very important. I just want to touch on one point. Again, you know, bringing back the discussion of having a mere of, kind of just a scanner. So, open source is different from proprietary code in the sense that, even if you scan the code and nothing has changed, a new vulnerability may affect your existing applications. And with open source, the detection is very accurate because the open source components are uniquely identified, so you are able to alert and remediate on new vulnerabilities that affect existing applications. So that’s something that just a scatter doesn’t cover. But when it comes to false positives and the scalability of scans, we’re talking about customers today who may run thousands of builds per day, and you need to scan your code with every build. So you have to have a system in place that quickly scans–they don’t go beyond like two or three minutes scan time because otherwise they’ll break the CI/CD processes or the build time–you have to have a very accurate set of results, with little false positives as possible, but with open source you can actually be 100% correct because these are known open source components. And then you have to adapt into these type of velocity, into these types of loads, when running so many builds a day. So, this is very important in the modern environment where you want to fit in to the modern software development lifecycle, being able to scan hundreds or thousands of times a day and reporting only on the things that have changed and really matter, with regards to vulnerabilities, license and quality.
Shimel: Fair enough. Derek, you know, in the wave report actually, Sonatype was cited for having low false positives, and commendable, you know, how important, how much weight should that have? I’m going to assume you’re going to say a lot, but, you know.
Weeks: Yeah, well–
Shimel: Seriously, how important is that?
Weeks: It, you know, the thing that we’ve been focused on, ever since we’ve been in business, is what do our customers need? And what they need is accurate, actionable information. And, you know, to kind of bring it to light, I’m sitting with a customer–Broadridge Financial–a couple of weeks ago, and they had an internal DevOps day. And the development team is sitting around talking about different security practices that they have, and one of these is that they have a static analysis tool within their environment. And the developers are going, “Man, like, we’re using this and it’s delivering all this information and it’s noise, like, I’m getting pages and pages of information from the static analysis tool. How do I act upon it?” And I said, “You know, quite honestly, you guys are a development team. You’re using a tool that was built for security teams, and that’s never going to give you the kind of answer that you need. What _____, you know, fast information, accurate information with low noise, actionable information, so that you know, if this thing is bad, what’s the good thing and how quickly can I move to it, right?” So it’s not–you know, when you say scanning, I think that’s–it gets an adverse reaction from us, because that kind of positions–this is, you know, this is another security tool and another security chain, but this is really about your developers are using something, and you want to know, as a developer, am I using the best parts or the worst parts? Right? And yes, security plays a role in what the best or worst attributes are, but they’re just one party at the table. And I think if you’re a developer, you want information that’s coming at you that you can say, “If I’m going to work on this, it better be a problem. I don’t want a false alarm coming up, that lends me down a path that says, ‘Look, I have a two week sprint that I need to finish, or we’re doing commits continuously throughout the day.” So it is important for the customers that we have–and I’m sure everyone here–that the outcomes that you’re really getting at is, I have feedback loops that are quick, I have feedback loops in my DevOps pipeline that are actionable, and I’m not sitting on a wild goose chase going down chasing false positives, you know, that are just a waste of my time. Right? I think security people in apps like tool _____ you know, they’re used to like, “Show me everything that, you know, is wrong with this, or potentially wrong with this, and I’m fine if you give me 12 pages of report, of what’s going on.” If you’re a developer, that’s the last thing that you want. You want to know there are two things really wrong with this, and by the way, they’re wrong and here’s, you know, the right thing that you can do immediately and to surface that as quickly as possible, and in some cases if you can automate the remediation of that, even better for the developer.
Shimel: Sure. So David, it brings up a–you know Derek’s point is valid–it brings up an interesting situation. Who is your customer, the developer, the security team or both? And if it’s both, can you serve two masters?
Habusha: Yeah, that’s, that’s a really important point, and our customers are both and you have to cater both. The security teams, from a management perspective, you have to give them the tools, and dashboards, and decision making systems, and policy enforcement and reporting. While to actually cooperate with the development teams, you have to provide the developers with tools that integrate into their normal day-to-day development environment that, as Derek mentioned, only focus on what matters on the very few vulnerabilities that make the difference. The high severity ones, the higher–the ones that actually impact your applications that will be called from your app. And then you have to integrate into their IDEs, into the repositories and give them the actionable information about the essence of the vulnerability, how to fix it and also the automated tools to actually fix them as soon as possible, so they’ll be able to build the software again and to ship it free of security vulnerabilities for the next version of the software. And the friction today, and I know that it’s something that is kind of repeating between the security teams and the development teams, as Derek mentioned, developers don’t really like resolving security issues. So you will be better off giving them just a small number of vulnerabilities that really matter in their own environment, in their own tools, so they’ll cooperate and they’ll resolve that as quickly as possible. So they are your–they are our users as well. But in the sense of the tools that need to cater to the developer community, these are different tools. These are more integrated into their environment. So, security teams set the policies, the reporting, they look at trends and they’ll be able to report to their management, while the development team actually resolves the issues in their own natural environment.
Shimel: Excellent. Patrick, I know what the history of Black Duck. And look, I remember in 2004, Phil Odence was a good,still is, a good friend of mine. Right? Open Source licensing was kind of the reason for being. Well, with the, you know, merging into Synopsys, obviously, have a much bigger history and heritage of working security. How do you guys kind of balance, you know, serving both constituencies?
Carey: Well, yeah, and really for SCA, arguably, there’s three constituencies. Right? Because as you point out, back when software composition analysis was primary about license compliance, it was sort of a legal team, development team partnership. And so, I think from a security and development team standpoint, the organizations that we work with, we see a consistent acknowledgement, that often the push to add more security tools into the environment, it may be driven by security but security teams have recognized that they are now working in partnership with the development team. That they can’t actually be successful and deploying security tools today and having them work effectively, if they’re not the tools that the developers will use. And so, in many ways, SCA has been farther ahead in this capability for some time because it inherently was viewed more by developers as a tool that helped them select better components, identify if the components were poor quality. It sort of naturally fits in, in various stages of the SDLC–all the way from components selection at the developer desktop, through automated policy enforcement through CI processes, and as I think was mentioned previously, unlike a scanner, it’s relevant at the operations timeframe. Right? You know, an Equifax breach, that wasn’t a failure during the development cycle, that vulnerability hadn’t been discovered when the developers were writing that code and when it shipped, it was presumed secure. It was only after that code was in production, that that vulnerability was disclosed. And so, you know, for us, we see it’s just–it’s this natural evolution, I think all of the security tools are moving towards. So static analysis is moving much more into the desktop. And so the modern updates to SaaS are really focused on IDEs. DAST is morphing into interactive application security testing, something that can be automated through the CI process. And so for us, it doesn’t feel like so much of a contention, so much as a natural evolution that Dale, that we’re obviously working to try and support.
Shimel: Sure. So guys one more question I wanna–and then we’ll jump into the way findings, because we should mention it, as long as it’s coming up. But first, I want to discuss what I call the Equifax paradox, which is–and Derek, I think I learned this from your report last year at one of our DevSecOps Days, which is–you know, we all know Equifax would stretch to the vulnerable open source component, but yet, when we looked at the downloads of open source components, after the Equifax reach–
Weeks: Yeah
Shimel: –after, after we tell people, “Apache Struts, too, this component was vulnerable, this is, this is how it got in. Update, update! Get rid of–stop using vulnerable–” Forget the millions of other open source vulnerable components they’re using. They’re still using vulnerable versions of struts too. They’re still downloading it, slightly less than they did before– a thing, but not too much though. Is that–am I– Derek, if I’m lying, you know, I’m dying. But am I telling the truth?
Weeks: Yeah, I think it’s actually picked up a little more that downloads and vulnerable versions of struts are up, since the Equifax breach. I think the last report I saw from our Maven central repository is that we’re at something like 130,000 downloads a month across almost 9000 organizations. I think a couple of things come to light here. One is, you know, people mentioned Equifax and–you know, while we love them as a customer–they weren’t the only struts breach that happened. On the same days that Equifax was breached, we had the GMO payment gateway in Japan, we had Canada Revenue, we had Canada statistics, we had Japan Post, India Post, we had NDS social security system. They were all struts breaches within days or months after. So, Equifax was not the only one using a vulnerable version of struts, but I think it kind of gets to the point of–you know, what we were mentioning earlier about–look, developers are using open source components in massive, massive quantities for any organization out there. And I think that, you know, in the case of Equifax–as Patrick mentioned–it was safe when they were starting to use it, it became vulnerable over time and when that happens, when a new vulnerability happens, you have to ask yourself two questions: Did I ever used that component? And if I did, where is it? So when open SSL, you know–and hardly to happen–when struts happen, when bash, and poodle and all these other things happen, you need to answer those questions quickly. And if you can’t, if you don’t understand what you’ve used and where it is, it’s nearly impossible to remediate it in a timely fashion. And we’ve seen that, you know, it used to be the time between a vulnerability being disclosed and the exploits appearing in the wild was 45 days, a decade ago. In most cases, it’s around 24 to 72 hours now, before exploits are appearing in the wild, and in some cases the exploits are being built into the open source projects by adversaries and shipped out. We just saw this last week with Bootstrap-Sass, someone created a version of that open source project that had a backdoor in it, put it in the RubyGems repository and people started to download this. I think they had 1,400 downloads or something, from a project that has 28 million downloads. So there are adversaries out there, impacting the validity of the software supply chains out there. And so, if you don’t that–you know, as much as we can scan and remediate and integrate into developer tools, you know, if someone’s out there saying, “Gosh, I need to get started. Like, what do I need to do?” If you can’t identify what you’ve used and where that is, in production or in development, you can start to do any of the other stuff. Right?
Shimel: Yeah, and you know what? That’s back to Patrick’s point about the initial, you know, Black Duck push, which was, let’s just identify what open source you have and whether you use, you know, then decide what your license compliances are, or whether or not they’re vulnerable is another story. David, what about, what do you, what can we do David? Is automatic remediation the answer? Right? Or automated remediation? I see an outdated strikes, I replace it. Automatically. Is that the answer? Will people go for that? What do you think?
Habusha: I think that’s a key to successful security hygiene of modern apps. But I think that it also relies on the maturity level of processes, in the different organizations. If they care about enforcing compliance as early as possible in the process, if they break built in case of a security vulnerability–and usually they don’t do that because, again, relationships between developers and security teams, so they just alert on the vulnerability and they don’t really break that–or if they find a new vulnerability, they generate an automated pull request, for example, that enforces the developer to take an immediate action, then yes. Automated remediation may resolve these issues, but customers need to acknowledge that the risk of automatically updating components with regards to backwards compatibility and automated testing is still, I mean, it’s still better to do that, than to take the risk of being in the attack window where the vulnerability has been disclosed, but you don’t have any remediation here. So, yes. You should automatically remediate your vulnerabilities. Try to do it as early as possible in the process, and depending on the maturity level, try to enforce compliance as early as possible. And in the operational aspect, when a new vulnerability is discovered–and as my colleagues mentioned–you know which applications are affected, and they, it may end up doing that on the container level, it may end up doing that on the server or VM level; then take the immediate remediation advice, test your application and roll it up to production as soon as possible.
Shimel: Fair enough. So guys, I know we’re over time but I think this was an important discussion to have. Let’s quickly kind of talk about the Forrester wave finding results. And before we do that, I want to relate to a story–my own personal experience–you know, back in my still security days it’s still–Gartner, he’s put out the Magic Quadrant. I wanna say it was for intrusion detection or intrusion prevention at the time. And I remember being in a meeting with the, it was the Navy Marine Corps Intranet (NMCI) and I got into a bit of a heated discussion with a Marine. No surprise there. And, you know, his analysis was that with the Gartner Magic Quadrant, all that mattered was the top upper right–upper right quadrant; that if you were in the challenges or the up in commerce, whether, if you are in any of the other quadrants, you were no good. And it was only the top upper right and only the one in the upper right, that such a proud institution as the United States Marines would be associated with. And, you know, I had to explain to him that that’s not even what Gartner says. So when we, when we look at the Forrester wave. When we look at the Forrester wave, we find things here. We should absolutely, you know, take that with a grain of salt. So that being said though, I’m gonna put up here right now–I’m assuming you guys can see–and then, and again, a picture is not worth a thousand words in this point because you really–and I encourage everyone listening and watching this–go read the full report, I think it’s publicly available today. Because they have, you know, caveats, and all kinds of footnotes, and with each of the companies ________ here, and no matter where a company shows up on this wave reports that you’re looking, there are strengths and weaknesses to each of them. But obviously, congratulations to WhiteSource, Synopsys, in the leaders track or wave section. Derek, you guys, there’s clearly strong performers and also when you look at the size of the circle, it’s how many–how big you are, or what your presence and market is. So congratulations to that, but I’m gonna ask each of you to kind of–and again, not here to bad mouth Forrest or anybody else, but, you know–how do you relate or what do you attribute the findings here in the wave? And I’m gonna give you a chance to agree or disagree, with some of the findings here that Forrester has put up.
Weeks: Yeah. So, I’ll go first. So one, we’re happy to be in the Final Four. I think with the NCAA tournament going on right now, Final Four as a pretty good position, you know. And the other thing, I think Amy DeMartine, who led this at Forrester, I think did a good job at kind of figuring out what attributes were important to the market, understanding what we were doing at Sonatype, and the, you know, commenting on the very low positives, the remediation guidance, the integration into DevSecOps pipelines, or into developer pipelines, which in our case, are a lot of DevSecOps pipelines. I think it’s a, I think it’s an important evaluation of the market. I think she got the top four right here–sorry, my auto lights here on the, in the conference room just went off. But, I think the key thing to remember is at Forrester, you know, Amy is an app sec analyst. She’s not a DevOps analyst. And I think that, you know, when you talk to the DevOps analysts at Forrester, that one helped us create the total economic impact report talking to four of our customers, you know, seeing a 325% ROI over three years using our product, getting a payback and under three months. I think the, you know, when you talk to DevOps analysts out there as well as app sec analysts out there, I think you get buried positions. So, if you’re an abstract person following apps like news, then, you know, the findings in this report, maybe more weighted to you. I think if you’re a DevOps analyst or covering DevSecOps, then you’re going to have a different view of the market. But, I think the kind of key attributes that are discussed are some of the right ones to discuss in the market.
Shimel: Derek, I couldn’t agree more. And it’s funny, a firm like Forrester, well they do have DevOps analysts. I spoke, many times _________.
Weeks: Yeah, we speak to them all the time.
Shimel: That they wouldn’t have put them in there. But Patrick, we’ll work our way up. How about you?
Carey: Well, we generally think the other–this wave processes is a very good way to analyze the vendor space. And I think people who download and read the report, you know, Amy puts in a lot of thoughtful commentary on each of the vendors, on what their relative strengths and weaknesses are, and the tool that they provide to allow teams to wait the different scores based on their priorities. I think is really useful in a novel approach. You know, Amy, although she’s an app sec analyst, certainly is tuned into the needs of DevOps and automated development. And I think you see some of that reflected here also, in terms of the acknowledgement of the necessity to automate these processes and integrate them with the development lifecycle. You know, interestingly, you know, the three of us here on this panel–Sonatype, Synopsys and WhiteSource–although we overlap here in the space of SCA, we’re, you know, our overall organizational focuses are somewhat different. You know, Synopsys is a, you know, a full, you know, a full spectrum application security vendor, as you point out. So we’re looking at everything, from static analysis, to SCA, to DAS and professional services. And so, you know, we’re, our strengths tend to be more in the integration across those different realms and the integrations for us. You know, Sonatype has, it has slightly different focuses and works more in the pure DevOps space than WhiteSource, obviously. It’s focused on SCA, so I think it’s interesting, you know, to see, you know, that mix of vendors here and the different vendor focuses reflected here and this top four.
Shimel: Interesting. David, how about you?
Habusha: Oh, well, it’s a–it’s been a very interesting process to walk through this report. And we’re happy that the criteria that led to the scoring of the report that is based on the actual principles that we just discussed, which are enforcing compliance, remediating security issues, generating the right reports on time and also catering to both management and security personas. As well as the DevOps and the development teams, and providing the right tools to close the loop in that regards, starting from selecting the right components and then putting the right security gates, and forcing the policies and compliance. But more importantly, as a key to achieving the right ACA strategies, how you prioritize security vulnerabilities. So we’re very happy to be acknowledged as the vendor that actually provides the best tools to support all these use cases and cater to different personas, and as my colleagues mentioned, we are a pure player in this market. And definitely being where we are, and providing these types of tools, and catering to these people, probably generated these results and we’re happy for that. I think that if you read the detailed comparison and look at the strategy and the various components that led to it, you see the actual tools and services and processes that actually led to provide these types of results. And again, we’re happy for that.
Shimel: Excellent. Guys, we–I’m gonna stop sharing this now. We’re way over the time that I had asked you to donate (or participate in this) so I apologize. We’ll wrap it up with this. I’d like to give each of you a chance to kind of state your last, sort of, statements to leave with our listeners and viewers. Why don’t we start–Patrick, you went last to start, so why don’t you go first. I will go to David and then to Derek.
Carey: Okay, great. And thank you again for pulling together this panel. I think this has been an interesting discussion. So, we here at Synopsys have been focused for a long time on helping teams build secure, high quality software and building it faster. And you know, I think one of the key takeaways from this is, you know, the acknowledgement that SCA is now really a critical component for any application, development team and the application development process, any application development tool chain. And so, I give credit to Forrester to shining a light on this and helping teams–security and development–understand some of what they need to be looking for in vendors, and highlighting, you know, the vendors that are in the space and the good work that’s happening to help teams build secure software.
Shimel: Fantastic. David?
Habusha: Yeah. And again, thank you for inviting us. And very interesting, to be together with my colleagues, talking about the SDA market and I think the report actually reflects the trends in the market for automation, remediation and enforcing policies. If you just look at the number of vendors in the report, comparing to the 2017 report, we see that there’s a lot more vendors that made it into the report. And we know that there’s a lot more vendors that wanted to make it into the report, which did not make it due to certain limitations. So we see the market growing, and we see the acknowledgement in various vendors, from, not just the pure SCA play, but from other places like repositories, trying to get into the space. And we think that the work that has been done on this report, trying to really understand the right ingredients associated with an SCA solution, we’re very, kind of reflecting the market and the needs. And again appreciate being on this panel. Thanks.
Shimel: Thanks David. Derek?
Weeks: Yeah. So Alan, again, thanks for inviting us all and talking about SCA because I, you know, as much as we are all growing our businesses, I don’t think people were talking about SCA enough. If you look at how many open source components and containers are out there and how many organizations are managing those, I think we’re still in the very early innings of this market. I think some of that is even, you know, visible from the–do you have app SEC analysts covering this space? Do you have DevOps analysts covering this space? Do you have DevSecOps analysts covering this space? I think that, you know, analyst firms are still trying to figure out which silos this fits in or if they need to merge their own silos. I think that will continue to evolve over time, you know. But I think we’re really happy with where things are, because you know at a business like Sonatype. I’ve been here five and a half years, we’ve been growing 60% to 70% every year I’ve been at the company. We have a huge number of Fortune 2000 clients, including, you know, Equifax and Salesforce, and all these. And I think that, if people aren’t paying attention to the open source components that they’re using, they need to start looking at what they’re using and start evaluating solutions that can help them deliver a higher quality code faster; and include the development teams, the DevOps teams, the security teams, the architecture teams, the legal teams, into the solution that really, your play is toward, and caters toward all of them, and enables them to work together–and I think in new or higher velocity ways. And so I think, if you haven’t–if you’re listening to this and you haven’t–looked into this space, I think the time is well overdue and it’s time for all of us to, you know, step into this and take a good look at the different vendors and different offerings out there.
Shimel: Thank you, Derek. So guys, let me just wrap it up by saying that, number one, I think it’s really a red letter day, where we can really focus attention on SCA. And we can help educate people on what SCA is, why it’s important, why they need to get with the program; whether you buy into a wave report and/or have problems without, they, you know, tabulated, it’s another story. I think all of us are at least glad that they’re–someone’s looking at this, it’s important.
Secondly, really kudos to all three of you because let’s face it, you’re all competitors in this space. Though as Patrick said, you all have your own special sauce and other areas you play. We’re happy to provide sort of a neutral forum, where I can gather together, you know, people who I know in the industry and we can discuss it in this manner. So, thank you very much for participating. For folks out there listening to this, go grab the wave report, there is a ton of great information in there. More importantly, go look at what you’re doing with open source, right? What open source components have snuck in or have made their way into, you know, your applications? And what are you doing to monitor the licensing of them, you know, vulnerabilities of them, the security of them, the management of them? It’s too important to overlook. So David, Patrick, Derek, thank you very much for your time today. Thanks to all three of your companies. Thanks Jamie DeMartina, the Forrester folks for their wave. Would have been great to get Amy on here today with us, but I just wasn’t able to pull that one off. Next time. Anyway, until then, this is Alan Shimel for DevOps.com, Security Boulevard, Container Journal; thanking Derek from Sonatype, Patrick from Synopsys, David from WhiteSource, for being here today. Have a great day everyone.
Weeks, Carey, Habusha: Thanks Alan.
Shimel: Bye, bye.
