Garrett O’Hara is the Chief Field Technologist, APAC at Mimecast having joined in 2015 with the opening of the Sydney office, leading the growth and development of the local team. With over 20 years of experience across development, UI/UX, technology communication, training development and mentoring, Garrett now works to help organisations understand and manage their cyber resilience strategies and is a regular industry commentator on the cyber security landscape, data assurance approaches and business continuity.
Open-source software is used every day in every industry. Rather than writing pieces of code from scratch, which can be expensive, time-consuming and unnecessary, developers can instead source them from publicly available open-source libraries. This is a godsend, helping under-pressure dev teams hit deadlines and organisations save time and money.
Using open-source software is common practice in the software industry, and open-source code can be found in everything from internet browsers to IoT devices. However, this practice opens the door to risk, because open-source software often contains serious vulnerabilities. Whether problems result from a simple mistake or carefully planted malware, the damage can be widespread and devastating: the Log4Shell vulnerability in the Log4j library affected millions of devices, more than 90% of enterprise cloud environments and was described as “bordering on the apocalyptic”.
Such is its usefulness that it’s hard to see many organisations entirely doing away with open-source code. But measures to mitigate and manage it can make a real difference.
Why open-source code can be a security-killer
Open-source code’s value to development teams has made it almost ubiquitous, and it’s continuing to grow. According to one analysis, open-source software amounts to 70–90% of code in web and cloud applications.
Around two-thirds of codebases contain high-risk vulnerabilities. While some are rapidly patched, others lurk in the shadows for far too long. Moody’s found that it could take organisations five years to fully resolve Log4j issues, and noted one vulnerability in devices running on Linux that went undetected for 12 years.
Vulnerable libraries may pull code from other vulnerable libraries, creating a cascade of weaknesses that can be hard to manage. Even vulnerabilities that have been fixed can cause problems if they are reintroduced by library versioning. Many issues come from human error, but others are straight-up malware. Malicious code may have been written in from the start or added by later updaters.
Open-source attacks are appealing to ransomware gangs and other bad actors because they can spread as widely as the code itself. Malicious changes can be carefully hidden, and if code is not reviewed stringently, their impact can be devastating: the Equifax data breach of 2017 saw the records of 163 million people compromised in an exploit of the Apache Struts framework.
Open-source code is hard to live without
Organisations will struggle to avoid all exposure to open-source code. Virtually all modern software uses it in some form, and retooling all your applications to avoid open-source components would be hugely expensive and time-consuming.
The question, then, is how to live with and mitigate open-source software’s risks. the only way to do that is by setting up processes to scan code, test it and fix any vulnerabilities. Organisations should also set rules for future engagement with any open-source code based on their assessment of risk vs reward.
Scans and tests can weed out malware
Static analysis scanning is a great first step in assessing open-source code for vulnerabilities and malware. Scanning all open-source code used by an application will identify most threats. It is best undertaken before an application goes live, and should be integrated into the build environment as part of the Continuous Integration System where possible, at the point where open-source libraries are pulled into a project.
Ways of picking up any remaining threats include further testing in a sandbox environment, plus additional code reviews, dynamic analysis and unit testing.
Dealing with the vulnerabilities
As always, there’s a trade-off between the level and types of vulnerabilities an organisation will deem acceptable and the cost-benefits of using open-source code. Addressing vulnerabilities is often pressurised due to deadlines, so it’s essential that there's close collaboration between cybersecurity and developer teams from the get-go. It can be tempting to build first and worry about security later, but that just makes any security gaps that much harder to fix.
The process is much more straightforward if your organisation has already set rules for security practices in the development process. Security policies should cover issues such as:
how decisions governing open-source code vulnerabilities are made
the policy regarding testing of your own (non-open-source) code
which stakeholders are involved
tracking and logging the origins of individual pieces of code
warnings for developers who access vulnerable libraries
certification and accreditation programs governing code that’s deemed to be a risk
Each CISO will have different approaches here – controlled programs will significantly reduce risk, but can make builds slower and more expensive. If you are to enjoy the benefits of open source, you need to make tough decisions about how to manage it safely.
Open source: a great resource with real risks
Open-source code is a great resource that can make developers’ jobs far simpler and enable them to build complex solutions much faster. Companies right across the globe are freely using open-source software, but far too many of them are doing so without adequate tests and scans. The resulting vulnerabilities have led to breach after breach.
There are some measures afoot to protect open-source code, with Linux raising $10 million to support and expand the Open Source Security Foundation (OpenSSF). But the risk burden falls mostly on individual organisations. If you use open-source code it’s vital you have a clear, proactive policy around the scanning, testing and fixing of code. If you don’t, your use of open-source code could result in hackers declaring open season on your organisation.