A number of popular commercial applications in categories ranging from browsers to messaging and meeting apps all contained open-source components with security vulnerabilities, according to new research released Wednesday.
The study performed by Osterman Research for GrammaTech also found that of the most popular commercial browser, email, file sharing, online meeting, and messaging products tested, 85 percent contained at least one critical vulnerability.
“Commercial off-the-shelf software applications often include open-source components, many of which contain a range of known vulnerabilities that can be exploited by malware, yet vendors often do not disclose their presence,” Osterman senior analyst Michael Sampson said in a statement.
“This lack of visibility into deployed and to be deployed applications is essentially a time bomb that increases an enterprise’s security risk, attack surface, and potential for compromise by cybercriminals,” he added.
Online meetings and email clients, which contained the highest average weighting of vulnerabilities, were the most-exposed categories the researchers studied.
“A lot of these online meeting applications were pushed out rapidly because of the pandemic. That’s why online meeting applications have more open-source components and more vulnerabilities,” explained Christian Simko, director of product marketing at GrammaTech, an application security testing company headquartered in Bethesda, Md.
He added that email and messaging apps may contain many flaws because they depend on Open SSL, an open-source communication protocol.
“Open SSL is very prevalent, and it’s a very vulnerable open-source component,” he told TechNewsWorld.
According to Osterman, Open SSL accounted for 9.6 percent of the open-source vulnerabilities found in all applications.
Better Monitoring Needed
Saryu Nayyar, CEO of Gurucul, a threat intelligence company in El Segundo, Calif., maintained that open-source software is as secure or even more secure than most commercial software.
“The crowdsourcing approach to software contributions usually identifies and fixes vulnerabilities quickly,” she told TechNewsWorld.
“However, for organizations that use open source libraries or other software, it is incumbent upon them to monitor open source use in their software and to patch or otherwise replace open source software that has a vulnerability,” she said.
“Many organizations frankly don’t bother to maintain a detailed list of their use of open source and don’t follow the message boards for their open source libraries,” she continued. “That leaves them vulnerable to attacks on known exploits due to the version they are using.”
“Organizations will check their custom code thoroughly but are not as rigorous with open source and commercial code,” added GrammaTech’s CMO, Andy Meyer.
He explained that commercial software makers are using open-source and third-party components to meet the time and cost restrictions they may be under.
“The fact that they’re using these components without testing them themselves speaks to the problem of speed and the need to accelerate release cycles,” he told TechNewsWorld. “They’re under pressure to get it done.”
All Open Source Not Equal
The risk that open source components pose to applications has less to do with the component itself than the supply chain that supports it, asserted Tsvi Korren, field CTO at Aqua Security, a container security company based in Ramat Gan, Israel.
“It all comes down to the degree of governance and oversight, which open-source projects often lack,” he told TechNewsWorld.
“We need to differentiate between projects that are sponsored and maintained by organizations — software companies or non-profits — and those that were started by and are still maintained by individuals or unorganized groups,” he continued.
“The latter category introduces the most risk to applications because these projects can’t invest in security testing, don’t provide service level agreements for fixes, and they can potentially be a target for attackers who try to ‘contribute’ malicious code and make it part of the project,” he said.
Since organizations don’t have control over changes made to open-source components, they need to be aware of when changes are made in them, advised Shawn Smith, director of infrastructure at nVisium, a Herndon, Va.-based application security provider.
“Using dependencies that are open source are perfectly fine so long as you’re properly auditing the source for issues, in addition to performing continual audits any time you update that dependency in your platform,” he told TechNewsWorld.
“Many organizations will staff their own internal teams to focus on remediating security issues reported against their open-source components,” added Kevin Dunne, president of Pathlock, a unified access orchestration provider in Flemington, N.J.
“The benefit of open-source components is that teams can create their own patches internally to fix problems that concern them, but it comes at a cost,” he told TechNewsWorld.
Software Bill of Materials
A key to reducing the risk of using open-source components in software is adding transparency to the review process.
“Solving the problem starts with visibility,” observed Dan Nurmi, CTO of Anchore, a container security company in Santa Barbara, Calif.
“Organizations need to understand the full open source picture,” he told TechNewsWorld.
One way to get that picture is through a software bill of materials (SBOM), which lists all the components and dependencies in an application.
“The software bill of materials can help with transparency and visibility into the entire third and fourth party landscape and can help you better understand what’s involved with using a specific tool,” Demi Ben-Ari, co-founder and CTO of Panorays, in Tel Aviv, Israel, which automates, accelerates and scales third-party security processes, told TechNewsWorld.
“Having a list of the components is always helpful for organizations and their teams to monitor published and newly discovered vulnerabilities,” added Purandar Das, CEO and co-founder of Sotero, a data protection company in Burlington, Mass.
“It also makes it easier to identify the patches that need to be applied,” he told TechNewsWorld.
Nurmi explained that creating software bills of materials is a common practice in the industry, but it hasn’t been formalized.”
“There isn’t a lot of guidance about what kinds of information is relevant when it comes to cross-organizational information sharing,” he said.
Korren noted that a good software bill of materials should indicate the exact components used in the software.
“Transparency is better than hiding these components but disclosing them doesn’t reduce the risk in the software,” he observed.
“What a BOM can do is to put pressure on vendors and users to pay attention to the security risks and the governance in the open source components,” he said.
“Users of the software could more easily find what vulnerabilities exist in these components and work to mitigate them,” he explained.
“Disclosure will also indicate if the vendor is keeping up with the releases of the open-source components,” he continued.
“But all of that requires work,” he added, “and the tendency right now is to ignore the problem so that software can continue to move through the pipeline.”
Loading ...
