Open source security needs automation as usage climbs amongst organisations

With more organisations tapping open source codes in their own applications, they will need to be able to work through the complexities of such environments with automation tools so they can quickly respond to new vulnerabilities.

Almost all internally developed software today contained some open source codes, noted Phillip Ivancic, Asia-Pacific head of solutions strategy at Synopsys Software Integrity Group.

According to the security vendor’s 2022 Open Source Security and Risk Analysis report, 97% of commercial codebases contained at least some open source codes. Of these, an average 78% of code in the codebases was open source. Released in May, the study analysed 2,409 commercial codebases across 17 industries.

Most organisations would not want to build everything from scratch when they develop their own software, said Liu Yang, co-founder and CEO of Scantist, an application security vendor that in 2016 spun off from a research lab in Singapore’s Nanyang Technological University (NTU).

There now were many well-established libraries and codebases in open source software (OSS) that organisations could tap and build upon, Liu said in an interview with ZDNet.

Andrew Martin, Databricks’ South Asia head, concurred, adding that open source enabled companies to innovate faster and leveraged codes that already were available, instead of spending resources building proprietary software in-house.

Open source technology also ensure full transparency and visibility into source code, offering data teams a connection to the wider open source community, Martin said. 

However, Liu said, tapping open source meant that any vulnerability in the codes then could be inherited by the host enterprise application. Open source vulnerabilities, hence, always should be addressed first, he said.

Failure to do so could lead to serious security risks for businesses that did not remain informed of such vulnerabilities and update their software accordingly, he cautioned.

The Synopsys study revealed that 81% of software codes contained at least one known open source vulnerability, a 3% drop from the previous year.

While tapping open source did not imply in-house software was any less secure, doing so brought in key considerations that should be addressed and managed, Ivancic told ZDNet. For one, companies should know all OSS components including the actual versions that were used in their projects’ codebase.

Referred to as the Software Bill of Materials (SBOM), this central repository would ensure companies were able to quickly respond when new vulnerabilities were uncovered, such as last year’s high-profile zero-day flaw Log4j. With a SBOM, they would be able to identify applications that were vulnerable and deploy the necessary remediation actions, he said.

They also needed to know the exact OSS codebase used in any given project, so they could determine if the application would be impacted when new high-risk vulnerabilities were discovered.

The Log4j zero-day flaw, in particular, was likely to spawn more vulnerabilities in coming years due to the increasing use of OSS, said Liu.

Furthermore, he noted that the Java library for logging error messages in applications was a fundamental framework used by half of Java applications, which meant that all open source software that used the library potentially had severe vulnerabilities.

Hackers could exploit the Log4j flaw to perform remote attacks and use a company’s OSS library to control its systems.

It also was tough dealing with such vulnerabilities due to the layered nature of OSS development, he said.

“If you’re using an OSS library for one application, that library likely is using a second library and that, in turn, is using a third library,” Liu explained. “If the third library has a critical vulnerability and you’re using the first library, there is intrinsic vulnerability in this dependency chain. It can present security risks for you, even if you’re not using the third library.”

Identifying all passive and indirect interdependencies was far from easy, he noted, adding that it could be difficult for companies to access security experts to carry out such works. He pointed to the need for automated tools to support such security assessments.

Ivancic stressed the need for organisations to understand the operational and licensing risks involved in using open source codes. For instance, he noted that OSS codebases that did not have an active community of contributors could indicate potential risks, since new vulnerabilities might not be uncovered and patched in a timely fashion.

The Synopsys study revealed that 88% of codebases used components that were not the latest version, while 84% had open source codes that were more than four years out-of-date. In addition, 53% of audited codebases had licensing conflicts and 20% contained open source with no license or custom license.

Ivancic noted that open source projects had various licensing provisions that ranged from very permissive to those that might require users to publish derivative works under the same licensing terms. A SBOM then would better able organisations to track the different licensing conditions, he said.

“If organisations aren’t proactive about maintaining and reviewing their vulnerability updates, they run the risk of becoming an easy target for attackers,” he noted. “Additionally, if they fail to comply with open source licenses, they can put their business at risk of litigation and open themselves to threats to their intellectual property.”

