Click to learn more about author Nicole Segerer.
Low-cost solutions. Enhanced productivity. Faster time to market.
These benefits of open-source software (OSS) are some of the driving factors behind its wide adoption. With open-source use also comes the need for users to minimize the risksrelated to third-party software. Using OSS and being license compliant is necessary in order to protect intellectual property (IP), minimize legal complexity, and secure real financial savings.
Risks related to OSS usage are worth monitoring. The 2020 State of Open Source License Compliance report analyzed how much open source is being used, how aware of that use companies are, and the prevalence of vulnerabilities and license compliance issues that are present in their applications. This 2020 report identified an average of 662 issues per audit project, including one issue per 32,600 lines of code scanned. Only 1 percent of these issues had been disclosed prior to the audit start. Nearly half (45 percent) of the vulnerabilities that were uncovered had a “high” rating on the Common Vulnerability Scoring System (CVSS). The average number of issues per project jumped dramatically over the previous year’s study — a trend that’s likely to continue.
Fortunately, best practices can guide open-source management and help ensure that it is being used securely. Consider the following steps for mitigating vulnerabilities and making the most out of your open-source usage.
1. Be Proactive
To monitor and minimize the risk of OSS, make a proactive, company-wide plan. First, set clear expectations for all stakeholders. An Open Source Review Board (OSRB) brings together representatives from varied departments (engineering, legal, product management) to establish policies and a reporting structure for open-source management. Stakeholder training ensures that all individuals involved are aware of the organization’s risk spectrum — and what’s expected of them. When license and security policies are clear, the entire staff — from software engineering teams, legal counsel, the CEO and CTO, and their teams — can be effective by knowing the plans and executing them. Remember, too, to involve vendors; proactively setting requirements for your supply chain can help strengthen your relationships and your code.
Next, set up systems to successfully act on your plans efficiently. Software Composition Analysis (SCA) is an automated process of evaluating OSS and supporting risk management, security, and license compliance. Automated software monitoring and scanning tools can streamline the process of evaluating open-source software compliance. Audits analyze third-party and proprietary software, providing detailed guidance on what compliance and vulnerability issues must be addressed. The results of automated processes are typically faster (and less stressful) than manual reviews.
Finally, be prepared to remediate issues when they’re found. Begin with the highest priority issues, then move through the remaining items. You and your customers, alike, will benefit from the resulting reduction in risk.
2. Prioritize
Not all open-source licenses are equal. Neither are the license obligation issues that code scans discover. Severity — and the resulting remediation needs — vary. Each of the thousands of open-source licenses carries its own obligations, rights, and terms. To best understand and manage the issues in your code, clear prioritization is essential.
The highest-priority issues, known as P1, are high severity issues. These include strong Copyleft compliance issues that involve the Affero General Public License (AGPL) or GPL; these carry significant obligations. P1 issues are at the top of the list of items that need to be remediated urgently; they represent a critical IP security threat. In the 2020 State of Open Source License Compliance report, 17 percent of license compliance issues fell into the P1 category.
After you’ve remediated P1 issues, move on to resolve P2 issues, which account for 5 percent of identified issues. These secondary priority issues are related to commercial and vanity licenses. Unknown license items are a major focus here. Why? Unknown licenses actually could be P1 licenses, increasing their significance. You should always know the licenses for your icon set — and never be caught without a commercial license or with expired licenses.
Finally, P3 issues are the risks that aren’t as immediately concerning but still need to be addressed. Think of these as low-risk hygiene issues and put a time-based plan in place to address. P3 issues, which represent 76 percent of license compliance issues, are often related to permissive licenses (e.g., BSD, Apache, MIT). A systemic approach to remediation can ensure that all files with third-party code include headers and provide attribution to the code’s owner.
3. Know Where to Look
If your open-source scanning plan isn’t in place or urgency is a priority, consider an open-source audit. Open-source audits examine your code, identify third-party and proprietary software, yield a Software Bill of Materials (SBOM), and call attention to issues that require updates or remediation. What type of audit is right for your organization depends on factors such as business needs, codebase size, company policy, market fluctuations, and threats.
The most commonly used audit services are standard audits. These are well-suited to reviewing and vetting code from external suppliers, collecting supporting materials for litigation efforts related to IP, analyzing an open-source software project or solution before its release, and ensuring compliance and security before reaching a particular development milestone. Through codebase scans, these audits identify the majority of explicit P1 licenses, binary files, copyrights, and exact matches.
Software companies that want to be very thorough in ensuring that they’re not taking on risk lean toward forensic audits, which provide a deeper analysis than standard audits. These audits, which discover 6 percent more issues per project than standard audits, provide a deeper look at all evidence types, including the materials scanned in standard audits plus emails/URLs, expanded search terms, and source code snippet matches and fingerprint analyses. Forensic audits go beyond looking at the file level; each line of code is evaluated, as is the non-explicit evidence. These audits are well-suited when additional caution is needed to, hopefully, prevent litigation.