Interview: Wayne Jackson of Sonatype

In this interview, Jeff Williams interviews Wayne Jackson of Sonatype. They discuss the results from The 2014 Open Source Development Survey, where 3,300 surveyed developers gave their honest opinions on everything from third-party code to internal policies and procedures. Topics included the implications on continuous application security, compliance measures, and application security automation.

Or you can READ THE TEXT BELOW:

Jeff Williams: All right. Hi folks. I’m Jeff Williams, CTO of Contrast Security. I want to thank you for joining us for another episode of our security influencer interviewers. Our goal is to provide a series of brief and highly informative interviews with and for security professionals. The theme this year is discussions on the implications of continuous. Today we’re talking with Wayne Jackson, my friend and CEO of Sonatype. He is a race car driver, a mountain climber, and carpenter, among other things. Prior to Sonatype, Wayne was the CEO of Sourcefire and Riverbed Technologies. Wayne, thank you for joining us.

Wayne Jackson: My pleasure, and for the record, a former race car driver.

Jeff: Got it.

Wayne: I’m not allowed to do that anymore.

Jeff: That’s probably a different interview. Recently Sonatype, Contrast, and New Enterprise Associates sponsored the fourth annual state of open source and application security survey with participation from over 3,300 IT professionals globally. So the survey does what?

Wayne: What we’re hoping to do is tease out the state of maturity in the marketplace. What kind of practices are people and organizations employing hopefully to make their software better. Because we at Sonatype focus on the supply chain and how open source is really the underpinning of software development supply chain, we tend to focus on open source and how people are thinking about their use of open source.

Jeff: Right. So I took a look at the survey. It looks like the vast majority of application security practices are manual in nature. So how does that work with software getting faster with Agile and DevOps development and most organizations are doing this manual AppSec process. How does that work?

Wayne: Well it doesn’t to be candid, and it can’t. A typical organization that we see uses literally thousands of unique open source components every month and they’re complex as you know. They’re not atoms, they’re molecules, and they change all of the time. And so trying to lay a manual process on top of that kind of activity is just impossible.

And one of the interesting effects of attempts to govern that manually is you’re dooming the organization in one of two ways. Either you’re dooming the organization to be slow or if you’re really effective in that kind of governance and I think relatively no one is. But if they were, you’d be dooming people to use old code, because they would be waiting for the approval of new versions that fix old problems. So you layer all of that onto modern software development methods which are really agile with one week or two week build cycles, sure, then there is a fundamental misalignment.

Jeff: So is it possible to go fast and be secure?

Wayne: Only with automation.

Jeff: Yeah.

Wayne: And we spent a lot of time talking about that. I know you guys at Contrast are focused automation and making the security inspection process a continuous thing. As are we [Sonatype] with regard to managing your supply chain. Rather than having a bunch of humans sitting around a table deciding whether a given thing is acceptable, we encourage folks that are sitting around the table to find the attributes of acceptability and then let machines make pass, fail decisions.

Jeff: So I’m glad you mentioned that, because I think that a lot of people see automation as just putting tools in place and then the tools do whatever the tools do. But what you point out by saying focused on what attributes of open source do you care about, you’re actually talking about a policy decision, that then you use the tool infrastructure to automate. Is that fair?

Wayne: Yes. Exactly. And doing it in a way that’s transparent to the people that are affective by it, the developers because having something rejected in the abstract isn’t all that helpful to people that are charged with making decisions.

Jeff: I’m just fascinated by that policy decision, because in a lot of organizations I work with, I see them just basically adopt the tool and run it without configuring it. They don’t think about the step of working out what their policy ought to be and then enforcing it with the tools. Rather they just make their policy whatever the tool does out of the box.

Wayne: Yes, that’s very sad. And you look at network technologies; a big part of my background is in that area. PCI came up with this brilliant idea to say you can either build better software or you can implement a web app firewall. And then so people said hey, you know what, I’ll bet buying a box is a lot easier than actually making better software, and so they brought these WAFs. And so they have to be configured if they are going to do anything really, and people don’t, to your point.

Jeff: Exactly.

Wayne: Okay, check the box. We’re PCI compliant. We’re not any better, but we’re PCI compliant.

Jeff: Right. Okay, let’s get back to this survey. Another finding in the survey which said that only 56% of the survey participants said their organization have an open source policy in place. Surprising?

Wayne: It’s actually relatively consistent with prior years which is a little disappointing, especially given HeartBleed, and Struts, and things that are materializing in very meaningful ways.

Jeff: But it’s better than half.

Wayne: At least some people are paying attention. The bigger concern that I have isn’t whether they have policies, it’s whether they have policies and practices that actually move the needle. That’s the bigger concern that I have.

Jeff: Yeah, I think you’re right. There are a lot of organizations that just have a policy on the shelf but because it’s not automated, it’s not actually making any difference in the field.

Wayne: And you see some crazy behaviors when those policies are put into place. We were at a major global bank recently, and they were doing an analysis of how effective their policies were, and they found the developers who needed a thing were renaming that thing to match something that was on a white list so that they would be compliant with their policy.

Jeff: Wow. In the survey it says that 63% of companies don’t track vulnerabilities over time. So a library that has a vulnerability one day and then the next day vulnerability gets released, 63% of the companies are not going to notice that. So what does that say about the process that companies are following here?

Wayne: You know, I think it reflects a general immaturity. And a mistaken... I’m going to kick a hornet’s nest here... but a mistaken assumption that open source is just okay.

Jeff: Until someone proves it to be insecure, right?

Wayne: There are those unfortunate events. Yeah, but I mean the problem with open source is that it’s software just like any software. And I’m not going to kick which is the better commercial or open source debate, but there are some things missing in the open source eco system that we take for granted in commercial relationships. If I’m Microsoft, who is notorious historically for writing really bad software, at least I have a relationship with you. And so if I find something, and I fix something I can tell you. It’s sort of the equivalent of an auto recall.

