2023 is now in full swing. But before getting too far into the new year, we decided to take a step back and reflect on the way open source management has changed over the past months — and how it will continue to evolve in the coming ones.
In this article, we’ll explore trends, predictions, and observations related to mission-critical open source management procedures. These include using SBOM data, automating open source license compliance, maintaining visibility into the composition of your software, and more.
This blog is based on two primary data points:
- A small survey of around 100 IP counsel and open source license compliance professionals (conducted in 2022)
- Conversations with FOSSA’s customer success and product teams, including senior product manager Cortez Frazier Jr.
1. SBOMs will continue to be a priority — but with more attention paid to understanding and operationalizing SBOM data
Both the results of our IP counsel survey and numerous customer conversations lead to the clear conclusion that organizations of all stripes are prioritizing SBOMs. This isn’t a huge surprise — SBOMs have several vital use cases, including software supply chain security, regulatory compliance, and sales enablement, among others.
But for 2023, we’ve heard a growing number of organizations indicate that they will prioritize taking steps to better operationalize SBOM data — which has historically been somewhat difficult for a few reasons:
- Modern applications are built with dozens upon dozens of different software components, which means SBOMs tend to be complex and hard to decipher, especially without the right tools.
- The increasing standardization of machine-readable formats (and the rise of SBOM tools) can make ingesting SBOM data easier. But, even then, it can still be difficult to interpret certain SBOM elements, such as the relationships between different dependencies.
- Not all SBOM tooling has sufficient programming language coverage, and some tools don’t integrate well with development pipelines.
- Certain SBOM formats have better support for vulnerability data than others.
We expect organizations to prioritize addressing these challenges in 2023. This includes more discussions (and with greater urgency) around where to add SBOM tooling (e.g. to a centralized VCS or central CI system), which part of the SDLC tooling should run (e.g. the build process), and how to import (and use) SBOMs for third-party applications.
Added FOSSA senior product manager Cortez Frazier Jr.: “The intersection between consistent SBOM generation and enriching SBOMs with vulnerability or exploitability data is where organizations begin reaping real-world value from SBOMs.”
2. Current license compliance processes are manual and time-consuming — which will continue to encourage the gradual shift to automation
One of the more eye-opening results from our IP counsel survey was the amount of manual work that many organizations still devote to open source license compliance management.
For example, 58% of respondents said they were still generating attribution notices manually. And, only 26% of respondents have fully automated license compliance policy implementation.
Often, this work falls on in-house counsel. The majority (73%) of survey respondents said that legal teams are ultimately responsible for generating attribution notices.
Historically, one of FOSSA’s top use cases has been helping organizations shift from manual to automated open source license compliance. And, although there are budgetary considerations that may slow the transition to automated compliance for some companies, we do continue to hear that this is a priority for many, regardless of industry or region.
“Given the amount of license compliance risk discovered in direct and transitive dependencies, a manual approach is not only time-consuming but likely inaccurate as it pertains to total component usage,” Frazier Jr. said.
3. Visibility into software composition remains a challenge
The increase in SBOM adoption hasn’t solved all challenges related to understanding software composition. Two of the biggest are:
- Code scanning tools (and related processes) are geared toward direct dependencies. For example, 58% of respondents to our survey said that their organizations limit open source license compliance to direct dependencies
- Code scanning tools (and related processes) don’t always make it easy for organizations to quickly identify whether — and where — they are using specific open source packages.
Perhaps the biggest practical concern stemming from this lack of visibility relates to how organizations respond to zero-day vulnerabilities. When critical-severity vulnerabilities (like Log4Shell) are disclosed, it’s vital that organizations quickly identify where they are using vulnerable versions of a certain package (and then successfully upgrade to the next safe version).
But this can be easier said than done, especially for large enterprises with extensive product lines. And, it can be especially tricky if attackers successfully breach your environment and introduce new, malicious packages.
“Package manager dependency conflict resolution only exacerbates lack of visibility as packages defined in your manifest files may be relatively different than those included at build time,” Frazier Jr. said.
4. Continuous monitoring of your will become even more of a priority — even if it comes at the expense of restrictive early enforcement
The great tool in any risk professional’s tool belt will always be an accurate and up-to-date asset inventory, whether that be physical, or, in our case, digital assets.
This is important for many reasons, including the fact that an up-to-date inventory enables organizations to continually monitor their environments. In this context, we define continuous monitoring as real-time component analysis (SCA) during every build or source phase of your organization's SDLC(s). As new exploits impacting existing open source packages appear, an organization's ability to accurately assess total attack surface is critical to any threat modeling or mitigation activities.
Along those lines, we expect teams to increasingly take precautions to avoid processes or activities that could get in the way of continuous monitoring. One example of this is the tendency to implement restrictive policies when using new software composition analysis tooling. Although the goal of these policies is admirable, in practice, this approach may incentivize development teams to delay onboarding their repositories until these high-risk components are pre-emptively eliminated. And, this may have the unintended consequence of hiding, rather than reducing, risk.
Instead, in the interest of enabling continuous monitoring, we expect risk professionals to prioritize:
- Achieving complete coverage of all repositories within your target risk profile (e.g. distributed software, externally facing apps, or apps with critical IP) to build an accurate asset inventory
- Applying codified risk identification policies at scale to surface existing software supply chain risk
- Curating metadata associated with high-risk component groups as defined by your organization’s internal policies (e.g. denied licenses in direct dependencies for distributed projects or critical vulnerabilities in direct dependencies with a patch available)
In addition to avoiding processes that could get in the way of an accurate component inventory, we expect more organizations to consider tooling to facilitate continuous monitoring. And, to that end, we at FOSSA are currently developing a suite of package observability tooling that will make this much easier.
“By prioritizing component coverage over restrictive enforcement, risk professionals will reduce internal tooling implementation friction while defining an accurate foundation for any mitigation or forensic events,” Frazier Jr. said.
You can get more information about FOSSA's open source management tools by visiting our platform page or reaching out to our team.
