Businesses using open-source code — which is embedded in a large majority of enterprise-grade software — need a full-scale inventory of its existence. That is missing in many corporate IT records.
Without a detailed accounting of open-source code running within their software, companies have no way to monitor software policies, licenses, vulnerabilities, and versions. That means IT departments are clueless about the overall health of the open-source components they use.
At issue is that many enterprises are sure they do not use open source, so they do not have to worry about keeping security patches and code upgrades current. That misconception usually results in network breaches, leading to malware and ransomware attacks.
The 2022 Synopsys Open Source Security and Risk Analysis (OSSRA) Report released last month showed an all-time high in open-source code running in software. The problem of using open source has been growing consistently year after year.
Open-source code is prevalent in software packages, from business applications to network and server processes. Unless enterprises make a concerted effort to catalog and monitor how their organizations use open-source snippets, even known vulnerabilities go unattended.
Fixing the problems the report highlights is a question of ownership, according to Tim Mackey, principal security strategist at Synopsys SIG.
The results suggest a tacit realization that the software powering businesses might not be under their managers’ control. It also signals that the open-source code in commercial products may not meet the standards to which they hold their own teams accountable.
“Given the OSSRA source data comes from technical due-diligence efforts related to mergers and acquisitions activity, and not a survey, the OSSRA report is a reflection of the current state of software usage and not the opinion of what it might be,” Mackey told LinuxInsider.
Harsh Truths Revealed
The 2022 OSSRA report audited anonymized findings from over 2,400 commercial codebases across 17 industries. The summary results in this graphic are a wake-up call to corporate IT overseers.
Source: 2022 Open Source Security and Risk Analysis Report (Credit: Synopsys)
The report serves as a crisis warning, especially in light of the ongoing impact of the Log4J vulnerability that appeared late last year.
Of the 2,400 commercial codebases across 17 industries, 2,097 contained security and operational risk assessments. The growth in the number of codebases Synopsys audited is 64 percent larger than last year’s. Much of that increase resulted from mergers and acquisitions throughout 2021.
The security threats resulting from Log4j were a significant reason President Biden late last year pushed his Executive Order on Cybersecurity, noted Mackey.
It was also key for the OSSRA report to motivate corporate chief information security officers, vice presidents of engineering, and chief technical officers to analyze their open-source software usage and see how well the OSSRA data maps to their own processes and governance.
“The OSSRA report has consistently highlighted that the problem with open source is not within the open-source code itself, but in how people use it,” he added. “Freely downloadable code is wonderful for the pocketbook, but that does not mean it can be managed using the same processes as you might find for commercial software.”
SBOM No Universal Fix
A key tenet of the OSSRA report is that risks can stem from unmanaged use of open source. The difference is significant between a lack of open-source management and the fact that open source itself is not the problem, the report concludes.
Open source now is the foundation of commercial software, noted researchers. It is found in 97 percent 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 patches to known users, open-source has no such vendor to handle risk management issues, observed Mackey.
“Existing patch management solutions are often geared toward an update model,” he added. “Software that is freely downloadable means the software producer does not know who its customers are or even if they are using the software they downloaded.
The patching process and its assumptions get lost when people focus on topics like Software Bill of Materials (SBOM) being a silver bullet for open-source management, according to Mackey. Fixing 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. In addition, industries need to focus on identifying and monitoring open-source components in the commercial software they use. That is what has to happen to correct what the OSSRA report indicates are problems, said Mackey.
Fixing What’s Fixable
Using obsolete open-source components requires companies to adopt a process for monitoring when their components become out-of-date. However, it is not just explicitly declaring dependencies or selecting approved suppliers. Mackey sees the problem as more deeply rooted in the supply chain.
“The Log4Shell experience is a perfect example of a foundational component that few knew existed. But once Log4j became front of mind due to the impact of the Log4Shell vulnerability, [it] forced teams to rush and figure out how to best manage it,” he pointed out.
That is the solution enterprise users of commercial software must do. Inventory the existence of open-source components. Then, establish and execute monitoring, patching, and updating.
“Whatever processes those teams used to successfully manage their Log4j experience at scale should be applied to other components. In other words, use the Log4j experience to build a more scalable solution for your organization,” urged Mackey.
Loading ...
