What's In Your Code?


Find & Fix IP Compliance Issues & OSS Security Vulnerabilities Before They Find You!

Software applications help meet customer and competitive needs, but they also provide a primary avenue for attackers to evade traditional network barriers. These applications, particularly externally facing, web-based ones, represent a significant opportunity and risk to every organization.

Software security in general, and application security specifically, is also a necessity for compliance with the laws, regulations, and policies that govern most organizations and their proprietary data. Weak software security can cause, for example, non-compliance with the Sarbanes-Oxley Act, the Payment Card Industry Data Security Standard, among others.

Application security is a difficult coordination problem for organization. Different teams within an organization have responsibilities for ensuring the security of web applications, software applications, hardware, and network connections. Coordination cuts across all levels of a company – from engineering teams that write the code all the way to the audit committee of the Board of Directors that must assess compliance to appropriate processes for managing information reliability and security.

Software Governance: Application Security Risks of Undocumented Open Source Software (OSS)
Today’s software developers are making intellectual property decisions. In the past, if developers wanted to incorporate third-party code into their applications, a joint development agreement or in-bound licensing contract would be negotiated. The process would have also included a development manager, procurement lead, and a lawyer. With today’s explosion of open source projects and easy access to code, developers dispersed across multi-national sites can incorporate open source, freeware, public domain, and even commercial code into their software without triggering the usual checkpoints in the procurement process. Without controls, the third party IP is unlikely to be detected, monitored, and tracked.

As a result, IT organizations are unaware of exactly what comprises their code base. In recent studies, Palamida found that many applications written within the last five years contain 50% or more open source code, by a line of code count. Of that 50 % of open source code, 70% was undocumented.

Typical Audit Results:

F1000 Company Audit Results
Size: 10.46 GB, 20.3MLOC
3rd Party Components Discovered: 1558
3rd Party Components Disclosed: 337
Percentage Undocumented: 78%


Source: Palamida Professional Services Audits

Organizations must now manage the newly emergent and informal “software supply chain” through which open source regularly enters the development environment. It is also in their best interest to ensure that they have a transparent authorization and monitoring system that enables them to minimize version proliferation, guarantee that they are using the most secure releases, and are aware of any known security vulnerabilities within their applications.

Not doing so leaves organizations open to data breaches, legal issues, and financial business exposure.

For Example:

Open Source Project: Open SSL (Heartbleed)
Issue: In the spring of 2014, a vulnerability discovered in OpenSSL 1.0.1 (a cryptographic software library) known as Heartbleed CVE-2014-0160, affected millions of applications, websites, servers, etc. by allowing remote attackers to access sensitive information, such as security keys/passwords stored in memory. A patch was available quickly, but if you were not aware of which of your applications (and which of your supplier’s applications) were using a particular Open Source component, you could not upgrade to the secure version.

Open Source Project: Zlib
Issue: The Zlib library has been a fundamental open source software component for almost 20 years and can be found in almost every Linux and Unix system. Security flaws in earlier versions of zlib have impact beyond the scope of open source projects alone. According to the zlib project page, there are hundreds of applications from both open source and commercial vendors that use zlib.

Open Source Project: Bash (Shellshock)
Issue: In September of 2014, a security bug, named Shellshock or Bashdoor CVE-2014-6271 in Bash version 1.0.3 was discovered, which allowed attackers to execute arbitrary commands – allowing unauthorized access to millions of servers/systems. Most notably was a botnet distributed denial-of-service (DDoS) attack against Akamai and the United States Department of Defense.

Open Source Project: ffmpeg
Issue: FFMpeg is a popular open source component used for converting and streaming video. While the main component is licensed under the terms of the Lesser General Public License v2.1 or greater, some optional (but also popular) pieces are licensed under the stronger General Public License. These optional pieces often cause unexpected licensing issues for teams if they are unaware of the differences.

Open Source Project: BusyBox
Issue: In 2009, the Software Freedom Law Center, on behalf of BusyBox, sued more than a dozen big name electronics companies (Best Buy, Samsung, Westinghouse, to name a few) for GPL license violations (not distributing the BusyBox license).

Open Source Project: iptables
Issue: In 2013, the German Courts ruled against Fantec, a European company that makes hardware devices for playing video & multimedia on devices such as televisions, for GPLv2 violations. Fantec was using iptables, written by Harald Welte, but failed to make the correct source code available per the terms of the GPL and thus, was sued for the license violation. Fantec claimed they were not responsible for the violation because the code was supplied by an outside vendor. The ruling against Fantec reinforced that ultimately embedded device distributors (in this case Fantec) are responsible for what they are shipping, regardless of who writes the code.

Open Source Project: DataTables
Issue: In 2013, the HealthCare.gov site was the target of controversy over allegedly stripping copyrights and licenses from JavaScript code. The site used DataTables which is licensed under GPLv2 and BSD, but appeared not to comply with the licenses’ obligation to “keep the copyright notices in the software.”

Vulnerabilities in Open Source vs. Proprietary: It’s All the Same
Organizations that use open source components are largely on their own when it comes to patches, upgrades, vulnerability assessment and similar tasks that would normally be a part of a commercial service contract.

Most IT teams believe they have adequate application security solutions in place because of significant investment in firewalls, web-based authentication, intrusion detection, and identity management systems. While important security layers, these solutions are securing the perimeter by managing traffic to the applications. None focus on securing the applications from the inside out.

Software security vulnerabilities are often caused by defects in specification, design, and/or implementation. It is becoming clear that the consequences of OSS adoption and management (or lack of management) made during the software development lifecycle impact the likelihood of security incidents and the success in responding to them.

"A typical proprietary software company will have a security team that ensures that best practices are carried out. They have the budgets to maintain those teams," says Zack Samocha, Senior Director of Products at Coverity. "I don't see those entities…in the open source community." -CIO, Paul Rubens

Is open source code more vulnerable than proprietary code? Absolutely not. The point is not that it is more or less vulnerable to attacks. Rather, organizations need to treat it with the same stringent compliance audit frameworks as they use for the code they write themselves. For companies who do not realize that 50% or more of their application’s code base could be comprised of open source software that is a significant factor for their software assurance programs.

Sign up to get Email Notifications


News & Events

Knowledge Center