Best Practices for the Adoption of Open Source Software
In a previous blog post, I discussed the differing perspectives security and development teams have about the use of open source components. Taking these perspectives into account, what is the best way to enable the use of open source components in your organization? Forbidding their use entirely is not a viable option and, in fact, would be detrimental to both developers and the organization as a whole in light of today’s rapid-fire development cycles.
To ensure competitive advantage, a modern enterprise is compelled to leverage open source software; however, this should not be at the expense of the security of the product. The following best practices maximize the benefit of open source software:
Patch management
A centralized patch management framework is vital to ensure that the most critical vendor patches are applied to your infrastructure in a timely fashion. The recent WannaCry attack was a stark reminder of the dangers of neglecting to manage patching. In terms of open source component patching, consider what happened with one healthcare organization when Heartbleed was disclosed. Although the organization was aware of the OpenSSL vulnerability, it was not able to find and update all versions of the component before hackers were able to breach it through the Heartbleed vulnerability. Cyberattackers move fast when they see an opening or become aware of a disclosed vulnerability, and you won’t be able to keep up. Only with a proactive approach will you have a chance of thwarting attackers.
Of course, the ability to patch, and patch quickly, depends on the visibility you have into open source component use. Consider technologies that help you keep track of which components are in use and where. For instance, Veracode Software Composition Analysis (SCA) helps you build an inventory of your open source components. Then when a big vulnerability hits the news, you can quickly identify which applications in your organization are vulnerable. Once you find a vulnerability in an open source component, you can immediately see whether the latest version of the component addresses it. This saves precious time as you’re formulating your action plan. You can also manually blacklist certain components, leading to an automatic policy audit fail for any application that uses it.
Prescribe a policy
Organizations will have varying degrees of risk appetite based on their market and maturity. It is important that an organization
Control your repositories
Modern IDEs are optimized to give developers access to the widest possible selection of open source libraries directly within their native environments. If such a development practice contradicts your policies, it may be necessary to bar access to such repositories, either by blocking access at the firewall level or, more pragmatically, providing an on-premises, cached version of known and approved software components. There are various commercial products that provide such a local cached version of popular repositories, allowing the security team to closely control which components (and hence which vulnerabilities) are being included in the final product. Additionally, the judicious use of local repositories ensures that only a single approved version of a component is used, rather than a myriad of different (and potentially vulnerable) versions.
Understand your software supply chain
Today, most organizations are not building all their software from scratch, but rather are both incorporating open source components into their code, and using applications purchased from outside vendors or outsourcing the development of code. With this influx of third-party software, it is easy to inherit both known and unknown vulnerabilities into your software supply. Using security testing tools (both static code analysis and software composition analysis tools) provides a high degree of visibility into inherent risk, and vendor contracts should be structured in such a way as to mandate a minimum security level for delivered software.
Understand how to remediate
An enterprise should continuously assess its risk from vulnerabilities within its open source and third-party components, and when new risk is detected (for example, a new vulnerability is disclosed), the security team should proactively work with the development organization to remediate. Best practices for remediation vary depending on component and product complexity. For instance, a simple "upgrade to the latest component" may introduce unintended regression if the component has changed significantly. A pragmatic approach is to determine whether the given vulnerability is actually exploitable, and if so, whether a closely matching non-vulnerable library is available that minimizes collateral impact.
Conclusion
Open source component use is here to stay, and is rapidly becoming the fuel that drives innovation in the modern enterprise. Yet this widespread use also creates systemic risk. In turn, every organization needs to understand the open source component use within their development teams and create policy and best practices that will keep innovation flowing without deteriorating security posture.
Get more details on the challenges surrounding, and solutions for, third-party software security in our new Third-Party Software Security Toolkit.
Related Posts
