Report: Open-Source Code is a Minor Issue, but Managing It Is a Major Challenge:

0
65

Businesses that use open-source code, which is found in the vast majority of enterprise-grade software, require a comprehensive inventory of the code’s existence. Many business IT records lack this information.

Companies have no method of monitoring software regulations, licences, vulnerabilities, or versions without a full accounting of open-source code operating within their programme. This implies that IT departments have no idea how healthy the open-source components they employ are.

The problem is that many businesses are certain they do not utilise open source, so they do not have to bother about security fixes or code upgrades. This misunderstanding frequently leads to network breaches and malware and ransomware assaults.

Last month’s Synopsys Open Source Security and Risk Analysis (OSSRA) Report revealed an all-time high in open source code being used in software. The issue of employing open source has been steadily increasing year after year.

From commercial apps to network and server functions, open-source code is found in many software packages. Even known vulnerabilities go unnoticed unless corporations make a determined effort to catalogue and monitor how their firms employ open-source snippets.

According to Tim Mackey, lead security strategist at Synopsys SIG, fixing the flaws highlighted in the research is a question of ownership.

The findings point to an unspoken understanding that the software that runs firms may not be under their managers’ control. It also implies that commercial goods may not use open-source code.

“Because the OSSRA source data originates from technical due diligence activities associated to mergers and acquisitions activity, rather than a poll, the OSSRA report reflects the present status of software utilisation rather than a view of what it may be,” Mackey told LinuxInsider.

Uncovering the Hard Truths

The anonymous findings from over 2,400 commercial codebases across 17 sectors were audited for the OSSRA report in 2022. The graphic’s summary results should serve as a wake-up call to corporate IT managers.

The study serves as a crisis alert, particularly in view of the continued effect of the Log4J vulnerability, which was discovered late last year.

Security and operational risk evaluations were found in 2,097 commercial codebases spanning 17 sectors. The number of codebases Synopsys audited increased by 64% over the previous year. Mergers and acquisitions accounted for a large portion of the growth in 2021.

According to Mackey, the security dangers posed by Log4j were a major reason President Biden pushed his Executive Order on Cybersecurity late last year.

The OSSRA report also served as a catalyst for corporate chief information security officers, vice presidents of engineering, and chief technical officers to examine their open-source software utilisation and compare it to the OSSRA statistics.

“The OSSRA study has continuously said that the problem with open source is not the code itself, but how people utilise it,” he continued. “While freely available code is great for the wallet, that doesn’t mean it can be handled using the same procedures as paid software.”

No Universal Fix SBOM

The OSSRA research asserts that uncontrolled open source adoption might result in dangers. According to the analysis, the distinction between a lack of open-source management and the reality that open source is not the problem is substantial.

According to academics, open source is now the backbone of commercial software. It’s present in 97% of commercial software. Despite its widespread adoption, the myth that open source is inherently risky continues.
Unlike Microsoft and Apple goods, where software makers may proactively distribute updates and fixes to known consumers, open-source does not have such a vendor, according to Mackey.

He said, “Existing patch management systems are frequently focused around an update approach.” “Freely downloadable software implies that the software manufacturer has no idea who its clients are or whether they are even utilising the programme they downloaded.”

According to Mackey, when people focus on things like Software Bill of Materials (SBOM) being a silver bullet for open-source management, the patching process and its assumptions get buried. To solve the problem, you must move beyond SBOM.

SBOM, he explained, is merely a tool for improving processes that were created for a particular form of software consumption. Furthermore, businesses must concentrate on finding and monitoring open-source components in commercial software. That’s what has to happen, according to Mackey, to fix the shortcomings identified in the OSSRA study.

Fixing Fixable Issues
Using outdated open-source components necessitates the adoption of a monitoring method for when such components become obsolete. But it’s not simply about stating dependencies and choosing permitted vendors. The problem, according to Mackey, is more deeply embedded in the supply chain.

“The Log4Shell experience is an excellent example of a fundamental component that few people were aware of. However, because of the effect of the Log4Shell vulnerability, “Log4j became front of mind, forcing teams to scramble and figure out how to best handle it,” he explained.

That is the answer for commercial software users in businesses. Make a list of open-source components that exist. Then develop and carry out monitoring, patching, and updating procedures.

“Any techniques that those teams utilised to manage their Log4j experience at scale effectively should be adapted to other components.” In other words, apply your Log4j knowledge to create a more scalable solution for your company,” Mackey said.

 

 

LEAVE A REPLY

Please enter your comment!
Please enter your name here