The latest open source software industry news from LinuxInsider

0

Software supply chain security issues have captured some of the negative headline space recently. This may well set the stage for what to expect in an upcoming State of Open Source report.

A collaboration between OpenLogic by Perforce and the Open Source Initiative (OSI) will provide industry insight into the benefits and challenges for organizations when using open source software. The survey, which runs throughout this month, measures the daily use and management of open source software.

Perhaps as a prelude to this report, recent research shows a bleak view of seemingly intractable vulnerabilities with open source software. A common thread running through the latest findings involves the potential success or failure of implementing software bill of materials (SBOM) usage industry-wide.

New SBOM Tool Brings Better OSS Fixes

Terminal management company Tanium November 1 launched the Tanium Software Bill of Materials (SBOM) to help organizations protect digital assets against external threats resulting from vulnerabilities in open source software, including OpenSSL v3.

The solution gives IT and security teams granular visibility and real-time remediation of software packages for every application on every endpoint at runtime. Tanium SBOM is especially beneficial for public sector organizations facing new regulatory requirements in the US and UK regarding software integrity and security.

Although open source software powers the modern digital economy, the average application development project contains nearly 50 vulnerabilities spanning 80 direct dependencies. While indirect dependencies are even harder to find, that’s where 40% or more of all vulnerabilities hide, according to Tanium.

“Software supply chain vulnerabilities have been at the heart of some of the most disruptive cyber events we’ve seen,” said Nic Surpatanu, chief product officer at Tanium.

“Tanium’s SBOM addresses this challenge head-on by leveraging endpoint data to decompose software composition and eliminate weaknesses such as the recently announced vulnerability in OpenSSL version 3,” he continued. “This clarity can be the difference between a minor operational hiccup or a full global disruption with lasting implications.”

SBOM is an entirely new approach to addressing supply chain vulnerabilities. It focuses on software residing on individual assets to detect libraries and software packages with known vulnerabilities. Tanium’s process goes beyond basic scanning tools by examining the contents of individual files wherever they reside in the computing environment.

This method allows Tanium to take prompt and appropriate action, such as performing application fixes and software updates, including removing a specific process or uninstalling affected applications. Tanium can find and fix vulnerabilities like OpenSSL v3 today as well as new supply chain vulnerabilities in the future.

“The Log4j vulnerability opened our eyes to the dangers of vulnerable open source software,” said Jason Bloomberg, president of analyst firm Intellyx.

“The ability to leverage endpoint data for diagnostic analysis of the software landscape is critical as businesses increasingly depend on many disparate applications. Tanium’s SBOM data enables security teams to manage a variety of applications with confidence that they can identify and address vulnerabilities before they negatively impact the customer,” he explained. .

OpenSSL fixes two high severity vulnerabilities

The OpenSSL Project released patches on Nov. 1 for two very serious security flaws in its open-source cryptographic library that encrypts communication channels and HTTPS connections. The vulnerabilities (CVE-2022-3602 and CVE-2022-3786) affect OpenSSL version 3.0.0 and later.

The first, an arbitrary stack buffer overflow of 4 bytes, could trigger crashes or lead to remote code execution (RCE). Attackers could use the second to initiate a denial of service state via a buffer overflow. The OpenSSL team considered these issues to be serious vulnerabilities, but were not aware of any functional exploits that could lead to remote code execution.

The initial warning urged system administrators to take immediate action to mitigate the flaw. CVE-2022-3602 was first categorized as critical, but is now downgraded to high severity. According to project officials, these recently released versions are not yet widely deployed to software used in production compared to earlier versions of the OpenSSL library.

This critical vulnerability is only OpenSSL’s second in the better part of a decade, noted Dan Lorenc, CEO and co-founder of Chainguard. This reinforces the idea that open-source code is at least as secure as closed-source proprietary code, he said.

“Major, well-funded vendors see bugs like this at a much higher rate. Instead of debating the merits of open source, we should instead focus on building secure software with the tools to make remediation faster and more transparent by rooting it in secure measures by default,” he added.

While SBOMs have dominated the conversation since the SolarWinds breach, no solution has demonstrated the ability to help organizations effectively address issues like this, according to Lorenc.

“A new approach is needed to make SBOMs effective, trustworthy and comprehensive. To achieve this, we need to generate SBOMs at build time, not after the fact. The reality is that software supply chains, not just open source, have many problems today that cannot be solved by quick fixes or one-time solutions,” he told LinuxInsider.

“Today’s integrated, SCA-based supply chain solutions have failed and will continue to fail to secure our industry’s software supply chains. We need to integrate security by default if we want to eliminate this threat vector. »

GitHub Flaw threatens the software supply chain

According to checkmarx SCS team (Supply Chain Security). Attackers could have launched attacks against millions of users through the open source supply chain.

Researchers reported this vulnerability to GitHub, which classified it as “High Severity” and recently applied a patch. Earlier this year, an attacker used similar exposure to hijack and poison popular PHP packages with millions of downloads. The Go, PHP and Swift languages ​​alone have over 10,000 packages vulnerable to this attack vector.

The practical meaning is that thousands of packages can be hacked immediately and serve as malicious code for millions of users and many applications.

“It’s not much different from other supply chain issues we’ve had in the past. This is becoming a common attack vector, and it’s going to require companies operating open source software repositories to take extra care to ensure that they not only understand what they’re deploying, but that they inventory it in a software nomenclature (SBOM) that will make it easier for them to identify and remediate when malicious or suspicious payloads have been identified in common repositories, said Jim Kelly, regional vice president for Endpoint Security at Tanium, at LinuxInsider.

New supply chain help created

Google, at the end of October, announced the creation of the Open Source project GUAC to strengthen the security of the software supply chain. Graph for Understanding Artifact Composition, or GUAC, is in its infancy but is poised to change the way the industry understands software supply chains, according to Google’s security blog. This effort will make it easier for developers and other stakeholders to access software security metadata.

GUAC is a good start to solving a really difficult problem, noted Scott Gerlach, co-founder and CSO of API Security Testing. StackHawk. Giving developers and security teams detailed information about the security of open source libraries and packages is very useful.

“The trick here is to get open source developers involved in this kind of program. What is their motivation? OSS developers to participate will be key to the success of GUAC,” he told LinuxInsider.

There is no magic bullet for application security. He proposed that you should not only work on supply chain security, but also test the code you wrote for AppSec vulnerabilities. Developing a robust security program includes both practices and production monitoring.

Share.

Comments are closed.