Like Liu, Ivancic underscored the importance of building automation into the development pipelines to mitigate risks based on internal security policies.

“OSS is not insecure per se…the challenge is with all the versions and components that may make up a software project,” he explained. “It is impossible to keep up without automation and prioritisation.” 

He noted that the OSS community was responsive in addressing security issues and deploying fixes, but organisations tapping OSS would have to navigate the complexity of ensuring their software had the correct, up-to-date codebase.

This was further compounded by the fact that most organisations would have to manage many projects concurrently, he said, stressing the importance of establishing a holistic software security strategy.

He further pointed to the US National Institute of Standards and Technology (NIST), which offered a software supply chain framework that could aid organisations in planning their OSS security response.

Regulations helpful, but not enough to fix all

Asked if regulations were needed to drive better security practices, Liu said most companies saw cybersecurity as a cost and would not want to address it actively in the absence of any incentive.

Hence, some corresponding governance or regulatory policies would be helpful in improving the overall security of open source software, he said.

He noted that there had been discussions amongst developers about the risks of backdoor exploits and malicious codes, which suggested a need for better governance in terms of security and responsibility. He added that his research team at NTU was looking to propose a set of mechanisms and rules to address OSS security.  

However, he said regulation alone would not resolve everything. Organisations still needed to figure out how to achieve better security in a cost-effective way.

This, Liu said, was where the wider ecosystem could collaborate. He added that Scantist recently ran a bug bounty programme in which participants were encouraged to use software composition analysis to find and fix vulnerabilities.

The aim here was to promote OSS security as well as push greater awareness amongst small and midsize businesses, Liu said. Scantist offers a software composition analysis tool, called Thompson, that is touted to help enterprises manage security and compliance risks of their open source libraries.

When contacted, Singapore’s Cyber Security Agency (CSA) said it currently had no plans to impose security regulations related to the use of open source software. Instead, the government agency advocated the adoption of zero trust principles and for all Singapore organisations to build their cyber defences based on this framework.

A CSA spokesperson told ZDNet that OSS security should be assessed as part of a company’s efforts to reduce risks from their supply chain partners. To help enterprises do so, CSA introduced several measures including programmes for CII (critical information infrastructure) sectors and smart consumer devices.

For instance, the CII Supply Chain programme was announced last year to outline processes and best practices that could help CII operators and their vendors manage supply chain risks and beef up their supply chain cybersecurity posture.

CSA earlier this year also introduced Cyber Essentials and Cyber Trust certification marks that certified cybersecurity measures organisations adopted for their products and services. The initiative aimed to provide “visible indicators” of businesses that prioritised cybersecurity as well as boost the level of trust and confidence amongst organisations that transacted with certified players, the CSA spokesperson said.

He added that the Cybersecurity Labelling Scheme, which rated smart devices according to their levels of cybersecurity provisions, with Level 3 and 4 the highest two categories. He noted that products certified under the Singapore Common Criteria Scheme would have gone through binary analysis to identify known vulnerabilities in OSS.

According to the Synopsys study, the Internet of Things (IoT) industry was amongst the highest user of open source, with 100% of codebases in the sector containing open source codes. However, 64% of IoT codebases were found to contain vulnerabilities. 

Martin noted that open source was never meant to compete with traditional proprietary code. “Today, many software developers and entities are looking to integrate open source with existing operating systems and applications,” he said. “This is different from incompatibilities that can occur due to differences in elements such as data formats. Ultimately, open source integration can happen so long as the development is there.”

He added that even the most regulated industries, such as the public sector and financial institutions, were adopting the concept that open source was the best way to foster innovation, recruit, and retain the best talent, and future-proof a technology platform.

RELATED COVERAGE

• Singapore talks up OT security, looks to add medical devices to labelling scheme
• APAC firms need to build trust, brace for more third-party attacks
• Zero trust, basic cyber hygiene best defence against third-party attacks
• Singapore firms see high rate of security incidents, but struggle to respond promptly
• Open-source security: It’s too easy to upload ‘devastating’ malicious packages, warns Google
• Blind trust in open source security is hurting us: Report