Open source software is ubiquitous. It has become an unequaled driver of technological innovation because organizations that use it don’t have to reinvent the wheel for common software components.
However, the ubiquity of open source software also presents a significant security risk, as it opens the door for vulnerabilities to be introduced (intentionally or inadvertently) to the consumers of open source software products. The recent race to address major vulnerabilities in the widely used Log4j code library is the biggest sign yet that risks within the open source software environment must be addressed.
The Open Source Appeal for Cybercriminals
The open source attack method is appealing to bad actors because it can be widespread and highly effective. Attackers can use various methods to obfuscate malicious changes contributed to open source projects, and the rigor in reviewing code for security implications can vary widely across projects. Without stringent controls in place to detect these malicious changes, they may go unnoticed until after they’ve been distributed and included in software across numerous companies.
Attacks on open source code can vary in size and the entities they affect. For example, last July, researchers found nine vulnerabilities affecting three open source projects — EspoCRM, Pimcore, and Akaunting — which are frequently leveraged by small and midsize businesses. What’s more, the 2017 Equifax data breach, which affected the personal data of 147 million people as a result of a vulnerability in the organization’s open source code, is a clear example of how vulnerabilities can be exploited by bad actors and create damaging effects throughout.
Never Going to Give You Up
CISA has said that hundreds of millions of devices were likely affected by the Log4j vulnerability. Given the magnitude of this incident, many enterprises are likely analyzing whether to leverage open source code for future developments.
However, forgoing open source altogether isn’t realistic. All modern software is built from open source components, and rebuilding those components without open source would require massive investments in time and money to produce even minor applications. Over 60% of websites worldwide run on Apache and Nginx servers, and 90% of IT leaders reportedly use enterprise open source code regularly.
Testing and Protecting Your Software
Instead of avoiding open source, a more realistic approach is for security and software teams to work together to develop policies and a process for testing applications and software components. Organizations should think about this as a three-part process. It requires scanning and testing code, establishing a clear-cut process for addressing and fixing vulnerabilities as they arise, and creating an internal policy in which rules are set for addressing security issues.
When it comes to testing the resilience of your open source environment with tools, static code analysis is a good first step. Still, organizations must remember that this is only the first layer of testing. Static analysis refers to analyzing the source code before the actual software application or program goes live and addressing any discovered vulnerabilities. However, static analysis cannot detect all malicious threats that could be embedded in open source code. Additional testing in a sandbox environment should be the next step. Stringent code reviews, dynamic code analysis, and unit testing are other methods that can be leveraged. (Dynamic analysis refers to examining the software program while it’s currently running to identify vulnerabilities.)
After scanning is complete, organizations must have a clear process to address any discovered vulnerabilities. Developers may be finding themselves against a release deadline, or the software patch may require refactoring the entire program and put a strain on timelines. This process should help developers address tough choices to protect the organization’s security by giving clear next steps for addressing vulnerabilities and mitigating issues.
The policy-change step should create a documented plan for how all decisions will be made moving forward and which stakeholders should be involved throughout the process. Additionally, organizations can implement multiple controls for their open source components, such as certification and accreditation programs. However, remember that this will add additional overhead costs and slow down the development of open source projects.
Defending Open Source Against Future Attacks
The industry at large is taking note of the need to further protect open source code. The Linux Foundation announced in October it raised $10 million alongside other industry leaders to identify and fix cybersecurity vulnerabilities in open source software and develop improved tooling, training, research, and vulnerability disclosure practices.
In addition to industrywide efforts to protect software built on open source code against cyber threats, organizations must also take an internal proactive approach to their defense strategy. This should include implementing testing and control procedures for both their own code and the open source code on which they rely. Organizations must also develop internal policies and guidelines that recognize the risks from using open source software and identify the controls to be used to manage that risk. Doing so will allow them to continue leveraging the benefits of open source code while creating an environment that is resilient against future attacks.
Source: www.darkreading.com