Troubles with software supply chain safety have recently grabbed a chunk of negative headline space. That might 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 the industry with a snapshot of organizations’ benefits and challenges when using open-source software. The survey, which runs through this month, measures the day-to-day use and management of open-source software.
Perhaps as a prelude to that report, recent research shows a dimming view of seemingly unsolvable vulnerabilities with open-source software. A common thread to the latest findings involves the potential success or failure of implementing the use of Software Bill of Materials (SBOM) industry-wide.
New SBOM Tool Brings Better OSS Fixes
Endpoint management firm Tanium on Nov. 1 launched the Tanium Software Bill of Materials (SBOM) to help organizations protect digital assets against external threats stemming from open-source software vulnerabilities, 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 particularly beneficial to public sector organizations faced with new regulatory requirements in the U.S. and the U.K. regarding the integrity and security of software.
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 is 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 Tanium Chief Product Officer Nic Surpatanu.
“Tanium’s SBOM takes this challenge head-on by leveraging endpoint data to break down the composition of software and root out weaknesses such as the newly announced vulnerability in OpenSSL version 3, he continued. “This clarity can mean the difference between a minor operational hiccup or a complete global disruption with lasting implications.”
SBOM is an entirely new approach to addressing supply-chain vulnerabilities. It focuses on the 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 IT environment.
This method allows Tanium to take swift, appropriate action, such as conducting application patching and software updates, including killing a specific process or uninstalling affected applications. Tanium can find and remediate vulnerabilities like OpenSSL v3 today as well as new supply-chain vulnerabilities in the future.
“The Log4j vulnerability has opened eyes to the dangers of vulnerable open-source software,” said Jason Bloomberg, president of analyst firm Intellyx.
“The ability to harness endpoint data for diagnostic analysis of the software landscape is essential, as enterprises increasingly depend on many disparate applications. Tanium’s SBOM data allows security teams to manage a variety of applications with the confidence that they can identify and address vulnerabilities before they adversely impact the customer,” he explained.
OpenSSL Fixes Two High Severity Vulnerabilities
The OpenSSL Project issued patches on Nov. 1 for two high-severity 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 4-byte stack buffer overflow, 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 serious vulnerabilities but was unaware of any working exploit that could lead to remote code execution.
The initial warning urged system admins to take immediate action to mitigate the flaw. CVE-2022-3602 was rated first as critical but now is downgraded to high severity. According to project officials, these recently released versions are not yet heavily deployed to software used in production compared to earlier versions of the OpenSSL library.
This critical vulnerability is only the second in OpenSSL in the better part of a decade, noted Dan Lorenc, CEO and co-founder at Chainguard. That reinforces the notion that open-source code is at least as secure as proprietary, closed-source 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 that has the tooling necessary to make remediation faster and more seamless by rooting it in secure by default measures,” he added.
While SBOMs have been dominating the conversation since the SolarWinds breach, no solutions have demonstrated the ability to help organizations effectively remediate issues like this one, according to Lorenc.
“A new approach is needed to make SBOMs effective, trustworthy, and complete. To achieve this, we need to generate SBOMs at build time, not after the fact. The reality is software supply chains, not just open source, have many problems today that cannot be fixed by silver bullet or point solutions,” he told LinuxInsider.
“Today’s bolted-on, SCA-based supply chain solutions have failed and will continue to fail to secure our industry’s software supply chains. We need to build in security by default if we are going to eliminate this threat vector.”
GitHub Flaw Threatens Software Supply Chain
A GitHub vulnerability could have impacted all renamed usernames on GitHub and enabled criminals to gain control over GitHub repositories, infecting all applications and other code, according to the Checkmarx SCS (Supply Chain Security) team. Attackers could have launched attacks against millions of users via the open-source supply chain.
Researchers reported this vulnerability to GitHub, which classified it as “High severity” and recently applied a fix. Earlier this year, an attacker used a similar exposure to hijack and poison popular PHP packages with millions of downloads. The Go, PHP, and Swift languages alone have more than 10,000 packages vulnerable to this attack vector.
The practical meaning is that thousands of packages can immediately be hijacked and serve malicious code to millions of users and many applications.
“This is not much different than the other supply chain issues we have seen historically. It is becoming a common attack vector, and it is going to require that companies that are leveraging open-source software repositories exercise extra care to ensure they understand not only what they are deploying but that they are inventorying this in a Software Bill of Materials (SBOM) method that will allow them to more readily identify and remediate when malicious or suspicious payloads have been identified in common repositories, Jim Kelly, regional vice president for Endpoint Security at Tanium, told LinuxInsider.
New Supply Chain Help Created
Google, in late October, announced the creation of the GUAC Open Source Project to bolster software supply chain security. Graph for Understanding Artifact Composition, or GUAC, is in the early stages yet is poised to change how the industry understands software supply chains, according to the Google Security Blog. The effort will make it easier for developers and other stakeholders to get access to software security metadata.
GUAC is a good start to solving a really hard problem, noted Scott Gerlach, co-founder and CSO at API Security Testing firm StackHawk. Giving developers and security teams rich information about the safety of open-source libraries and packages is very useful.
“The trick here is getting open-source developers to participate in this kind of program. What is their incentive? Most often, these are people who work on projects out of a passion for problem-solving and deep curiosity. Incentivizing OSS Devs to participate will be the key to GUAC’s success,” he told LinuxInsider.
No silver bullet exists for application security. He offered that you not only have to work on supply chain security but also must test the code you have written for AppSec vulnerabilities. Building a robust security program includes both practices and production monitoring.
Loading ...
