Companies using open source code, which is embedded in a vast majority of enterprise software, need a large-scale inventory of its existence. This is missing in many corporate IT records.
Without detailed accounting of the open source code running in their software, companies have no way to monitor software policies, licenses, vulnerabilities, and versions. This means that IT departments have no idea of the overall health of the open source components they use.
The problem is that many companies are sure that they are not using open source, so they don’t have to worry about updating security patches and code upgrades. This misconception usually leads to network breaches leading to malware and ransomware attacks.
The 2022 Synopsis The Open Source Security and Risk Analysis (OSSRA) report released last month showed an all-time high of open source code running in software. The problem of using open source has been growing year by year.
Open source code is prevalent in software packages, from business applications to network and server processes. Unless companies make a concerted effort to catalog and monitor how their organizations use open source code snippets, even known vulnerabilities go unchecked.
Addressing the issues highlighted by the report is a matter of ownership, according to Tim Mackey, senior security strategist at Synopsys SIG.
The results suggest a tacit awareness that the software that powers companies might not be under the control of their leaders. It also signals that the open source code of commercial products may not meet the standards to which they hold their own teams accountable.
“Because the source data for OSSRA comes from due diligence efforts related to M&A activity, not from a survey, the OSSRA report reflects the current state of software usage and not the opinion of what it might be”, Mackey told LinuxInsider.
Hard Truths Revealed
The 2022 OSSRA report audited anonymized results from more than 2,400 commercial codebases across 17 industries. The summary results in this chart are a red flag for corporate IT managers.
Source: 2022 Open Source Security and Risk Analysis Report (Credit: Synopsys)
The report serves as a crisis warning, particularly in light of the continued impact of the Log4J Vulnerability which appeared at the end of last year.
Of the 2,400 commercial codebases across 17 industries, 2,097 contained operational and security risk assessments. The growth in the number of codebases audited by Synopsys is 64% higher than last year. Much of this increase results from mergers and acquisitions throughout 2021.
Security threats resulting from Log4j were a significant reason President Biden late last year pushed his executive order on cybersecurity, Mackey noted.
It was also critical for the OSSRA report to motivate CIOs, VPs of Engineering, and CTOs to analyze their use of open source software and see how well OSSRA data matches up. to their own processes and governance.
“The OSSRA report has consistently emphasized that the problem with open source is not in the open source code itself, but in how people use it,” he added. “The free downloadable code is wonderful for the wallet, but that doesn’t mean it can be managed using the same processes you might find for commercial software.”
SBOM No universal solution
A key tenet of the OSSRA report is that risks can arise from unmanaged use of open source. There is a significant difference between a lack of open source management and the fact that open source itself is not the problem, the report concludes.
Open source is now the basis for commercial software, the researchers noted. It is found in 97% of commercial software. Despite its universal use, the misperception that open source is somehow inherently dangerous persists.
Unlike Microsoft and Apple products, where software vendors can proactively push updates and fixes to known users, open source doesn’t have such a vendor to handle risk management issues, observed. Mackey.
“Existing patch management solutions are often geared toward an update model,” he added. “Freely downloadable software means that the software producer does not know who their customers are or even if they are using the software they have downloaded.
The correction process and its assumptions get lost when people focus on things like Software nomenclature (SBOM) being a silver bullet for open source management, according to Mackey. Solving the problem requires going beyond SBOM.
SBOM is simply a tool to improve processes that were designed for a different type of software consumption, he said. Additionally, industries need to focus on identifying and monitoring open source components in the commercial software they use. That’s what needs to happen to fix what the OSSRA report says are problems, Mackey said.
Fix what can be fixed
The use of outdated open source components forces companies to adopt a monitoring process when their components become obsolete. But it’s not just about explicitly declaring dependencies or selecting trusted vendors. Mackey sees the problem as rooted deeper in the supply chain.
“The Log4Shell experiment is a perfect example of a foundational component that few people knew existed. But once Log4j became a priority due to the impact of the Log4Shell vulnerability, [it] forced the teams to rush and figure out the best way to handle this,” he pointed out.
This is the solution commercial software users should adopt. Inventory the existence of open source components. Then establish and run monitoring, patching, and updating.
“Whatever processes these teams use to successfully manage their large-scale Log4j experience should be applied to other components. In other words, use the Log4j experience to create a more scalable solution for your organization,” urged Mackey.