Modern applications are dynamic. They’re distributed and they’re often born in the cloud. These applications can be developed on the fly, spun up and scaled quickly to meet evolving user and market demands—enabling a level of business agility that allows users to make quick, informed decisions in real-time and take advantage of opportunities as they arise.
Enabling this development velocity are tens of thousands of open source libraries–pieces of code that developers can include in their applications to perform a specific function without having to code it from scratch. Open source libraries prevent developers from having to reinvent the wheel and allow them to focus on their differentiated business logic. While efficient and a major time saver, open source software may be the biggest single threat to software supply chains today. Developers simply have too much faith in the integrity of free, open source code that they casually include and distribute with their applications.
Despite the operational benefits, the pressure to develop quickly shouldn’t expose the organization to increased security risks. Development teams need to rethink how they use open source software and take steps to ensure they meet the same security standards as other enterprise applications.
The Open Source Security Issue
The problem is that most open source projects are maintained by a small number of developers that contribute their time and expertise to build software components that can be reused by the community at large. However, these developers are volunteers who aren’t being paid for their time and effort, nor are they under the same pressure as enterprise developers to ensure there are no vulnerabilities in their code. They may also lack the level of enterprise security expertise necessary to protect applications from increasingly sophisticated attacks. Some may even be hostile to efforts to better secure their code if it means slowing performance or changing the user experience.
The result is that insecure code is increasingly making its way into enterprise applications that use these open source libraries. In fact, the Log4j vulnerability last year was due to a vulnerability in an open source Java logging library. Recognizing the national security importance of open source software, the Biden administration recently issued an executive order and met with cybersecurity professionals to better safeguard the federal government’s computer systems. The resulting recommendations included policies that would help prevent security vulnerabilities in open source packages, improve the process for identifying and fixing defects and reduce time to remediation for distributing and implementing fixes.
It’s imperative that the private sector take notice and make more of an industry-wide effort to secure open source software that makes up businesses’ most critical applications today.
Three Steps for Better Open Source Security in the Enterprise
The bottom line is that enterprises themselves need to take more responsibility for securing enterprise applications—especially as these applications rely more on open source libraries. They need to take a more proactive approach that spans the entire software life cycle, embeds security tools directly into development platforms and provides complete transparency into what makes up their most critical applications.
Here are three things organizations can do to make sure their open source software is secure:
1. Continuously conduct end-to-end application testing
Modern applications are constantly evolving—making it more imperative than ever to continually test for vulnerabilities throughout the entire software life cycle. Starting with the planning stage, security should be embedded throughout the process—providing developers with a solid framework for building secure code before it goes through testing. Once pushed, application security testing should continue as an automatic, built-in step when pushing code to production. DevOps and security teams should work together to ensure security is no longer an afterthought to feature development.
2. Embed enterprise security capabilities directly in development platforms
Forcing developers to take an extra step to ensure secure code when they’re already under pressure to push code quickly is a recipe for failure. Security teams must make it as easy as possible by integrating security controls directly into existing development processes. Standardizing security testing and controls during development makes it more likely policies are recognized, understood and followed.
3. Ensure transparency in every snippet of code you use
Complexity is the enemy of good application security. DevOps teams need to know exactly what makes up their applications—including open source libraries and their dependencies. The federal government is pushing the open source community to standardize a software bill of materials (SBOM). Similar to regulations that require hardware manufacturers to know where every part is sourced, this would force both open source developers and enterprise developers to take more responsibility for the code they include from other sources. That way, if a vulnerability is discovered in a library, enterprises could easily determine if they are at risk and take appropriate action to fully mitigate the issue as quickly as possible.
It’s Time to Take Greater Responsibility
Open source software enables the kind of development agility that makes businesses thrive, but open source also greatly expands enterprise threat surfaces—leaving many organizations at risk of a breach. Organizations need to take greater responsibility for the security posture of the open source libraries they use to speed application development. This requires end-to-end application testing throughout the entire software development life cycle; embedded security tools and controls in development platforms and processes and complete transparency into the open source software that makes up critical enterprise applications. This proactive approach will ensure that vulnerabilities such as Log4j are identified and patched quickly before threat actors are able to exploit them and compromise applications.
