What’s in your code? As the use of open source grows, it’s essential to be proactive in efforts to identify and mitigate risks. Alex Rybak, senior director of product management, Revenera, shares five steps to help ensure greater transparency and trust in your open-source program.
As reliance on open-source software (OSS) grows, the risk plane expands. One of the greatest risks isn’t the code itself but a lack of knowledge of what’s in the code.Â
Recent software supply chain researchOpens a new window by Revenera found that 61% of scanned codebase files are attributed to open source components, but companies are only aware of a small fraction of the open-source components they’re using. Too many organizations simply aren’t aware of their software supply chain.
When a vulnerability is discovered, minimizing disruption is key. To better identify and mitigate risk, companies must take a proactive approach to managing open source, knowing what’s in their code and complying with all associated licenses.Â
Five Steps to Smarter Open Source Management
The following five steps can help you begin to get your house to ensure greater transparency and trust in your open-source program.
1. Don’t wait until the last minute
Being proactive means planning ahead to create a complete ecosystem for OSS management, staying up-to-date about open source components, the associated licenses, and reported security vulnerabilities â€“ then sharing this information with various stakeholders across your organization. This begins by selecting the right set of tools to identify all components used across your portfolio of products and track those that may carry software supply chain risks within your organization due to license or security compliance issues.Â
Software composition analysis (SCA), for example, supports the creation of a complete and accurate software bill of materials (SBOM) for all of your applicationsâ€”an ingredients list that details all elements in your software applications. Having this source of truth supports better visibility into the impact of licensing changes or newly discovered security issues and allows organizations to comply with license obligations and industry best regulations and best practices.
If you don’t yet have a comprehensive policy for all third-party software (including OSS) and the ability to create a complete and accurate SBOM, now is the time to create one. If you already have one, further refine it by identifying and closing gaps. For example, make sure your process allows you to efficiently scale to manage the entire software supply chain, with inclusions from upstream suppliers and delivery of compliance artifacts to downstream partners and customers.Â
2. Make the process continuous
Doing a last-minute audit of your code just ahead of a release isn’t sufficient or, for that matter, efficient. Instead, manage your open-source program continuously. Integrate it into your development toolchain so that your applications are assessed at each point of the devops cycle, starting with the artifact repository, to the integrated development environment (IDE), during code check-in, as part of your build pipeline, and during deployment of the application. A continuous scanning strategy helps you keep up with the volume of third-party code that your organization ingests as release cycles speed up and allows you to operate on smaller sets of changes as code churns.
Hosted by the Linux Foundation, theÂ OpenChain Project maintains the international standard (ISO/IEC 5230:2020)Â forÂ OSS license compliance. The program’s main elements include defined roles and responsibilities; adequate training; a documented OSS policy; a process to identify, review, and remediate OSS components; preparation of compliance artifacts to comply with license obligations and industry regulations; and community engagement.
3. Set up your team for success
Over the past few years, there’s been a shift in responsibilityâ€”to the software development and security teamsâ€”for much of the work of managing open source. However, many of these individuals have not received proper training in license compliance and OSS security management as part of their career development. It’s unreasonable to expect a quality outcome from someone who has not been adequately set up to succeed. Make sure you invest in appropriate training that covers general awareness of OSS topics, including common license types, obligations, restrictions, and details about your organization’s open source and security policies and procedures.
To set up your business-wide team for success, begin by thinking through roles, responsibilities, skillsets, and the capabilities you have in-house. As you assign responsibilities to developers and both technical and non-technical leaders, set expectations so that staff has a clear understanding of what’s being asked of them and the bigger â€œwhy,â€ particularly as they take on new duties that may be layered on top of existing full-time positions. Be clear about what you’re asking of them, whom they can turn to for assistance, and who is ultimately accountable for the process. Finally, be sure to provide ongoing training as your policies and broader market conditions change and as new knowledge is required.
4. Understand the role of automation
Automation is a great tool for reducing manual work, increasing turnarounds, and reducing decision-making errors, and, in turn, making the process more consistent. It does have some drawbacks. Applications are continuing to grow both in the volume of open source and other third-party components and complexity. Often there is a mix of technologies within an application, some of which cater well to automated discovery and others not as much.Â
It is essential to understand your position on the quality vs. time vs. resources ratio. This needs to be assessed by each team based on their level of risk tolerance. Some level of human involvement will always be necessary for certain areas of risk mitigation. Going with a push-button approach may be completely appropriate for some products but not for others. Be mindful of the balance and make the decision a conscious one.
5. Don’t forget to look back
Proactive open source management requires learning from past experiences. As Winston Churchill once said, â€œnever let a good crisis go to waste.â€ Whenever a new security vulnerability is announced in the open-source world, and teams scramble to identify if the various exploits impact them, take the opportunity to look back at former issues. For example, vulnerable versions of OpenSSL, which were responsible for the Heartbleed security vulnerability back in 2007, are still pervasive in many products being released today. While everyone made great efforts to find and patch Log4j to address the Log4ShellOpens a new window security vulnerability in late 2021 and early 2022, new exploits and subsequent patches will continue to be released. Make sure your teams keep up with material patches and avoid the pitfalls of a one-and-done approach.
Keeping these steps in mind would help you navigate the complexities of the risk plane open source opens up while leveraging all that OSS offers.Â