Organizations are increasingly relying on open source code. Many enjoy the convenience of using open source code to quickly innovate or develop services without the tedious process of developing their own code, but there is a catch: open source code can turn into a security nightmare for organizations.
On the eve of 2022, a zero-day vulnerability — Log4j — was exploited by hackers and put organizations’ software and web applications, as well as their critical data, at increased risk. What made this attack so far-reaching is that the vulnerability originated from widely used open-source code.
This points to a larger problem: threat actors rely on the subversion of open source for malicious purposes. Often in the case of Log4j and other software such as EspoCRM, Pimcore and Akaunting, they are able to capitalize on the inherent vulnerabilities associated with this code and remain undetected. As an industry, we often think that vulnerabilities in open source code will be easy to spot, but that’s not the case – Log4j was put into production in 2013 and no one noticed any issues until it is already too late.
Open source is a double-edged sword
Open source code can be an incredible resource for organizations. At its core, it’s out-of-the-box software that helps teams reduce development time. This accelerates innovation and allows developers to build and deploy software relatively quickly. In addition, this code is supported by a community of developers who give their time. This means that new features can be released and bugs can be fixed by the community at no cost to the developer. It is this extraordinary advantage that also poses as a security risk.
While there are many benefits to using open source code, there are also risks associated with its use. For example, open source can only be developed based on community involvement. If the community loses interest in the project or if key people are called to work on another project, the development will stop. Additionally, bugs can be overlooked because developers assume it is the responsibility of the community to locate and fix them. Although many hands are often doing light work, this is a common problem with group work that does not have clear processes in place to ensure a consistent product.
There’s also a very common misstep that I see organizations make when it comes to open source. While many of them rely on open source code, they don’t consider the code their own and often don’t apply the same security checks they would apply to their own natively built code. This means that open source libraries often escape security testing and code reviews, creating an environment in which bugs and security vulnerabilities can be built into a product at a fundamental level.
Come together to secure open source code
As an industry, we can take steps to better secure our open source code from malicious actors. To start, if you use a code analysis tool, analyze all the open source libraries you use. I also encourage developers to contribute to the project. If enough people are involved, building owners can implement these security measures themselves. Also, always make sure to check the security steps followed by the project before using it.
Ensuring security is built in from the start will help ensure that potential vulnerabilities are closed, and has the added benefit of helping your industry peers who rely on open source.
Solving Open Source Problems with Attacker-Centric Behavioral Analytics
Open source code and its associated vulnerabilities aren’t going away anytime soon. While government agencies, such as the Federal Trade Commission, provided guidance to reduce open source vulnerabilities, organizations can take additional steps to further mitigate threats.
Vulnerabilities may already be present in your code, and organizations cannot rely solely on security teams to find and manage these vulnerabilities. Protection begins with a review by their own engineering teams. Additionally, it is important to use a solution that will protect your organization from these inherent vulnerabilities and block any attempts to exploit your data. Using attacker-centric behavioral analytics is key to helping your organization mitigate these threats.
Signature-based defenses will often fail to protect your organization against exploits such as Log4j because attacks can be launched in multiple ways. Monitoring and detecting suspicious behavior over time will help identify different attack patterns so your organization can mount a stronger defense.
If the past two years are any indication, organizations should be on the lookout for an increase in cyberattacks. In 2022, I encourage you to start securing your code at the foundational level and together work to secure our ubiquitous open source code that we rely on so heavily.