But open source is more like building kit cars, right? You have a lot of flexibility. You can leverage huge amounts of innovation, but there isn’t that relationship with the supplier and so that puts the burden on you to lean forward and actively monitor that entire eco system which is really, really hard.

Jeff: And you have to do it continuously, right? I mean these vulnerabilities are rolling out every week lately it seems.

Wayne: Well, in one of the things, yes to your point, but one of the interesting things that we’re seeing in open source is that once a vulnerability is finally discovered then all of the sudden, there is real scrutiny not just sort of "are the features there" scrutiny. And so, since the Struts issue last July, we’ve seen almost as many vulnerabilities discoveries over the last nine months as we saw in the years before.

Jeff: Interesting. So you think that’s like someone staring up at the roof or something? Like everybody starts looking in the same place? Because they are like oh, Struts is vulnerable. I’m going to pile on?

Wayne: Basically, yes.

Jeff: Interesting.

Wayne: Well as you know, and for what it’s worth, the Struts project, I think is done a really laudable job in dealing with issues that have been surfaced over the last year. And so they deserve a lot of credit. But as you know, auditing software, finding security defects, is really hard. There are, I don’t know what the number is, a thousand people in the world that are really good at it. And so in the context of hundreds of thousands of projects, it’s just really hard to find the scrutiny necessary to uncover these things.

Jeff: Sure. Is there a way to tell the difference between the open source projects that are basically doing good security stuff and then open source projects that aren’t, like the two guys in the garage that don't know anything about security?

Wayne: So we’re doing a lot of work in that regard. I’m not quite ready to talk about it yet, because we’re still making sure that the data is all good, and clean, and sound. But yes, we think that there are. One of the things that we encourage folks in the commercial realm to do is to think about the dependencies and their projects, to understand their attributes whether, for example, they’re security defects and if they are, replace them with something better.

And some of that might be technical data. It might not be relevant, but why use something that is known to be bad when an alternative is easily available. And so the study is really about, okay, we’ve made those recommendations for a commercial user open source. How about open users of open source? How are they managing their dependencies?

Jeff: Fascinating.

Wayne: And so that’s the work that we are doing now.

Jeff: Yeah. I love the fact that you guys [Sonatype] have access to so much data about the open source community and open source usage, and component usage, and all of that. It’s a fascinating way to study the problem, that scale that you couldn’t probably do within a single organization. So getting back to the survey, were there other things in the survey you found surprising?

Wayne: Well, we have been doing the survey for a few years, and I suppose one of the things that I found surprising, especially in the context of Struts given how many folks are affected by it, that there weren’t dramatic shifts toward better practices. We’ve seen steady improvement, but not sort of a sea change.

I think that part of that, sort of getting back to the open source and their best practices run dependency usage, a part of it is that we, as an industry, have to have solutions. We can’t just point out problems, right? Struts had a defect, okay. How to I remediate that? Struts is widely proliferated in your organization. Go find it.

Jeff: Right.

Wayne: And so to the extent that we do surface issues and I know you do, too, really want to provide answers that are actionable.

Jeff: Yeah. I definitely agree. In fact I am more and more convinced that the only real approach that works with application security is pushing those activities into the development groups and having the development groups be able to do them themselves.

But one thing that was in the survey that surprised me was there was a 10% increase, from 40 to 50% in the number of organization that are reporting that the application security group was responsible for these library component and security issues. Now I’m wondering whether you think that’s a good thing or a bad thing that the AppSec-centralized team is being responsible for this rather than the development teams themselves?

Wayne: You know I think it’s an interesting leading indicator. I think what that said to me was that okay, people are starting to take application security more seriously, and they are making better software, and the place where that happens today is in these cloistered groups. And so in some ways I think it’s a good thing, because it’s taking on a greater level of importance, but I don’t think that’s ever going to really work, because to your point earlier, with the rise of agile and the pace of agile, there is just a fundamental misalignment with the group that’s designed to automate things periodically.

Jeff: Designed as a bottleneck?

Wayne: Yeah. So you wind up with these huge tensions where the software development guys are tasked with glittering features really quickly and the security group is designed to slow that down so that the output is more secured, and they wind up thinking both are enemies rather than allies in the whole process. So what I think is going to happen, what I hope happens and technologies like yours [Contrast] are going to help happen, is that emphasis starts to shift left. And a part of enabling that is making the tools simpler enough that it can move left.

Jeff: Yeah, so what I was thinking is maybe the way this evolves is that the security group stays as a centralized team. I think that there is real advantages to that, having folks that are really good at threat monitoring and really good at monitoring threat intelligence and things like that. But they can use the technology to automate those policies we talked about earlier and enable the development teams to basically do it for themselves along with this automation. We'll see. I think that there is a lot of room for experimentation and growth in this space, because it’s early.

Wayne: Agreed. Yeah, I, and again to your point, I’m not diminishing the expertise that resides in some of those groups and there need to be strategic and thought leaders around security policy. But concentrating in those groups, expertise required to actually operate a tool to me implies that the tools just aren’t right.

Jeff: Yeah, I think that’s a fair point. Well, we’re both trying to fix that problem. Wayne, thank you very much for the survey. I think it’s a tremendous service to the community to try to gather this data and bring it to light. I think it’s incredibly informative, and thank you for the interview today.

Wayne: My pleasure and I really appreciate your participation.

Jeff:    Thanks and so the conversation will continue online. We’d enjoy hearing your thoughts on today’s discussion and any ideas for future security topics you’d like to hear about. You can find and subscribe to the whole series at www.contrastsecurity.com. I look forward to hearing from you.