Sidestepping the Security Traps of Open Source

Software development relies heavily on open source code but that doesn’t mean dev teams should just copy it, paste it and forget it.

Open source code is the backbone of today’s most popular consumer and enterprise applications. According to a recent report from the Black Duck Center for Open Source Research & Innovation (COSRI), 96 percent of the applications the Center scanned last year contained open source code.

For developers, open source code is a boon: It saves hours of programming, giving them more time to innovate instead of getting bogged down building the basics. But all of the benefits come with a dose of risk: The COSRI reported that 67 percent of that code it scanned last year had vulnerabilities.

No company is immune. Consider the 2014 Heartbleed bug, a vulnerability in the OpenSSL software library that gave hackers access to sensitive information across thousands of web servers. Or take Equifax: The consumer credit reporting agency linked its recent data breach to a bug in the Apache Struts framework, an open source code repository that Equifax used to build its web applications.

But measuring, maintaining and improving open source code doesn’t just fall to developers. The entire technology team is responsible, starting with the chief technology officer, says Mel Llaguno, Open Source Solution Manager at software company Synopsys. That means not only investing in the right technology to help manage open source code use, but also working open source code debugging into a team’s day-to-day responsibilities.

“It comes down to awareness, and that responsibility falls on all levels of an organization,” Llaguno says.

The Need for Proactive Security

There’s nothing inherently unsafe about open source software. The main difference between open source code and vendor-purchased commercial code is that, for the latter, vendors maintain the code, release updates and catch flaws. With open source code, those responsibilities fall on a company’s technology team. As a result, most open source risks come from limited “code maturity.” In other words, the code isn’t actively monitored, edited or improved.

“[Limited maturity] is where organizations are falling down worldwide,” says Brian Carter, Director of Strategic Communications at COSRI.

Monitoring open source code is no easy feat, considering how deeply entrenched it is in our lives. The average app, for example, includes 147 unique open source components. The key to ensuring the healthy functioning of all of those components is staying ahead of bugs, errors and other problems that could eventually turn into security breaches.

Finding Security Flaws with Code Scanning Tools

Ensuring that open source code is performing the way it should requires different types of technology.

The right combination of tools depends on an organization’s budgets and specific needs. First, there’s software scanning technology, which parses existing code to identify open source use and flag potential problem areas. Developers can also use dependency graphs, which show the open source projects that the company’s code depends on, enabling them to identify defects and make improvements.

But companies can’t rely on scanning tools alone.

“The scan is a very good start, but it’s only a snapshot in time. Ten minutes after that scan, there might be a new vulnerability identified or a new license requirement,” says Carter.

Scans are also time-consuming and can slow agile development teams and disrupt the applications they build. Cloud applications depend on frequent, often automatic, updates, and running scans in the background could halt that process or cause errors.

To complement what scans offer, companies may want to consider also using cloud-based services that identify newly-added open source components and provide ongoing, on-the-fly protection. Available as plugins for software-building tools, these solutions work in the background to monitor the introduction of open source code and alert developers to any vulnerabilities.

.

.

Creating a Sense of Ownership

Although technology plays a central role in gauging and improving code maturity, it’s not enough. Developers should also have a stake in ensuring that open source code is functioning properly. But since no individual person or team owns open source code, it can be a challenge to get someone to take responsibility for the code’s health. Encouraging developers to own and oversee specific bits of open source code (also known as assigning code “commits” to developers) can make a significant difference, says Llaguno.

“The number of commits associated with particular developers, and the timeliness with which developers respond to bug reports—these are all things that make up the context of maturity,” he explains.

Beyond being vigilant about open source code within the organization, developers should also engage with the broader developer community of open source code users outside of their companies.

Open source code use is a two-way street, meaning if your developers use open source code, they should contribute back to open source projects by flagging bugs and suggesting improvements for everyone to use.

“That not only improves your usage of it, but it also improves the entire ecosystem around open source code,” Llaguno says.

Maria Minsker
By Maria Minsker | January 4, 2018

Subscribe to The Blueprint

By clicking here, I agree to receive information related to The Modern Software Factory Hub and its newsletter, The Blueprint, as well as updates from CA Technologies. I understand I may unsubscribe at any time.

Please fill out all required fields

Read our Privacy Notice to learn how your information may be used and about our commitment to protecting your privacy.

You are now subscribed to The Blueprint.