How to Triage Open Source Software Risk

At the end of February, I reviewed top-level takeaways from Flexera’s 2020 State of Open Source License Compliance Report. Taking a closer look at the report’s findings, my last post evaluated how vigilance about open source management can help software businesses be more agile. Here, we’ll look at how to prioritize and work through risk factors that may impact your business. Following this post, my next blog will explain the differences between standard and forensic audit analyses. To stay updated with these and other practical takeaways for moving your open source management program forward, subscribe to the posts by clicking the “subscribe” link at the top of this page. 

I have a family friend who works in an emergency room. We’ll call him “John” for the purposes of this blog. John’s a physician’s assistant (PA) at a hospital, where he deals with all sorts of medical issues. The stories he tells are often hilarious, frequently gross, and sometimes frightening. Of course, when someone shows up after a major injury or with an acute illness, the ER is the right place to be. Other times, however, patients show up for what turns out to be minor issues. For example, a chronically aching back is a very real concern that deserves considered attention, but it isn’t likely to get top priority in an emergency medical setting; it may be better served by a different type of medical office that can evaluate the root cause and provide a thorough treatment plan. Triage—the process of evaluating the urgency of needs in order to determine the order of treatment—provides clear guidance on how to prioritize demands and address the most pressing issues first.

The triage on display at any ER is a good example of how to prioritize and treat medical risks. Also, it offers a good model for addressing the potential risk posed by open source software. I’d like to take a deeper look at the priority levels Flexera assigns to license compliance and vulnerability detection and the output of issue detection findings related to each level. 

Open Source Software Issue Detection Priority Levels

Using different methods, the Flexera audit services team goes through different evidence types with auditing a codebase. The evidence types are triaged in order to discover the high priority issues first. 

  • P1: Going back to our ER scenario, P1’s are like the injuries that get a patient in to see the ER doc STAT. These high severity issues represent critical IP or security threats and should be remediated first—and urgently. In one example of a P1 issue, the MongoDB database was under the on-premise product being shipped. In it was a GNU Affero General Public License (AGPL), which carries considerable obligations. The company had to choose whether to continue using it, go with a commercial option, or possibly replace MongoDB with another permissive license (a P2 or P3 license). Flexera’s report documents options which enable companies to work with legal to determine the correct processes and approvals for remediation most suited to individual customer needs.
  • In a second P1 example, an item required consideration of how much risk was acceptable. Proprietary Linux Kernel Modules were running in Kernel space (where all the GPL code is). The proprietary code running in the same space as the GPL code created an issue without a real solution. The decision needed to be made whether or not to accept the associated risk. Flexera can also highlight the severity of issues and how immediately remediation must happen. In an M&A event, for example, some issues should be resolved before the target company is purchased, while other issues can be remediated by the acquiring company post-close.
  • P2: You might go back to see your primary care physician for additional advice about certain issues; that’s the case with P2 issues, as well. Once the most urgent P1 issues are remediated, P2 issues (often related to commercial and vanity licenses) require a plan for resolution. Here, the biggest concerns come from unknown license items. The risk of unknown licenses is that they actually could be P1-licensed items. If a customer has an unknown icon that’s visible to the end user, additional care is necessary. You should always have an icon set for which you know the licenses. If it is a commercial component, you don’t want to be caught without a commercial license or with an expired license in your code.
  • P3: Just as a doctor might recommend an ongoing plan to help resolve an underlying health risk, P3 issues require a systemic approach to remediation. P3 issues are low-risk hygiene issues related to permissive license issues (such as those under Apache, BSD, and MIT). Frequently, the main concern here is to be certain that all files with third-party code contain headers and give attribution (e.g., for licenses and third-party notices) to the owner of the code. Flexera’s audit reports identify where these items are missing. While these issues shouldn’t be ignored long-term, remediation doesn’t need to be instant.

The Upside of Urgency: Value

An organization that has a culture focused on license compliance, IP protection, and best-in-class open source software management not only protects itself from legal complexity, but can harness real savings, as measured both in dollars and reputation. If open source software components aren’t used in accordance with the open source licenses, the impact on an organization’s bottom line can be huge—on the order of millions of dollars.

In Flexera’s upcoming webinar, “Insights and Trends to Evolve Your Compliance and Security Practices,” my colleague David McLoughlin and I will address the value of a robust open source management program—and how it benefits you, your business, and your customers. Register now—either to attend the free, live event on March 19 or to receive a recording of the webinar.

Read the report.

Leave a Reply

Your email address will not be published. Required fields are marked *