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.

Vulnerabilities / Threats

Real-World Use, Risk of Open Source Code

Organizations are using more open source software than ever before, but managing that code remains a challenge.

Open source code is vital to software development at most organizations, but that doesn't mean that enterprises have figured out how to use open source without inadvertently introducing vulnerabilities into their code.

A new study by the Synopsys Black Duck Audit Services team found that open-source software vulnerabilities have decreased, but many organizations seem to have trouble keeping track of the patched status of their open source components. Synopsis anonymized data from more than 1,200 codebases in enterprises in 17 different industries found that more than 96% of the codebases contain open source software or libraries. 

And according to their Open Source Security and Risk Analysis report, 60% of the codebases they audited had at least one vulnerability, down from 78% in last year's study.

More than 99% of codebases with more than 1,000 files contain open source components. And within those codebases, there are an average of 298 separate open source components — up from an average of 257 in the previous research. That increase in open source component count is important given that "few companies accurately track the components they use in their code. Most lack the policies, processes, and tools to keep up with the choices made by their developers," the report said. 

Open source component use is so prevalent that, in 13 of the 17 industry sectors tracked, there were more open source than proprietary components in the code base. That's why, says Tim Mackey, principal security strategist in the Synopsys Cybersecurity Research Center (CyRC), it's encouraging that the report contains some good news: "For the first time, there was a pretty substantial decrease in the number of open source vulnerabilities in the code base," he says. 

Mackey says that the reduction comes from a combination of patched vulnerabilities in the open source code, and a greater likelihood that the patched code will be in the codebases. "The companies are having a greater awareness of what to do and how to do it," he explains. With that said, unpatched code remaining in the codebases of organizations is a significant problem.

"Even though we're seeing a decrease in vulnerabilities in the aggregate, we're still seeing a lot of things that are 'stale," Mackey says, citing an example of the oldest seen by the researchers in this years study dating from 1990. According to the report, 43% of the scanned codebases contained vulnerabilities more than 10 years old - an indication that companies are not keeping up with open-source patching.

Given the number of open source components in most codebases, simply keeping up with open source components in your software are can be a daunting task -never mind keeping up with the fork, version, and state of updates to the code. 

'Gold Image'

Ed Giaquinto, CIO at Sectigo, says it's important for open source code to be properly inventoried and maintained to avoid introducing security vulnerabilities to applications. In response to a Twitter query about how organizations deal with open source components in their code libraries, he points to his desktop systems, where, "We get notifications of all installs (above and beyond the standard approved applications) from our endpoint management system." All servers, he says, are built from approved "golden images" with any deviations approved in advance and fully documented.

He says he believes that the combination of automated process and development discipline give the company 95% awareness of vulnerabilities and risks with open source code.

The importance of automation to keep up with open source updates is echoed by Rhett Glauser, vice president of marketing at SaltStack. "Considering modern scale & complexity, humans can't effectively deliver continuous compliance alone," he wrote in a response on Twitter.

Mackey is adamant that being aware of the code in a codebase is critical for maintaining the updates and patches required for secure code. "You can't patch something that you don't know you have," he says.

Even with a reliable inventory, though, knowing whether or not the code in your codebase is the most current, reliable, version can be difficult.

"Independent of whatever software asset software you have, you need to be building the bill of materials that includes where the code came from in the first place," Mackey says. "A solution for patching something that came from one source might not work for the same item that came from a different source."

And you might not even know that an item needs to be patched if the open source world is assumed to be akin to the commercial software market, where updates are frequently pushed to the customer, and there are regular communications about updates and patches. "They need to be engaged with the communities," explains Mackey. "In the open source world, they don't know who you are without the level of engagement."

He recommends building a development strategy that includes committing time and resources to participating in the open source communities that develop the code you adopt. That engagement can help security-wise, he says. "...the transparency of mature, well-adopted OSS [open source software] can foster peer review that is tough to match in proprietary [software]."

Related Content:

 

 

 

Join Dark Reading LIVE for two cybersecurity summits at Interop 2019. Learn from the industry's most knowledgeable IT security experts. Check out the Interop agenda here.

Curtis Franklin Jr. is Senior Editor at Dark Reading. In this role he focuses on product and technology coverage for the publication. In addition he works on audio and video programming for Dark Reading and contributes to activities at Interop ITX, Black Hat, INsecurity, and ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Mobile Banking Malware Up 50% in First Half of 2019
Kelly Sheridan, Staff Editor, Dark Reading,  1/17/2020
Active Directory Needs an Update: Here's Why
Raz Rafaeli, CEO and Co-Founder at Secret Double Octopus,  1/16/2020
New Attack Campaigns Suggest Emotet Threat Is Far From Over
Jai Vijayan, Contributing Writer,  1/16/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
The Year in Security: 2019
This Tech Digest provides a wrap up and overview of the year's top cybersecurity news stories. It was a year of new twists on old threats, with fears of another WannaCry-type worm and of a possible botnet army of Wi-Fi routers. But 2019 also underscored the risk of firmware and trusted security tools harboring dangerous holes that cybercriminals and nation-state hackers could readily abuse. Read more.
Flash Poll
How Enterprises are Attacking the Cybersecurity Problem
How Enterprises are Attacking the Cybersecurity Problem
Organizations have invested in a sweeping array of security technologies to address challenges associated with the growing number of cybersecurity attacks. However, the complexity involved in managing these technologies is emerging as a major problem. Read this report to find out what your peers biggest security challenges are and the technologies they are using to address them.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-5216
PUBLISHED: 2020-01-23
In Secure Headers (RubyGem secure_headers), a directive injection vulnerability is present in versions before 3.9.0, 5.2.0, and 6.3.0. If user-supplied input was passed into append/override_content_security_policy_directives, a newline could be injected leading to limited header injection. Upon seei...
CVE-2020-5217
PUBLISHED: 2020-01-23
In Secure Headers (RubyGem secure_headers), a directive injection vulnerability is present in versions before 3.8.0, 5.1.0, and 6.2.0. If user-supplied input was passed into append/override_content_security_policy_directives, a semicolon could be injected leading to directive injection. This could b...
CVE-2020-5223
PUBLISHED: 2020-01-23
In PrivateBin versions 1.2.0 before 1.2.2, and 1.3.0 before 1.3.2, a persistent XSS attack is possible. Under certain conditions, a user provided attachment file name can inject HTML leading to a persistent Cross-site scripting (XSS) vulnerability. The vulnerability has been fixed in PrivateBin v1.3...
CVE-2019-20399
PUBLISHED: 2020-01-23
A timing vulnerability in the Scalar::check_overflow function in Parity libsecp256k1-rs before 0.3.1 potentially allows an attacker to leak information via a side-channel attack.
CVE-2020-7915
PUBLISHED: 2020-01-22
An issue was discovered on Eaton 5P 850 devices. The Ubicacion SAI field allows XSS attacks by an administrator.