In this interview, Alex Rybak, Director of Product Management at Revenera, evaluates issues related to the rapid growth of open source software usage and reflects on how to tap into its strategic advantages safely.
- Q. What’s the main draw of open source software (OSS)?
Open source software is a fantastic tool for engineering and software development teams. Incorporating OSS into a codebase can help organizations focus their development teams on core competencies, while offering a cost-effective approach due to shared development and maintenance costs and accelerating time-to-market by leveraging built pieces of functionality.
Particularly during uncertain times, open source software provides the ability to deliver new capabilities quickly. Being able to pivot is always important. It certainly was the case in 2020, as organizations everywhere adapted to the rapidly changing business needs driven by the COVID-19 pandemic, all while trying to stay on-track with (or even accelerate) their own digital transformation initiatives.
- Q. Why is OSS risky?
As the number of dependencies and their corresponding security vulnerabilities grow, it becomes increasingly critical for organizations to be fully aware of what’s in the software they’re using and passing along to their customers. Without full transparency into what third-party code, including open source, is in their products, they’re leaving themselves open to hidden security and compliance costs. Yet many organizations aren’t aware of the extent of the risk they face from open source dependencies.
The Revenera 2021 State of Open Source License Compliance report is our annual look at how OSS is being used. This year’s research found that 55% of scanned codebase files were attributed to open source, yet a mere 4% of the issues found through audits were disclosed in advance of audit start. This awareness gap leaves the door wide open to risk. Meanwhile, 1,959 issues, on average, were uncovered per audit project—a dramatic increase from the 662 found the previous year. Popular ecosystems such as PyPI, NPM, and RubyGems are bringing in many more dependencies than ever before. The average number of reported security vulnerabilities per audit, jumped from 45 to 89, year over year. 1 out of 8 issues was classified as a P1 severity; meaning it was either governed by a strong copyleft license and/or associated with high severity security vulnerabilities. These items typically require immediate remediation efforts.
Additionally, not all open source licenses are the same, meaning that they can grant a variety of rights while imposing a wide range of obligations. Development, security, compliance, and legal teams all need to be aware of which licenses and dependencies exist, to understand and address them. For example, weak copyleft licenses (20% of the scanned codebases in this year’s research) mean that while the software is free to use, there are potential mandatory obligations beyond simple attribution requirements. Depending on whether the open source package is modified along with how it is linked and distributed an organization may have to include some source code to comply with the license obligations. Strong copyleft licenses (12%) mandate that any distributed software that links or incorporates that code be licensed under compatible licenses and also carries a source inclusion obligation. Permissive licenses (63%) have minimal restrictions and are typically satisfied by properly attributing the work of the original author(s). The key to managing your risk starts with understanding which OSS components you are using across your portfolio of applications and keeping this list up to date as your code churns.
- Q. How can software suppliers improve their code hygiene and strengthen their security stance?
In short: a continues and automated open source management program is the most effective way to proactively monitor OSS usage. Such a program tracks code churn throughout the development process. It then addresses compliance issues, including security vulnerabilities. Having this in place can ensure that open source’s strategic advantages are being used effectively, while the risks are monitored and minimized.
A Software Composition Analysis (SCA) program catalogs the use of open source and third-party software, manages intellectual property (IP) and security risks, and helps operationalize an organization’s open source strategy, while providing increased transparency into the software supply chain.
One of the most important elements of an SCA program is producing and maintaining a complete and accurate Software Bill of Materials (SBOM). The SBOM provides software component transparency, which is critical to ensuring trust throughout the software supply chain. We’re also seeing federal agencies, including the Cybersecurity & Infrastructure Security Agency (CISA) and the National Telecommunications Information Administration (NTIA), put more emphasis on the SBOMas a best practice for software component transparency, ensuring security throughout the supply chain.
- Q. What’s one element of OSS management that’s often overlooked?
Having a unified and documented approach to open source management is key. Train developers in what you expect of them and in open source compliance and application security best practices. Have legal and product teams on board, as well. Develop your inbound and outbound corporate OSS policies, and make sure people are aware of them and have points of contacts to reach out to for guidance. Develop your guidelines for a review and remediation workflow, and apply it consistently through your organization.
Alex Rybak is Director of Product Management at Revenera (formerly known as Flexera’s Supplier Division), focusing on their Software Composition Analysis (SCA) solutions.
