Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

10:30 AM
Mike Pittenger
Mike Pittenger
Connect Directly
E-Mail vvv

Best Practices for Securing Open Source Code

Attackers see open source components as an obvious target because there's so much information on how to exploit them. These best practices will help keep you safer.

Recently, a Forrester Research report called attention to open source's preeminence in application development, noting that custom code now often comprises only 10% to 20% of many applications.

Although traditional application security tools — dynamic analysis security testing (DAST) and static analysis security testing (SAST) — are effective in finding bugs in proprietary application code, they aren't effective in identifying vulnerabilities in open source components "in the wild." With SAST, this is true even months or years after the bugs have been publicly disclosed. In fact, most open source vulnerabilities are reported by security researchers and not found by DAST and SAST tools. Since 2004, more than 74,000 vulnerabilities have been disclosed by the National Vulnerability Database (NVD), but only a handful of those disclosures reference commercial security tools such as DAST, SAST, and fuzzers.

In addition, more than 80% of all cyberattacks target applications. The combination of these facts — applications are the top target of cyberattacks, open source is the foundation of today's application code, and traditional application security tools are ineffective in identifying open source — lead to the conclusion that open source vulnerabilities are one of the biggest risks to application security.

Our research shows that the average commercial application has more than 140 discrete open source components. Add to this that over 3,600 new open source component vulnerabilities were reported in 2016 — almost 10 per day on average and a 10% increase from 2015 — and the need for effective open source security and management is clear. However, our audits of client code consistently reveal that many organizations are blind to the security and license compliance risk that their use of open source may expose them to.

Why Do Our Adversaries Like Open Source Vulnerabilities?
I see no proof that open source is either more or less secure than proprietary, custom software. It's software, and will have bugs. However, because of the ubiquity of popular open source components, attackers see them as a target-rich environment with publicly available information on known vulnerabilities as well as detailed information and examples on how to exploit them.

[Check out the two-day Dark Reading Cybersecurity Crash Course at Interop ITX, May 15 & 16, where Dark Reading editors and some of the industry's top cybersecurity experts will share the latest data security trends and best practices.]

More importantly, open source is difficult to track manually, so organizations often don't have visibility to all of the open source components they use. Unlike commercial software, where updates and bug fixes are pushed to customer, open source has a "pull" support model. Users are responsible for keeping track of vulnerabilities as well as fixes and updates for the open source they use. Unless an organization is aware that a vulnerable open source component is included in its application, it's highly probable that that component will remain unpatched.

Best Practices to Manage Open Source Risks

Create and enforce open source use policies: Many organizations lack even basic documentation of open source policies. You should have a single responsible entity — either person or committee — overseeing open source usage, documented policies, and developer trained in their responsibilities when it comes to open source use.

Create and maintain a comprehensive inventory of open source in use: Inventory all open source components your teams use to develop software. A complete open source inventory must include all open source components, the version(s) in use, and download locations for each project in use or in development. You'll also need to include all dependencies — the libraries your code is calling to and/or the libraries that your dependencies are linked to — in your inventory.

If you're using third-party developers, you'll need to be confident that they will be as diligent about code inventory as an internal team. The larger the team and the more teams you have can quickly make the inventory process unwieldy and more prone to errors and omissions.

Map open source to known security vulnerabilities: Sources such as the NVD can provide information on publicly disclosed vulnerabilities in open source software. But be aware that not all vulnerabilities are reported to the NVD in a timely fashion, and that the format of NVD records often makes it difficult to determine which versions of a given open source component are affected by a vulnerability. You shouldn't rely on the NVD as your sole source of vulnerability information.

Other useful sources of information include project distribution sites such as those maintained by the Debian and Python projects. Security blogs and message boards such as the US-CERT alerts page and Google's security blog should also be part of your vulnerability research.

Identify other open source risks: Failure to comply with open source licenses can put organizations at significant risk of litigation and compromise of intellectual property. Similarly, the use of outdated or poor-quality components can compromise the quality of applications that use them.

Continuously monitor for new open source risks:With more than 3,600 new open source vulnerabilities disclosed every year, the job of tracking vulnerabilities doesn't end when applications leave development. Organizations need to continuously monitor for new threats as long as their applications remain in service.

Take the First Step to Open Source Security
Although it may seem easier to just keep doing what you're doing and hope for the best, the most important step you can take is to put some type of open source security management process into place. Application vulnerabilities are the biggest security threat to your organization, and using components with known vulnerabilities is an OWASP Top 10 issue. Without inventorying, managing, and securing the open source components used in those applications, you're providing attackers with an easy target.

Related Content:

Mike Pittenger has 30 years of experience in technology and business, more than 25 years of management experience, and 15 years in security. At Black Duck, he is responsible for strategic leadership of security solutions, including product direction. Pittenger's extensive ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/21/2020
Hacking Yourself: Marie Moe and Pacemaker Security
Gary McGraw Ph.D., Co-founder Berryville Institute of Machine Learning,  9/21/2020
Startup Aims to Map and Track All the IT and Security Things
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/22/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-09-23
An issue was discovered in Xen through 4.14.x. The PCI passthrough code improperly uses register data. Code paths in Xen's MSI handling have been identified that act on unsanitized values read back from device hardware registers. While devices strictly compliant with PCI specifications shouldn't be ...
PUBLISHED: 2020-09-23
In IgniteNet HeliOS GLinq v2.2.1 r2961, the login functionality does not contain any CSRF protection mechanisms.
PUBLISHED: 2020-09-23
In GLPI before version 9.5.0, the encryption algorithm used is insecure. The security of the data encrypted relies on the password used, if a user sets a weak/predictable password, an attacker could decrypt data. This is fixed in version 9.5.0 by using a more secure encryption library. The library c...
PUBLISHED: 2020-09-23
In IgniteNet HeliOS GLinq v2.2.1 r2961, the langSelection parameter is stored in the luci configuration file (/etc/config/luci) by the authenticator.htmlauth function. When modified with arbitrary javascript, this causes a denial-of-service condition for all other users.
PUBLISHED: 2020-09-23
In IgniteNet HeliOS GLinq v2.2.1 r2961, if a user logs in and sets the ‘wan_type’ parameter, the wan interface for the device will become unreachable, which results in a denial of service condition for devices dependent on this connection.