News Stay informed about the latest enterprise technology news and product updates.

Chris Wysopal reveals new ways to monitor open source code security

Companies have long grappled with open source code security concerns and the risks associated with third-party components and software libraries. Enterprise developers often use prebuilt components and frameworks to save time and avoid writing customized code, but vulnerabilities increase security risks. This is especially true for commonly used frameworks, libraries and components.

With some enterprise applications, as much as 80% to 90% of the code is based on open source components, according Chris Wysopal, co-founder and chief technology officer of Burlington, Massachusetts-based Veracode Inc. In these scenarios, the majority of the application security risk comes from third-party components, which have been used by enterprise developers for years, and in some cases, without anyone checking for current vulnerabilities.

"Because of that risk that's grown over time -- and it has gotten to the point that it is in the OWASP 2013 Top 10 -- in your software-development process, you need to have a way of discovering all of the open source components that you are using, what versions are they and then looking to see if there are any known vulnerabilities out there," Wysopal said. "We call this software composition analysis and now I'm recommending that everyone should be using this as part of their SDLC [software development lifecycle]."

In an interview with SearchSecurity at the 2014 RSA Conference, Wysopal discussed how organizations can figure out where third-party components are and search for unknown risks. New tools can be run against build systems and software repositories to help find vulnerable points and inspect binary code.

What policies and procedures should be in place to enforce better application security for third-party code? In addition to software composition analysis before organizations put code into production, finding Web applications and either decommissioning them or fixing potential security holes -- especially after mergers and acquisitions -- is critical to enterprise security in today's complex environments.

Below is a transcript of the video.

Kathleen Richards: Hi, I'm Kathleen Richards from Information Security magazine and Thanks for watching this video. Joining me today is Chris Wysopal, chief technology officer of Veracode. Chris, it's great to have you with us.

Chris Wysopal: It's great to be here.

Richards: What are some of the risks associated with third-party components?

Wysopal: Well, the way people develop apps today, getting them to market quicker with less resources, they're using more and more third- party components. We've looked at some apps, and 80 to 90% of the code is open source components, so the development team is really just stitching together these components and writing some of the business logic, the data flow, the workflow. But all the encryption, all the rendering of charts, sorting, it's all done by third-party components.

The majority of the risk in the application is actually coming from the third-party components today. This is recognized by OWASP. In the 2013 OWASP Top 10 they added a new risk, Top Ten risk, which is make sure you're not using open source components with no vulnerabilities in it. It seems like a no-brainer...

Richards: Right.

Wysopal: ...But it's shocking that people will pull an open source component when they start developing the project, say like five years ago, and then five years later they're still building with the same component that may have had vulnerabilities discovered over that five year period. Because of that risk that's grown over time, it's got to the point that it's in the OWASP Top 10.

Now, as part of your software development process, you need to have a way of discovering all the open source components you're using, what versions are they, and then looking to see if there's any known vulnerabilities out there. We call this software composition analysis.

Richards: Oh.

Wysopal: Now I'm recommending that everyone should be using this as part of their SDLC [software development lifecycle].

Richards: How can organizations figure out where these components are and monitor the unknown risks?

Wysopal: Our static analysis service, which looks for unknown vulnerabilities in the code you've written. We also do this software composition analysis. When you upload your code to us, your binaries, we will go through that and identify the open source components and we will look up in a database to tell you if there's a vulnerability.

There are other products out there that you can run as part of your build system on your source code repository that will inspect and find these components that have known vulnerabilities in them.

Richards: Okay. But you're not advising against internal use of open source products.

Wysopal: Absolutely not.

Richards: Okay.

Wysopal: I mean, this thing is today, most organizations, the way that they grow, the way that they give better service, the way they offer more functionality to their customers is to build applications, build technology. You do that faster if you leverage open source components. It's pretty much a requirement today to get to market with software to use open source components.

I would never say don't use them because you're going to be late to market if you don't use them. The thing is, know the risk in those open source components. As time goes on, don't forget that as you ship the software a year ago, you need to keep on top of the known vulnerabilities that may arise after your software ships. You have to continuously monitor into the future.

Richards: What policies and procedures should be in place to enforce better application security for externally sourced code?

Wysopal: There should be a gate before you put code into production, or if you're a software vendor before you ship code to your customer, that it meets a particular security policy, right? There should be certain testing done that's part of that release process to make sure it's acceptable.

One of those things now has to be to look at, do software composition analysis. To have a policy saying no, we're not going to ship any known vulnerabilities in the open source we're using. Typically a CISO would put that policy in place in his or her organization.

Richards: What trends do you see going forward?

Wysopal: A couple of things we're seeing is, one, of course is the software composition analysis. Another one is discovery of Web applications. What we found with a lot of our customers is that they have a lot of Web applications that have their brand on it. Customers are interacting with them, and they never went through any kind of security process, even if the company had a security process, to do security testing before they went online.

There are a few different reasons. One is, it's really easy for a business manager to have a website built. Say the marketing department could have a website built by an advertising agency, and it's done outside of a normal process that a company has for building and deploying applications, so the CISO doesn't even know about it.

Another way that these apps spring up is through acquisition. When a company acquires another company, they're acquiring a whole set of Web applications. What we've seen over the last few years is that the average large company has no idea what Web applications have its customers' data that has their brand on it.

To do this, what we've created is a discovery service which takes a list of IP ranges, IP space that the organization might control. It takes a list of all the domain names that the organization owns, and it can search through all this space and find the web applications that you didn't know about, and then you can decide what to do with them.

Actually, sometimes they get decommissioned because it's old. It's a company you acquired. It was an app they had five years ago. No one is using it anymore. Shut it down. That actually saves money. Sometimes we see people put a Web application firewall in front of them, and sometimes they'll actually fix the issue. That's something that we've seen a lot of growth around. It's just finding Web apps and doing quick fixes to them.

Richards: Okay. Is there anything that you're seeing with regard to mobile app security?

Wysopal: Absolutely. I think the first wave of mobile security was at the device level, sort of like how it was with desktops, right? You're running antivirus on there. Does the desktop have password enforcement, does it have password locking? That host- level stuff.

We saw the same thing come to mobile apps. Is there a password on the app? Can I wipe the device if it's lost? The device-level stuff. That's pretty easy to do, and I think most organizations have solved that through mobile device management, MDMs.

But now what we're seeing is after that, the next more serious problem is what's all the behavior happening in these mobile applications? Do these mobile applications access private data on the device and send it off the device, whether it's photos, things on the SD card. Is it your contact lists? Is it personally identifiable information, identifying you to a particular device ID?

These are all things that, obviously, people who want to track you, if it's the NSA or something, they're certainly doing that. But advertisers are doing it. People who are building apps are doing this to monetize their apps. They can sell this information to marketing companies. Obviously in a high security environment you don't want people tracking you and finding out all your personal info. So we're seeing that people want to know what the apps are doing, and not have apps that have risky behavior that they don't want.

That means you want to do behavioral analysis of the apps. Run the apps in a sandbox, see what they're doing, right? See what data is getting sent off that device. Where is it going? What kind of data is it?

By doing so, you can put a bunch of properties together for this app, and then you could have a policy which says for certain individuals we don't want apps that trap their contact list, for instance. We don't want apps that track their location. Then you could have a MDM enforce that policy and not allow devices to run those apps.

That's what we're seeing now as the mobile problem moves to the application layer.

Richards: Chris, this is great. Thanks so much for your time.

View All Videos