Open Source Security Standards
Open source security solutions have many benefits, one of the main being the source code is available to anyone to review, which is good for security. However, there is no guarantee that open source security standards have been followed when the code was created.
Oftentimes, code is written and made available in online repositories such as GitHub to solve a specific problem or perform certain functions. While the code may achieve its objectives perfectly well, there could be vulnerabilities in the code that could be exploited. If that were to be the case, anyone that incorporates the code into their own business applications would be incorporating a potentially exploitable vulnerability.
The argument in favor of open source is since the code is public, many eyes are looking at the code. That means vulnerabilities are more likely to be identified than with proprietary software solutions that have the code hidden from view and only a small number of individuals conducting code reviews. While that is often the case with popular open source projects with highly active communities, that may not be the case with all open source code. It is possible that while the code is public, it is not regularly reviewed and checked for errors.
The risks of using open source code in applications have been highlighted recently with the discovery of several vulnerabilities in the open source Java-based logging utility Log4j. Log4j is ubiquitous in cloud servers and enterprise software, so any vulnerability impacts huge numbers of enterprise applications and cloud services.
A remote code execution flaw, dubbed Log4Shell, was discovered in December 2021; and, shortly after being made public, it was exploited by a wide range of different threat actors to steal data, install malware such as cryptocurrency miners and ransomware, and gain persistent access to applications and systems for espionage purposes. The flaw, which has a CVSS severity score of 10/10, is widely regarded to be one of the most serious vulnerabilities to be discovered in the past decade due to the ease of exploitation and the sheer number of organizations affected.
The open source community is usually quick to develop patches or mitigations to prevent exploitation of zero-day vulnerabilities, and this was the case with Log4Shell. The problem in this case is many companies did not follow open source security standards and best practices when incorporating Log4j into their applications.
This means it is not clear whether and where Log4j has been implemented in many cases. Scanners were quickly developed by cybersecurity firms and the open source community to detect where Log4j had been implemented, but these scanners often fail to detect the code embedded several layers deep in applications.
Log4Shell has emphasized the importance of following open source security standards when developing software and ensuring contributors to open source projects follow those standards. There is, however, a tendency for popular open source projects not to implement new open source security standards so as not to discourage contributors, but it is vital to do this to mitigate against serious vulnerabilities such as Log4Shell.
Best Practices to Follow When Using Open Source Components
While there are clear advantages to using open source code when developing applications, there can be quality and security risks associated with open source. Before using any open source component it is wise to assess the total cost of ownership, as while it may seem like the best choice initially, over time that may not prove to be the case. If the decision is made to use open source, it is important to make sure that the open source software meets the organization’s software quality standards and open source security standards have been followed when creating the code.
One of the most critical steps to take when using open source components is to keep track of all components used and where they are used. Any developer may incorporate open source code in an application; but, if no record is kept and the developer person leaves the company, the failure to document the use of open source components could result in code not being updated.
The same is true for dependencies. Direct dependencies are open source libraries that software makes calls to; and while these calls may be logged, there might also be transitive dependencies, which are dependencies of dependencies. You should have strict policies and procedures governing the use of open source software, a detailed inventory of open source code should be maintained – including direct and transitive dependencies – and there should be comprehensive documentation for each component. It is then important to conduct regular security assessments to identify and patch known vulnerabilities.
Keeping track of vulnerabilities as they are discovered is not always easy, since they are not always published in one location. That makes it difficult for security teams to keep track of vulnerable components. One solution is to use a dependency checking tool, such as the one developed by the Open Web Application Security Project (OWASP). This tool can be used to check project dependencies to determine if they contain any known vulnerabilities.
It is also important to monitor for open source components that are no longer supported by an active community of users, as this may mean vulnerabilities are no longer identified and addressed. When no longer supported, it is recommended to switch to equivalent components that are being more actively developed, as vulnerabilities are more likely to be found and patches released.