The Industry Must Better Secure Open Source Code From Threat Actors
Build security in up front to secure open source code at the foundational level. Apply security controls, have engineering teams test, do code review, and use attacker-centric behavioral analytics to mitigate threats.
Organizations increasingly rely on open source code. Many enjoy the convenience of using open source code to quickly innovate or spin up services without the time-consuming process of developing their own code, but there's 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 threat actors and placed organizations' software and Web applications, along with their business-critical data, at an increased risk. What made this attack so far-reaching was that the vulnerability stemmed from widely used open source code.
This points to a broader issue — threat actors rely on subverting 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, there is often a belief that vulnerabilities with open source code will be easy to spot, but that isn't the case — Log4j was put into production in 2013 and nobody noticed any issues until it was already too late.
Open Source Is a Double-Edged Sword
Open source code can be an amazing resource for organizations. At its core, it's ready-to-use software that enables teams to decrease development time. This speeds innovation and empowers developers to relatively quickly stand up and deploy software. Additionally, this code is supported by a community of developers who volunteer their time. This means that new features can be released and bugs can be fixed by the community with no cost passed on to the developer. It's this extraordinary benefit that also presents as a security risk.
While there are numerous benefits to utilizing open source code, there also are risks associated with its use. For instance, open source can only be developed based on community involvement. If the community loses interest in the project, or if key individuals get called to work on another project, development will stall. Additionally, bugs may be overlooked as developers assume it's the community's responsibility to locate and fix them. While many hands often make light work, this is a common problem with group work that doesn't have clear processes in place to ensure a consistent product.
There's also a very common misstep that I see organizations take when it comes to open source. While many of them rely upon open source code, they don't view the code as their own and often don't apply the same security controls that they would to their own, natively built code. That means that open source libraries often escape security testing and code reviews, which creates an environment where bugs and security flaws can get baked into a product at a foundational level.
Come Together to Secure Open Source Code
As an industry, there are actions that we can take to better secure our open source code from threat actors. To start, if you're using a code scanning tool, scan all the open source libraries you're using. I would also encourage developers to contribute to the project. If enough people get involved, the project owners can institute these security steps themselves. Additionally, always be sure to check what security steps the project follows before using it.
Ensuring that security is built-in upfront will help to ensure that potential vulnerability gaps are closed, and has the added benefit of helping your industry peers who rely on open source.
Address Open Source Concerns With Attacker-Centric Behavioral Analytics
Open source code, and its related vulnerabilities, aren't going away anytime soon. While government agencies, such as the Federal Trade Commission, have provided guidance to reduce vulnerabilities related to open source, there are additional steps organizations can take to further mitigate any threats.
Vulnerabilities may already be present in your code and organizations cannot solely rely on security teams to find and manage those vulnerabilities. Protection starts with review by their own engineering teams. Additionally, it is important to utilize a solution that will protect your organization from these inherent vulnerabilities and block any attempts to exploit your data. Utilizing attacker-centric behavioral analytics is vital to help your organization mitigate these threats.
Signature-based defenses will often fail at protecting your organization from exploits like Log4j since attacks can be launched in a multitude of ways. Monitoring and detecting suspicious behavior over time will help to identify the various attack patterns so your organization can mount a stronger defense.
If the last two years are any indication, organizations need to be on the lookout for increased 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 upon which we so heavily rely.
About the Author
You May Also Like