Picture this: a new zero-day vulnerability has just been announced, sending ripples through the tech community. Your team is on the front line, tasked with a mission — find and fix this vulnerability across your organization. The first step? Pinpoint where this vulnerable package lurks. Traditional methods turn this into an odyssey — a fragmented, painstaking journey from one development team to another, inquiring, investigating, checking. The process is fragmented, slow, and inaccurate. 

For instance, in the wake of the Log4j vulnerability, many companies found themselves scrambling to figure out where Log4j was being used in their organization. They created war rooms and spent weeks collaborating with engineering leaders to find and fix the vulnerability.   

But it doesn’t have to be this way. Imagine a centralized, comprehensive inventory — a single source cataloging every package used in every project across your organization. With such a tool, the search for a specific package name or vulnerability becomes swift and simple. 

This vision is now a reality with FOSSA’s recently released Package Index. Designed for these critical moments, Package Index offers unparalleled visibility into your software supply chain, making it quick and easy to find any package or vulnerability across all projects in your organization.

How Package Index Enables Global Visibility

The discovery and management of packages and vulnerabilities across the entire organization has traditionally been difficult and time-consuming. FOSSA’s Package Index simplifies this, enabling several key benefits:

1. Comprehensive Overview of All Packages: Package Index creates a complete, detailed inventory of every package used across your organization’s projects. This is more than just a list; it's a dynamic, searchable database. Security teams can now instantly access a full record of packages, along with their versions, dependencies, and associated vulnerabilities. This level of detail is crucial for understanding the security and compliance status of your software assets.

2. Rapid Response to New Vulnerabilities: When new vulnerabilities are disclosed, Package Index allows for immediate, organization-wide searches using either package name or CVE (common vulnerabilities and exposures) number. Security teams can quickly identify which projects are using the vulnerable package and assess the potential impact. For example, Package Index can be used to find which projects in your organization may be using Apache Log4j. This capability dramatically shortens the time from vulnerability disclosure to mitigation, a critical factor in managing security risks effectively.

3. Block Packages Globally: With Package Index, it’s now possible to enforce package policies on a global scale within your organization. Security teams can block specific versions of a package, and this decision can be automatically applied across all projects. This ensures uniform compliance and security standards, streamlining policy enforcement and reducing the risk of inconsistencies or oversights.

“Package Index is super useful when customers are inquiring about a specific package or CVE. It’s really easy for our security team to use FOSSA to search for a specific CVE or package and get a very quick answer before going into the technical nitty-gritty of the CVE”

-Valentina Ditoiu, Senior Security Program Manager at UIPath

Get Started with Package Index

Current FOSSA customers can leverage Package Index in their workflow today. 

If you aren’t yet a FOSSA customer and are interested in Package Index, getting started is straightforward. You can sign up for a FOSSA premium account (recommended for smaller organizations) for immediate access to this feature, or request a demo (recommended for larger organizations) to get an in-depth look at how Package Index can help make your license compliance and security efforts more effective and efficient.

With the addition of Package Index, we are excited to continue enabling organizations in their use of secure and compliant open-source software.

Last month, the Enduring Security Framework (ESF), a working group that includes representatives from multiple U.S. government agencies (NSA, ODNI, and CISA) along with private sector partners, released a new document designed to help organizations jumpstart their SBOM programs and effectively manage risks related to open source software.

 “Securing the Software Supply Chain: Recommended Practices for Managing Open-Source Software and Software Bill of Materials” includes a range of guidance for both software developers and consumers. The report has four main sections:  

• Open Source Software Management 
• Creating and Maintaining a Company Internal Secure Open Source Repository  
• Maintenance, Support, and Crisis Management
• SBOM Creation, Validation, and Artifacts

The document builds on the U.S. federal government’s landmark 2021 cybersecurity executive order and the ESF’s software supply chain security best practices guides, which you can find at the bottom of this press release. 

In this blog, we’ll highlight four of our primary takeaways from the new OSS and SBOM management document, along with an analysis of why we think each is important. Please note that we don’t intend this article to be a comprehensive overview of the ESF’s recommendations; rather, we’re highlighting a few sections and takeaways that we view as particularly relevant to FOSSA users.

1. License Compliance is a Mission-Critical Part of Effective Open Source Management

As the report notes (in Section 5.1.2), SBOMs were conceived with open source license compliance as a primary use case. In fact, the SPDX bill of materials specification was originally announced as part of the Linux Foundation’s Open Compliance Program. Today, of course, many organizations utilize SBOMs for security and regulatory compliance reasons, but this shift hasn’t reduced the importance of open source license compliance.

On the contrary, enterprises of all types continue to rely heavily on open source to fuel application development, and organizations need to have a plan in place to maintain an inventory of their licenses and continuous compliance with licensing requirements — or risk the legal, reputational, and financial exposure that can come with non-compliance.

The report does highlight (Section 2.2.1) that managing compliance activities “may be a lot for individual programmers to track” (given the large volume of open source in most applications), but “organizations can provide tools to make this consideration easy or transparent for the humans at keyboards.” 

Our view is that automating license scanning and detection, attribution notice creation, and the implementation of license approve/deny policies are among the most important activities for enabling compliance at scale.

2. Customize SBOMs for Your Use Cases and Consumers

There are a lot of factors that contribute to SBOM usability. For starters, a high-quality SBOM needs to have accurate and up-to-date information, and it should include sufficient metadata to comprehensively describe the component. (The NTIA’s minimum required elements are a good place to start.)

But, as the report notes in Section 2.4, in cases where you intend your SBOM to be ingested by a third party, it’s also important that “care should be taken to ensure SBOMs are provided in a format that can be processed by their consumers without the loss of integrity…”

Section 5.1.1 echoes that guidance: “When creating an SBOM, consideration should be given on who is going to consume the SBOM and what formats are acceptable.”

In practice, the focus on making SBOMs usable for consumers starts with generating your SBOM in a machine-readable format (SPDX or CycloneDX). 

Another important consideration is customizing SBOM metadata to support its primary use case. For example, if you are producing an SBOM for a government agency, you must include the NTIA-required elements. If the SBOM consumer is an organization preparing for technical due diligence, you should include licensing fields. If security is a consideration, consider embedding (or linking to) VEX (Vulnerability Exploitability eXchange) documents with accurate state and justifications. And so on and so forth. 

The big-picture takeaway is that there’s no single SBOM format or standardized set of data fields that will be most useful to 100% of consumers, so it’s important to gather that information before generating and transmitting your bill of materials.

3. Go Beyond CVSS Scores to Prioritize Vulnerabilities

Traditionally, CVSS (Common Vulnerability Scoring System) has been the go-to for assessing and prioritizing open source vulnerabilities. The idea was that the higher the CVSS score, the greater the risk and the more urgent the remediation. 

However, CVSS isn’t the be-all, end-all. Although it communicates vulnerability severity, it doesn’t account for direct or indirect exploitability. Just because a vulnerability could have devastating effects doesn’t mean it’s actually likely to be exploited or is even accessible given the context of the vulnerable application. This is why relying too heavily on CVSS can lead to false positives and overload security teams with CVE alerts.

So, while CVSS is still an important part of vulnerability management programs, it’s best to include other inputs as well. Section 3.2 of the report highlights other frameworks worth using, such as the EPSS Scoring System; EPSS measures how likely it is that a specific vulnerability will be exploited in the wild, a dynamic determination given the persistence and ingenuity of threat actors.

4. Start Thinking About VEX

VEX (short for Vulnerability Exploitability eXchange) is the subject of frequent discussion in the report — it’s mentioned 61 times in total. Similar to EPSS, VEX is a potentially valuable tool in helping organizations understand whether vulnerabilities in their software are actually exploitable. However, VEX and EPSS differ in that VEX data is provided by the software supplier and based on internal inputs, while EPSS is a data model based on external factors. 

As such, VEX holds particular promise in helping SBOM consumers understand the security risks they’re inheriting from software suppliers. In other words, VEX could be key to unlocking many mission-critical SBOM security use cases. 

In a VEX document, the software supplier will annotate a particular vulnerability with information to help the consumer understand exploitability. VEX data fields include whether a product is affected by a vulnerability (“Status or State”), why the product is or isn’t affected (“Justification”), a detailed response to contextualize the justification (“Description”), and how to mitigate the vulnerability if the product is affected (“Recommendation”), among others.

The ESF guidance explains (Section 5.1.3) that “VEX provides additional context which may reduce the number of ‘false positive’ vulnerabilities that a vulnerability scanning (tool) would report against an SBOM due to the specific package instance.”

One of the challenges organizations seeking to adopt VEX currently face is that, as a relatively new standard, there’s still work to be done around standardization (e.g. which data fields to include in a VEX document) and automation (e.g. given the complex nature of modern applications, managing VEX with manual processes isn’t scalable). 

Despite these current barriers, it’s increasingly clear that security teams will be well served to start thinking about how to integrate VEX into their SBOMs (and develop processes for requesting suppliers to do the same). 

Section 5.1.3 of the report includes an example of how this might be done.

ESF Recommendations: The Bottom Line

The ESF’s report is a timely document that deals with several challenging and complex areas related to managing SBOMs and reducing the risks that can come from using open source software. I hope this article gives FOSSA users (and open source management/SBOM teams) a feel for the report and its focus areas, but I do encourage you to consider reviewing the document for a deeper dive.

Additionally, for more insights on these topics, consider checking out the following on-demand webinars:

• The Dos and Don'ts of Using SBOMs for Security
• Generating, Importing, and Managing SBOMs with FOSSA
• When "Open Source" Isn't Open Source

If there have been no recent code changes to your repository, you might assume that building an application is a static, reproducible process. But in modern applications that depend heavily on open source packages, this is not true. Package versions are constantly changing, often introducing unexpected risks or vulnerabilities and sometimes even new licenses. 

FOSSA monitors these changes, identifying any new licensing issues or security risks in each package revision. This enables teams to adopt a posture of proactive, continuous management of their open source software. But for teams with a large number of repositories and projects, it has the potential to create redundant alerts related to the same underlying issue. 

To help solve this problem, FOSSA recently launched auto-ignore rules, a feature designed to significantly streamline license compliance and vulnerability remediation. By creating a rule just once, you can apply it across other projects or future versions of a given package. This approach not only minimizes the need to resolve the same issue in multiple places but also dramatically reduces the number of open issues and the time spent on them, decreasing alert fatigue for your team.

This feature isn't just about reducing the number of alerts; it's about creating an intelligent system that remembers your decisions and applies them across your projects and future package versions.

How Auto-Ignore Rules Reduce Re-Work

FOSSA's new auto-ignore feature saves time in multiple scenarios:

1. Applying decisions to future revisions: Auto-ignore rules eliminate duplicative work by applying your decisions from one revision to future revisions. Typically, open source licenses change infrequently — you shouldn’t have to continuously resolve the same licensing issues on every revision. For example, once your team approves the license for a particular package version, auto-ignore rules can extend this acceptance to future versions of the package, as long as the license remains unchanged. This means your team won't be bogged down by alerts for the same licensing issue every time the package is updated — a significant step toward efficient license compliance management.
2. Applying decisions to all projects that share the same policy: Another key advantage is the application of auto-ignore rules across projects with shared policies. For instance, if your team determines that a specific issue is irrelevant for any SaaS application, you can apply an auto-ignore rule across all projects governed by your SaaS application policy. This ensures that all similar projects benefit from your vetting efforts, avoiding the need to resolve the same issue repeatedly across multiple projects.
3. Applying decisions from a project to its release group: Similarly, if you’ve ignored an issue for an individual project, you can now also apply that decision to the release that contains that revision of the package. 
4. Applying decisions globally: If you’ve made a decision about a particular package issue, you can also apply it to all projects globally.

A User-Friendly Experience for Enhanced Efficiency

Designed with a focus on user experience, auto-ignore rules are integrated seamlessly into your existing FOSSA workflow. When ignoring an issue, simply select where else this rule should apply, and a new auto-ignore rule will be created. 

FOSSA is the only license compliance solution that remembers what decisions you’ve made and applies them to other projects, so you don’t have to resolve the same issue in multiple places. 

Take the Next Step Toward Effective OSS Management

Current FOSSA customers can leverage auto-ignore rules in their workflow today. You can reference our documentation for more information. 

If you aren’t yet a FOSSA customer and are interested in auto-ignore rules, getting started is straightforward. You can sign up for a FOSSA premium account (recommended for smaller organizations) for immediate access to this feature, or request a demo (recommended for larger organizations) to get an in-depth look at how auto-ignore rules can help make your license compliance and security efforts more effective and efficient.

With the addition of auto-ignore rules, we are excited to continue enabling teams to focus on what truly matters for security and license compliance in their organizations.

Earlier this week, researchers from Ruhr University Bochum in Germany announced the discovery of a new vulnerability impacting the popular SSH protocol. The attack is named Terrapin, and it’s been assigned CVE-2023-48795. 

SSH (Secure Shell Protocol) is a cryptographic network protocol that enables secure communication over an unsecured network. It’s a versatile and widely adopted protocol that’s used in countless applications and computing environments.

Terrapin is a man-in-the-middle attack; the flaw allows an attacker to corrupt data being transmitted. This can result in a loss of information or bypass critical security controls such as keystroke timing protections or SHA-2 cryptographic hash requirements, allowing the threat actor to downgrade to SHA-1. Doing so opens up the possibility of other attacks on downstream applications, components, or environments that use SSH. ​​These associated vulnerabilities have been assigned CVE-2023-46445 (Rogue Extension Negotiation Attack in AsyncSSH) and CVE-2023-46446 (Rogue Session Attack in AsyncSSH).

There’s not necessarily a one-size-fits-all remediation for the Terrapin attack. As the Ruhr University researchers explain:

“Due to the widespread adoption of affected cipher modes, patching Terrapin (CVE-2023-48795) is notoriously difficult. To make matters worse, "strict kex" requires both peers, client and server, to support it in order to take effect. A wide variety of SSH implementations started adopting "strict kex" since public disclosure.”

With that said, the Ruhr University researchers have created a vulnerability scanner that you can use to see if your SSH server or client is susceptible. (They’ve also published a list that includes some affected SSH implementations and safe versions.)

Additionally, FOSSA Vulnerability Management subscribers can use our product to locate the CVE(s) in your codebase. You can do this by navigating to the “Packages” tab in the UI and entering the CVE numbers in the “Select a CVE” bar on the bottom-right side of the page. (We've also included a brief video demonstration at the bottom of this article.)

Vulnerability Impact and Significance

How concerned should you be about this vulnerability? While this will vary across organizations and implementations, in general, there is currently little reason to be overly alarmed. Here's why:

• Limited Impact: Terrapin can delete consecutive portions of encrypted messages, which in isolation will typically result in a stuck connection. Some of the most serious impacts identified are in downstream applications implementing SSH, such as AsyncSSH. An attacker may be able to disable certain keylogging obfuscation features, enabling them to conduct a keylogging attack; or, worst case, a threat actor can sign a victim's client into another account without the victim noticing, enabling phishing attacks.
• Difficult to exploit: An active man-in-the-middle attacker and specific encryption modes are prerequisites for the exploit. Intercepting SSH traffic requires a detailed understanding of a target's environment, limiting real-world applicability.

In short, Terrapin is a concern, but not a reason to panic.

Additional Resources: Understanding and Mitigating Terrapin

The Ruhr University researchers who announced the vulnerability have also published several valuable resources for those concerned about their exposure. These include:

Vulnerability scanner: A tool that can be used to determine if you’re vulnerable to the attack.

FAQ: Guidance on how organizations should prioritize remediation, how the attack works, which implementations are vulnerable, and more.

Patches: A list of affected versions and implementations (and the safe, patched versions).

Additionally, FOSSA Vulnerability Management users can reference the video below for guidance on locating the Terrapin CVEs. If you aren't currently a FOSSA user but would like to become one, please reach out to our team.

SCA (Software Composition Analysis) and SAST (Static Application Security Testing) tools both play important roles in secure application development, but there are notable differences between them. 

The biggest is that SCA tools focus on open source dependencies and their associated risks, while SAST tools focus on your proprietary code — e.g., the custom code your developers write or maintain, including how an open source component is used in proprietary code. 

As such, SAST provides a different perspective on vulnerabilities or weaknesses than SCA. Where SAST would tell you, “Your code has improper input validation,” SCA would tell you, “The code (OSS) your code is using has improper input validation.” In other words: The tools surface similar vulnerabilities, yet on dramatically different attack surfaces. 

Another significant difference is SCA has multiple use cases beyond vulnerability management, including SBOM management and open source license compliance. 

For these reasons, SCA and SAST are considered complementary: SAST tests your code and coding practices, while SCA tests your third-party code. 

In this blog, we’ll explain how both SCA and SAST work, the important differences between them, and how the tools can work together to strengthen security.

SCA, Explained

SCA tools analyze, inventory, and manage open source dependencies, their licenses, and their vulnerabilities. SCA works by scanning software applications to identify the third-party components and libraries they depend on. SCA tools can integrate with various development and CI/CD tools to automate the analysis as part of the software development process.

SCA supports several distinct use cases:

Open source license compliance: SCA tools report a list of open source licenses (and their associated dependencies) when scanning code. Some SCA tools (like FOSSA) will also list the obligations that your licenses carry — and even offer functionality to help achieve compliance, such as automating license notice creation. Additionally, SCA tools with strong policy engines can be configured to block builds if an out-of-policy license is detected. 

SBOM generation: Creating a software component inventory is a fundamental SCA capability, so it shouldn’t be a surprise that many SCA tools also support SBOM generation. For example, organizations can use FOSSA’s SCA offering to generate SBOMs in both the SPDX and CycloneDX formats, with a range of customization options. Some SCA tools also support third-party SBOM ingestion and management.

Open source vulnerability management: Beyond providing an inventory of known vulnerabilities (CVEs), SCA can help with prioritization and remediation. For example, FOSSA will show the CVSS and EPSS scores for a given vulnerability to support prioritization, and we’ll also report the fix and code path to help with remediation.

SAST, Explained

SAST is used to analyze an application’s source code, bytecode, or binary code for security vulnerabilities — without executing the program. SAST tends to be used very early in the software development lifecycle (such as in the development phase), which helps developers and security teams address possible security issues before deploying an application.

SAST identifies potential vulnerabilities by using predefined rulesets or security patterns. These rulesets are created based on known security best practices and common coding mistakes that may lead to security issues, including SQL injection, cross-site scripting (XSS), buffer overflows, and other security vulnerabilities. In practice, these vulnerabilities result in threat actors escalating authorized privileges, accessing restricted data, or executing malicious code. 

SAST utilizes several techniques to identify vulnerabilities, such as:

• Data flow analysis: This tracks how data moves through the application. It includes control flow analysis (to understand the order in which different parts of the code are executed) and code path analysis (understanding conditional statements, loops, and different execution paths).
• Taint analysis: This tracks the flow of untrusted or tainted data through the application. If user input is not properly sanitized or validated, it can be considered tainted, and the tool traces its path through the code to identify potential security risks.

Key Differences Between SCA and SAST

As we’ve discussed, although SCA and SAST both support security use cases, there are significant differences between the two tools. Here are some of the biggest.

1. SCA is used to identify open source dependencies. SAST is used to analyze proprietary or first-party code.
2. SAST tools do require access to source code, while SCA tools may not.
3. SCA supports open source license compliance and SBOM use cases, while SAST does not.
4. When SCA surfaces a vulnerability, the remediation is often upgrading (or replacing) an open source component. With SAST, the remediation is generally to modify the actual application code. 
5. SAST tends to be used earlier in the SDLC than SCA, in the development phase rather than the build phase.

Despite these differences, it is worth noting that a majority of vulnerabilities reported by SCA tools are the direct result of "SAST" scans on the source of an open source dependency. So, essentially, most open source vulnerabilities are SAST results run against that proprietary or open source code that have been published in a public database (such as MITRE, NIST, GitHub advisory, and so forth).

SCA and SAST: The Bottom Line

Although SAST and SCA work differently and have different purposes, they’re both important parts of managing security risks for modern applications. As such, many organizations benefit from using both tools. This is often done via integration into your CI/CD pipeline, which ensures that security assessments are conducted automatically with every code commit and deployment, providing timely feedback to developers.

With SCA and SAST in place — along with other testing tools and the right people and processes — organizations can strengthen their defenses against a range of security and open source license compliance risks.

For more information on FOSSA’s SCA tool and how it works, we recommend visiting our SCA product page.

Dual licensing often refers to the scenario where a developer makes software available under a choice between two licenses: generally a copyleft open source license and a commercial license.

However, dual licensing can also refer to the scenario where multiple licenses apply simultaneously; in these situations, users are required to comply with the terms of multiple licenses at the same time.

For clarity, in this article, I’ll use the term “choice of license” to describe the scenario where software is offered under a choice between licenses. And, I’ll use the term “multi-license” to refer to the scenario where multiple licenses apply simultaneously. (I’ll use the term “dual license” when referring to both scenarios collectively.)

There are several reasons why an organization may choose to dual license its software:

• Choice of license: Many private companies offer a choice of license so that casual or small users can use the software free of charge, but enterprise users must negotiate for an alternative, commercial license.
• Multi license: To ensure compatibility with other code with which the project should interoperate, such as GPL v2 and Apache, since there are questions about whether these licenses are compatible. 

In this blog, I’ll discuss the nuances of both dual-licensing models (choice-of-license and multi-license), along with considerations for managing some of the IP risks that can come with them.

Editor’s Note: Heather Meeker is one of the world’s foremost legal experts on open source software licensing and compliance. She’s authored the go-to book on the topic, “Open Source for Business,” and is a General Partner at OSS Capital. Heather is also the author of the new book, “From Project to Profit: How to Build Your Business Around Your Open Source Project,” now available on Amazon.

Choice-of-License Scenarios

Like I mentioned earlier, dual licensing can refer to a scenario where vendors (often private companies) make software available under either an open source license or a commercial license. Software vendors that adopt a choice-of-license model generally use AGPL (but sometimes GPL, e.g. GPL v2 or GPL v3) as the open source option.

The reason why AGPL (and GPL) are popular choice-of-license options is because they’re the copyleft licenses that impose the most conditions. As such, they have the effect of driving users who don’t want to comply with the license terms toward negotiating alternative (read: commercial) licenses.

In contrast, it wouldn’t make sense to offer a dual-licensed product under a permissive license like Apache 2.0 because there wouldn’t be an incentive for an end-user to pay for an alternative.

When vendors use a choice-of-license model, they almost always make the options clear on a public-facing website. This is because the vendor wants users to know there’s an option to negotiate commercial licenses — it’s a way of generating business for their company. 

The flip side of this is that, although it may not be ideal to pay for a commercial licensing option, end-users should have some peace of mind knowing that they can solve compliance problems by negotiating a regular commercial license.

Commercial licenses in this kind of situation are usually conventional enterprise end-user licenses or software distribution licenses.

Multi-License Scenarios

Perhaps the most famous example of a scenario where multiple open source licenses apply simultaneously (multi-licensing) is OpenSSL. OpenSSL is a very popular open source utility licensed under two slightly different permissive licenses (the OpenSSL license and the SSleay license). (Note that this project has since migrated to Apache 2.0, in part due to confusion over its multi-license. However, there are many legacy copies of OpenSSL in the wild that are still licensed under the OpenSSL/SSleay model.)

You may also find situations where certain components in a project are under one license and certain components are under another — for example, some might be GPL, and some might be the MIT license. This happens mostly when a downstream project will not accept code under any license other than GPL.

A question that I’ve heard come up in true multi-license situations (where both open source licenses do cover and apply to the entire work): Should we be worried about conflicts between the licenses? My view is that they probably won’t conflict because they’re both going to grant unlimited rights — it’s just that you have to comply with all of the conditions for at least one of the licenses.

Managing Dual-Licensing Risks

If you’ve worked with SBOMs (software bill of materials), you might recognize that the SPDX specification has properties that distinguish between choice-of-license and multi-license scenarios. (These are known as SPDX license expressions.) In SPDX, choice-of-license scenarios are communicated using “OR,” and multi-license scenarios are communicated using “AND.”

When you get information in an SBOM or software audit about dual licenses, you need to understand whether you’re looking at “OR” or “AND.” However, the tracking tools that you (or your vendors) use may struggle to track these nuances, so it does sometimes take some additional work to distinguish between these dual-licensing scenarios. 

For example, let’s say you get a license report and it says “GPL/MIT.” That will usually mean both licenses apply. But, if you get a license report and it says “AGPL/Commercial,” that means it’s usually a choice. 

The only reason you would know this is based on context. I’ve gone through lots of licensing reports, and it’s often not clear — sometimes you have to look at the information on the relevant website to figure it out. But it’s important that you understand what the universe of choices can be so that when you get a single line item that lists multiple licenses, you understand how to determine the licensing model.

Learn More About Dual Licensing

This blog is based on a webinar I recently conducted with FOSSA: When “Open Source" Isn’t Open Source. If you’re interested in more perspective around dual-licensing scenarios (and source-available software licenses), consider watching the on-demand recording. You can do so by clicking this link.

Source-available software licenses, which have become increasingly popular in recent years, share properties with both open-source and proprietary licenses. At a high level, source-available licenses have three main attributes:

1. They make source code available 
2. They impose some license restrictions 
3. They’re implemented in a frictionless manner

Source-available licenses are deployed like open-source licenses — and people have a tendency to mistakenly refer to source available as open source — but they’re not the same. This is because source-available licenses put restrictions on the use of the software, while true open-source licenses do not. 

In this blog, I’ll discuss in detail the key properties of source-available licenses (and how they compare to open source and proprietary source), highlight examples of popular source-available licenses, and cover strategies for managing IP risks.

Editor’s Note: Heather Meeker is one of the world’s foremost legal experts on open-source software licensing and compliance. She’s authored the go-to book on the topic, “Open Source for Business,” and is a General Partner at OSS Capital. Heather is also the author of the new book, “From Project to Profit: How to Build Your Business Around Your Open Source Project,” now available on Amazon.

Source-Available License Properties

Although there’s no universally held definition for a source-available software license, code availability, the existence of restrictions, and frictionless implementation are common properties. Here’s a brief explanation of each.  

Makes Source Code Available

A source-available license means that the source code is available. That’s the most important overarching license property. 

Places Restrictions/Limitations

In contrast to open-source licenses, source-available licenses are not unrestricted. They have what licensing lawyers call a field-of-use limitation. (Source-available licenses can also limit the number of users, or impose other limitations, but they usually impose field-of-use limitations.) A field-of-use limitation is an old term in IP licensing. It can refer to, say, a technology area, a market, a geography, or a kind of use. 

Implemented in a Frictionless Manner 

Similar to open-source licenses, source-available licenses are implemented in a frictionless manner. This is in contrast to traditional end-user licenses, which require you to click to accept. 

Source-available licenses very rarely have acceptance mechanisms. You usually download the software and there’s a license included, which is the same experience you’d have with open source. 

But while you usually don’t have to click to accept anything, the license grants broad enough rights so that if you don’t accept the terms, you won’t have the right to do what you want to do with the software. That’s the legal theory upon which the frictionless method rests — for both open-source and source-available.

Source Available vs. Open Source and Proprietary

Source-available licenses share some qualities with open-source and proprietary licenses, but there are important differences between them. 

Open Source Licenses

The fundamental concept of open source — other than source-code availability, of course — is that it allows the software to be freely used for any purpose. Open source grants all the rights of copyright and it doesn’t impose any restrictions on the use of the software. This means no license restrictions, no field restrictions, no market restrictions, no territory restrictions, and so forth.

It can, however, impose conditions. 

Lots of people get confused about the difference between conditions and restrictions, but a condition is: If you do this thing, you have to do this other thing. For instance, if you drive a car, you have to get a driver’s license. 

Open-source licenses place a range of conditions on the use of the licensed code. Copyleft licenses like GPL impose significant conditions, like source code sharing, while permissive licenses impose hardly any at all. 

Proprietary Licenses

In contrast, proprietary licenses do impose restrictions and limitations. For example, there can be limitations on the number of servers or the number of users. (In the old days, we used to do site licenses and CPU licenses, but those have mostly gone by the wayside.) If you’re licensed for 100 users but you have 200 people using the software, those extra users are not licensed; you’ve violated the license and have potentially engaged in copyright infringement by exceeding the license restrictions.

Other types of proprietary license restrictions may include that you can only use the software for testing purposes or with specific products. Or, there may be a bundling requirement, meaning you can’t use the software on a standalone basis. 

Source-Available Licenses

To recap: Like open source, source available makes source code available. And, like open source, these licenses are deployed in a frictionless manner. But unlike open source (and like proprietary terms), they have license restrictions.

Source-Available License Benefits

Software producers often choose to adopt source-available licenses for two primary reasons that seem contradictory but actually aren’t: openness and lack of openness.

Let’s say I'm making a database, I have some code, and I want to sell commercial licenses to it. My customers will not use that software unless I give them the source code. The reality today is that you have to give customers source code because they expect it. 

That’s been one of the huge effects of the open-source movement. Twenty years ago, enterprise licenses included binary-only licenses and technology escrows, but those have fallen by the wayside. Now, the commercial expectation is that you give your customers source code so they don’t have worries about business continuity. As such, you have to have a source-code license, and the source-available licenses do that.

Additionally, because source-available licenses are frictionless, they allow people to easily download the software, and you don’t have to sign evaluation licenses. This takes a lot of friction out of the sales process. It allows distribution on platforms like GitHub. At the same time, if properly drafted, source-available licenses have narrowly crafted restrictions that protect the software producer’s business. 

A typical source-available restriction is that you can use the software for anything you want — but you can’t set up a competing cloud service using the software. That allows the licensor to protect its cloud business, which is how it’s making money and how it’s funding product development. 

Ultimately, making the software available for free (except for restricted use cases) helps with community, and the restrictions help the licensor fund the free aspects. It allows a company to fund development with its commercial business while keeping the source code available.

Source-Available License Examples

A handful of source-available licenses have gained particularly strong adoption. Here’s an overview of several of these popular licenses and their key provisions. 

Business Source License

The most popular source-available license is the Business Source License (BSL), which was created by MariaDB. The BSL is an unusual license since it includes a license change feature.

The license change feature says that after a certain amount of time — no more than four years — the license automatically changes to a GPL-compatible open-source license. This is sometimes referred to as embargoed or delayed open source. 

The Business Source License also says that you can use the software for non-production uses, although it doesn’t define non-production uses. Because the production use restriction is really broad and not precise enough for most people, BSL licensors tend to write what’s called “additional use grants.” So, for the BSL you’re usually looking at the BSL itself and an additional use grant along with the change license and a change date. 

The BSL has gotten a lot of traction, particularly in the crypto area. There’s no particular reason why it’s gained steam in crypto other than the fact that it was adopted by some crypto companies, which generated publicity and popularity in the space. 

Recently, a license called the Functional Source License (FSL) was released that updates BSL and narrows down the choices. It also contains a narrower restriction aimed at protecting SaaS businesses. 

Elastic License

The Elastic License, which was published by Elastic Search, prohibits the use of the software to provide a managed or hosted service. This type of restriction is very popular in source-available licenses because the companies that release software under these licenses are trying to protect their cloud businesses. The Elastic License allows redistribution freely, so it’s not protecting the distribution business, only the cloud business. That’s a strategic decision. 

Another property of the Elastic License is that you can’t disable the license key functionality. This is because Elastic controls some of its paid features by putting them in the software but keeping them turned off unless you pay for them. 

Commons Clause License

Commons Clause was an early source-available license that ended up being more of a thought experiment than something a lot of people use. It’s an addendum to an open-source license, and the fact that it’s an addendum has caused some consternation in the open-source world. At a high level, I would describe Commons Clause as a restriction on commercialization, which is similar to the Business Source License. 

If Commons Clause is used, the vendor applies a base open-source license plus the Commons Clause addendum. So, if you see software with a base license like Apache 2.0 and Commons Clause on top of it, the end result is that you can’t sell the licensed software. 

Polyform Licenses

Polyform is a project I worked on with other lawyers in the open-source space to create a Commons Clause-like menu of choices for source-available licenses. Polyform offers various options like non-commercial, evaluation-only, and even some that are similar to the Elastic License or the BSL.

Managing Source-Available Licensing Risks

There are four primary IP-related considerations when it comes to using source-available software. Here’s my assessment of each.

License Notices

A lot of legal and compliance considerations with source-available licenses are similar to those that come with open-source licenses. This includes license notice requirements.

Those who draft source-available licenses usually try to make them easier to comply with than open-source licenses, such as allowing you to include a URL rather than the whole license text. But it’s the same kind of process — if you distribute a product with one of these elements in it, you need to pass on a license notice.

Complying with Limitations and Restrictions

The main concern with source-available licenses is that you need to make sure you comply with the license restrictions. You would not have that issue with an open-source license. 

For example, if a source-available license allows only non-production use, you need to figure out how to maintain that control within your organization. The challenge is that a lot of organizations tell me — I believe correctly — that once you approve software for use within an organization, it gets very hard to control how it’s used within the organization. 

This same challenge played out with proprietary software over the past 30 years: vendors developed software management tools that would ensure you didn’t exceed the number of users or servers you were allowed under proprietary licenses. But no such thing really exists for a non-production use restriction. 

So, you have to do some human intervention to make sure you have policies and processes in place to ensure continuous compliance with most source-available licenses. 

Navigating a Lack of Standardization 

Source available licenses aren’t standardized yet, though the industry is converging around a few of them. A great benefit of open source — in addition to the fact that it has no restrictions — is the significant amount of standardization within open-source licenses. There are hundreds of them, but only a handful of open-source licenses have been broadly adopted. So, it’s very easy to make assumptions about the license terms because there are actually so few licenses that people use with any regularity

In contrast, at this point, you’ll have to review the source-available license on an ad-hoc basis just like you would with a proprietary license.

Budgeting for Commercial Use

Source-available licenses are almost always imposed by private companies, usually in a dual-licensing model or some other model where the company wants to make money from the software.

If a company releases software under a source-available license that prohibits commercial use, and you want to use it for commercial purposes, you have to come back to the licensor and negotiate a separate custom license.

That’s a double-edged sword. 

On the one hand, if you want to use the software in a way that’s not allowed by the license, then you can probably negotiate an alternate license with the licensor. That isn’t the case with some open-source projects, which often cannot or will not negotiate alternate terms.

On the other hand, the companies that release source-available code are usually conducting enforcement activity because they’re shoring up their rights. So, it’s a little more common to have actual enforcement actions from private companies. Those are not usually lawsuits but rather letters saying, “We understand you’re using this in violation of the license, you need to get the license, and here’s the fee for it.”

As an overarching matter, if you can’t live with the terms of the source-available license, you can solve that problem with money. It might be painful to pay, but at least there is a solution.

Is Source-Available a Threat to Open Source?

Not really. The source-available model is a substitute for proprietary licenses, not open-source licenses. Without this category, vendors would still be using click-to-accept EULAs that don’t provide source code.

Learn More About Source-Available Licensing

This blog is related to a webinar I recently hosted with FOSSA: When “Open Source" Isn’t Open Source. If you’d like more information on source-available software licenses (and dual-licensing models), I’d suggest you consider viewing the on-demand recording. You can do so by clicking this link.

EPSS (Exploit Prediction Scoring System) measures how likely a particular vulnerability is to be exploited in the wild. EPSS scores range from 0% (the lowest probability of exploitation) to 100% (the highest probability of exploitation). In addition, since it can be hard to extrapolate the true meaning from a probability score alone, EPSS also provides percentile rankings; percentile rankings measure EPSS probability relative to all other EPSS scores. The combination of probability and percentile enables advanced prioritization inputs.

EPSS exists to address a problem that security practitioners know all too well: We’re drowning in CVEs — including many high-severity CVEs — but the majority aren’t actually exploitable. This, of course, can make it difficult to prioritize vulnerability remediation efforts.  

By providing an objective measure of the likelihood of exploitability, EPSS can be a valuable input in vulnerability prioritization alongside other external data points like CVSS (Common Vulnerability Scoring System) and VEX (Vulnerability Exploitability eXchange).

In this blog, we’ll dive into the specifics of the EPSS model, discuss how it compares to CVSS and VEX, and explain how EPSS scores can be integrated into a comprehensive vulnerability management program.

But first, let’s start with a brief review of EPSS’ history and its data model.

EPSS History and Data Model

EPSS is managed by the Forum of Incident Response and Security Teams (FIRST) in partnership with a range of public and private sector contributors. The first version of the EPSS scoring system was released in April of 2021. Version 2.0 was published in February 2022, and the current V 3.0 was released in March of 2023.

Whenever a new CVE is published, an accompanying EPSS score will be released. The score is intended to communicate the “probability of exploitation activity in the next 30 days.”

According to the model’s website, EPSS is currently collecting data from multiple sources, such as:

1. The CVE List from Mitre
2. Number of days the CVE has been published
3. Published exploit code in any of: Metasploit, ExploitDB, and/or GitHub
4. Multiple security scanners
5. CVSS v3 vectors in the base score as published in the National Vulnerability Database (NVD)
6. CPE data as published in NVD

In all, EPSS is trained on over 1,000 variables. For a more comprehensive explanation of the EPSS model, we recommend you visit FIRST’s website. 

EPSS vs. CVSS

Like EPSS, CVSS (Common Vulnerability Scoring System) is governed by FIRST, and the two models share similar objectives in helping security practitioners understand and prioritize vulnerabilities. But while EPSS focuses on vulnerability exploitability, CVSS primarily aims to communicate vulnerability severity.

CVSS assigns severity scores on a 0 (lowest) to 10 (highest) basis. The ranges are as follows:

None: 0

Low: 0.1 - 3.9

Medium: 4.0 - 6.9

High: 7.0 - 8.9

Critical: 9.0 - 10.0

As an example, the Log4J vulnerability CVE-2021-44228 was assigned a severity rating of 10.0, the highest possible.

CVSS scores represent “the intrinsic qualities of a vulnerability that are constant over time and across user environments,” such as integrity impact, availability impact, attack vector, and more. 

There are other elements of the CVSS that take into account a) factors that do change over time, such as exploit code maturity, and b) factors specific to user environments. But these aren’t part of the CVSS score that gets published.

EPSS vs. VEX

EPSS isn’t the only resource for assessing vulnerability exploitability. VEX (Vulnerability Exploitability eXchange) also seeks to help measure exploitability, but it works very differently than EPSS.

VEX information is provided by the software supplier based on internal inputs. When using VEX, the supplier assigns a status to the vulnerability (Affected, Not Affected, Under Investigation, or Fixed) as well as a status justification. For example, the supplier may assign a status of “Fixed” if the vulnerability has been patched. Or, the supplier may assign a status of “Not Affected” with a justification of “Component_not_present” if, say, the vulnerable module isn’t included in the production deployment.

In contrast, EPSS scores are informed by external data input described in previous sections. 

As such, VEX and EPSS are complementary and can be used in tandem to help prioritize remediation efforts.

How to Use EPSS Scores

Security practitioners can use EPSS scores in several ways:

• With an SCA (software composition analysis) tool that leverages EPSS scores to help you filter and prioritize vulnerabilities
• Directly from the EPSS website (via downloadable CSV)
• From the EPSS API

Because EPSS scores are informed estimates based on a data model, real-world evidence of exploitability should take precedence over EPSS when informing vulnerability remediation decisions.

FOSSA users with subscriptions to our Vulnerability Management product can easily leverage EPSS scores to help guide vulnerability prioritization. You can do this in multiple ways:

1. To prioritize by EPSS score for vulnerabilities across all projects: Navigate to the Security Issues tab in your FOSSA dashboard. Ensure your issues are ungrouped. Click on the sort options in the top right-hand corner of your screen, and select “Highest EPSS.” You’ll then see a list of all vulnerabilities across your organization, starting with the highest EPSS score and ending with the lowest. To help contextualize the EPSS score, you’ll also see its percentile compared to other vulnerabilities. This view also includes other vulnerability context, like CVSS, CVE, and fix. 
2. To prioritize by EPSS score for vulnerabilities across a single project: Click on the project that you’d like to analyze, then open the Security Issues tab. From there, you’d follow the same filtering process as described above. 

The screenshot above provides a quick example of the value of EPSS. Although CVE-2021-45105 has a CVSS score of 5.9 (and is thus categorized as a medium-severity vulnerability), it is actually in the 99th percentile of EPSS scores and thus should be prioritized over many higher-severity CVEs with lower EPSS scores. 

If you’d like to learn more about how FOSSA can support your organization’s vulnerability management program, please reach out to our team.

An SBOM (software bill of materials) is only as useful as it is accurate. There are a wide variety of potential SBOM use cases (security, open source license compliance, regulatory compliance, due diligence, etc), but all of them depend on the underlying SBOM data being correct, comprehensive, and up to date.  

There are many variables that ultimately affect SBOM quality. These include the tools you use to generate an SBOM, when and how you integrate those tools into the SDLC, the format of your SBOM document, the data fields you include in your SBOM, and more.

In this blog, we’ll discuss several important elements of a high-quality SBOM, starting with tooling and how to integrate it.

Tooling and Install Plan

Producing quality SBOMs at scale requires the right SBOM tools. It’s best to prioritize tools that offer comprehensive language coverage, support CycloneDX and SPDX, and provide numerous customization options.

Once you’ve selected an SBOM tool, the next question is when and how to integrate it into the software development lifecycle. I recommend after the final build for each service, but prior to deployment to represent a production environment — more specifically, within your continuous integration phase after you’ve successfully merged local environments with a development environment. At this point, you can build and run a FOSSA analysis (or an analysis with the tool of your choice) as a final step before deploying environments into any staging/production systems. 

Additionally, the final application install plan — which includes all microservices and components —  should be represented as one SBOM.

Another important consideration is how frequently you should generate a new SBOM. We recommend you create a new version each time you update or modify components (i.e. after every new build). 

It’s also critically important to ensure your SBOM tools provide language coverage for all open source dependencies in your install plan. Tooling will often report zero dependencies for unsupported languages. 

In addition to making sure your SBOM tooling has coverage for all the languages you use, ensure the output of the SBOM tooling properly aggregates polyglot applications. With free or open source tooling, it’s common that a user will need to manually aggregate individual SBOMs generated from language-specific tooling to represent a completed service or application.

SBOM Configuration and Data Fields

Although there are certain data fields that are part of every quality SBOM (package name, package version, package author, etc), there’s also a lot of room for customization. When deciding which data fields to include (and exclude) from your SBOM, it’s important to understand the needs of your SBOM consumers. This will make a big difference in determining whether a specific SBOM achieves its purpose.

Here are some considerations and recommendations for data fields to consider including depending on your primary use case(s).

License Compliance or Attribution Use Cases

Both CycloneDX and SPDX have a number of data fields that support open source license compliance use cases. Interestingly, SPDX License Identifiers — which are essentially standardized abbreviations for common open source licenses — form the foundation for license compliance use cases across both SPDX and CycloneDX. 

If you’re using the SPDX format, consider configuring your SBOM to include the Declared Licenses, Concluded License, and Copyright Text data fields. 

If you’re using CycloneDX, consider configuring your SBOM to include Licenses metadata, such as ID and URL.

You may also consider including full license text directly in your SBOM to help satisfy license notice requirements. You can do this in both SPDX (with the License Text field) or CycloneDX (with the Text field). Note that in CycloneDX, there’s an optional encoding for the license text; if you want to include human-readable full license text in a CycloneDX document, you will need to make some additional adjustments (e.g. escaping new lines or special characters).

Finally, it’s worth noting that both CycloneDX and SPDX support commercial licensing information. In CycloneDX, you can communicate commercial licensing information using the Licensor, Licensee, License Type, and Purchaser fields. In SPDX, you can communicate commercial license information by adding a custom license identifier (“LicenseRef”), then adding the full license text (or context/comments) in the “Extracted Text” field. (In cases where it wouldn’t be appropriate to include the full text of a commercial license in your SBOM, it’s relatively common practice to add context/comments in the SPDX “Extracted Text” field instead.)

Ultimately, for license compliance use cases, we recommend you configure your SBOM to include the license name for each component, and, if you intend for your SBOM to double as a public-facing attribution notice, consider including the copyright notice and full license text as well.

Security Use Cases

Security is a common SBOM use case. And, both CycloneDX and SPDX can be used to communicate a variety of security data, though the mechanism for doing so varies. 

This starts with VEX (Vulnerability Exploitability eXchange) data. VEX is used to communicate whether vulnerabilities are actually exploitable in a real-world context. Key VEX data fields include:

• Vulnerability Identifier
• Status
• Status Justification
• Mitigation 

In CycloneDX, you can either a) embed VEX data directly in the SBOM or b) link to an external VEX report (which is recommended to ensure the VEX data can be easily kept up to date). 

SPDX doesn’t have data fields that support directly embedding VEX data, but, like CycloneDX, it supports external references to VEX documents. 

Although VEX is an important part of communicating security-related information in an SBOM, there are other fields and references to keep in mind as well.

In CycloneDX, the “Vulnerabilities” element includes numerous security-related data fields, such as CWE, CVE, Vulnerability Score, Vulnerability Severity, and more. It’s also possible to link to external security advisories, vulnerability disclosure reports, and more. 

In SPDX, the primary way of communicating security information is through External References. You can link to VEX documents, CVE advisories, and more.

Whether using SPDX or CycloneDX, ensuring each package or component has a full dependencies (CycloneDX) or relationships (SPDX) graph will help locate the direct dependency remediation required to influence transitive dependencies. 

In addition, an associated unique identifier, such as a Package URL, is critical to validating the accuracy of vulnerabilities. For example: Is my organization using public registry versions of OSS packages or ones hosted internally? If internally hosted, are these mirrors or forked/modified versions my organization self-maintains? 

Ultimately, for security use cases, we recommend that you ensure each component has an accurate Package URL (PURL), a referenced or embedded VEX document, and up-to-date VEX status and accompanying justification.

Regulatory Compliance Use Cases

The Biden Administration’s 2021 cybersecurity executive order required organizations selling into the U.S. federal government to provide an SBOM along with each product. The requirement also outlined minimum elements that must be included in these SBOMs, which are as follows: 

• Supplier Name
• Component Name
• Version of the Component
• Other Unique Identifiers (e.g. PURL, CPE, SWID Tags)
• Dependency Relationship            
• Author of SBOM Data
• Timestamp

It’s worth noting that these minimum elements are also applicable to the FDA’s new guidance around SBOMs to accompany premarket submissions. However, the FDA also has a few additional requirements, including communicating the level of support for maintaining the component and the component’s end-of-support date.

Automation vs. Human Contributions 

Although most of the data fields discussed in this section can be easily configured and automated in your SBOM tool — for example, it takes just a few seconds to add or remove data fields from your SBOM in FOSSA — there are a few that require some level of human intervention. 

Specifically, if you include VEX data in your SBOM, you will need to annotate it with status justification and mitigation information. Also, if you use SPDX and there are different values for the Concluded License (determined by the SPDX document creator) and Declared License (determined by the component author) fields, you’ll want to use the Comments on License field (7.16) to add context.

Additionally, SBOM tools often won’t easily support some of the less common data fields discussed in this section, so you may need to manually add them as well.

Hosting and Distributing High-Quality SBOMs

The work to ensure an accurate, quality SBOM doesn’t end once the document is first generated. It’s also vital to keep the SBOM up to date to reflect changes in your application. Additionally, it’s critical to distribute SBOMs in a way that your consumers can actually use them. 

We know this is not necessarily the highest priority for some organizations today, but we anticipate it becoming an increasingly important consideration as more SBOMS are demanded externally by software supply chain security-focused software consumers. 

An SBOM may become out of date as new vulnerabilities impact existing package versions, if the composition of your application changes (such as by introducing new components), or if an external mitigation is applied to an existing vulnerability, among many other reasons. We recommend the following to keep SBOMs up to date:

• Generating new SBOMs, including updated VEX, per production deployment 
• Daily VEX document creation to include new vulnerabilities and mitigation
• Applicable access controls 

There are additional considerations for hosting and distributing SBOMs based on the type of software your organization is covering. Generally, these fall into either “Public” SBOMs or “Private” SBOMs. A public SBOM should be included in the root of any applicable public-facing version control software (VCS) or repositories enabling access for any potential software consumer. Public SBOMs should generally be reserved for open source applications or ubiquitous “freemium” models (for example, Slack). 

Private SBOMs should be included in the root of any applicable internally facing VCS or repositories enabling access by internal stakeholders such as security or compliance teams. Private SBOMs are generally reserved for internal security/compliance as well as commercial software used by government organizations (FDA, EO 14028) or risk-intolerant industries (healthcare, finance, industrial).

SBOM Quality: Additional Resources

I hope you found the guidance in this post helpful as you develop and/or refine your approach to generating SBOMs. If you did, here are some other resources you may find useful:

SBOM Examples, Explained (Blog): SBOMs can be complex, lengthy documents that describe multiple software components. To help demystify the content of an SBOM, we've created several examples, along with explanations for the data fields and sections in each.

Generating, Managing, and Importing SBOMs with FOSSA (On-demand webinar): See how you can use FOSSA’s platform to automate mission-critical parts of the SBOM lifecycle. 

How SBOMs Can Strengthen Security (Blog): Get a deep dive into how you can leverage SBOMs to strengthen software supply chain security.

Additionally, if you'd like more information about using FOSSA's tool to generate, manage, and import SBOMs, please reach out to our team.

Curl 8.4.0, a new version of the popular data transfer command line tool and library, was released on Wednesday, Oct. 11, Curl 8.4.0 fixes two vulnerabilities (one high severity and one low severity) that impacted several prior versions of Curl. 

The vulnerabilities are:

• CVE-2023-38545 (SOCKS5 heap buffer overflow): A high-severity vulnerability that impacts both libcurl and the curl tool, versions 7.69.0 to and including 8.3.0
• CVE-2023-38546 (cookie injection with none file): A low-severity vulnerability that impacts libcurl 7.9.1 to and including 8.3.0

Curl project founder and lead developer Daniel Stenberg called the high-severity vulnerability “probably the worst curl security flaw in a long time,” underscoring the importance of getting the issue patched; however, other researchers aren’t so convinced.

While the CVE-2023-38545 vulnerability is classed as high severity, and buffer overflows are often used for RCE exploits, current indications lead many researchers to believe that this isn’t quite as exploitable as first thought due to the conditions required for successful exploitation. 

Proof-of-concepts are available to demonstrate DoS attacks, but no known successful RCE exploits have popped up yet. In order for someone to take advantage of this vulnerability, a program using a vulnerable version of libcurl (or curl) would need to connect to a malicious URL using the SOCKS5 protocol with remote resolution.

News of the Curl vulnerabilities was first disclosed by Stenberg last week. Additional details were released along with the safe version 8.4.0 on Oct. 11.  

Curl Vulnerability Details

As mentioned above, Curl 8.4.0 fixes two vulnerabilities. One (the high-severity CVE-2023-38545) impacts both the curl tool and libcurl, while the second (the low-severity CVE-2023-38546) impacts only libcurl.

The high-severity CVE-2023-38545 is a buffer overflow vulnerability taking place in the heap-based download buffer used during the SOCKS negotiation before the transfer starts. If the target hostname is longer than the available memory in the buffer, the extra data is written into the heap.

The low-severity CVE-2023-38546 allows users to insert cookies into a program at will, provided a series of conditions are met. The severity is low because several specific conditions need to be met, including a readable file (in the correct format) named none being in the directory of the program using libcurl.

Importantly, there is no API nor ABI change in the safe Curl 8.4.0, which means that you shouldn’t need to make any changes to your calls to curl/libcurl; you should be able to simply update to the secure version.

How to Find and Fix Curl Vulnerabilities

Users with a paid subscription to FOSSA Vulnerability Management can use our product to help detect vulnerable versions of Curl. 

First, if you haven’t already, import your project(s) via our CLI or our Quick Import method (VCS integration).

From there, there are multiple methods of find vulnerable versions of Curl in FOSSA:

Option 1: Navigate to your project in the UI and view your security issues

Option 2: Navigate to the “Packages” tab in the UI and either: 

• Enter the CVE numbers in the “Select a CVE” bar on the bottom-right side of the package.
• Search for “Curl” in the “Search for package name” bar toward the top of the page. 

FOSSA users without a Vulnerability Management subscription can search for vulnerable versions by using API or by reviewing your projects’ dependency lists manually.

As mentioned, if and when you detect vulnerable versions of Curl in your project, it’s recommended to upgrade to the safe version 8.4.0. The Curl project also offered additional recommendations to safely fix the issue.

For the high-severity CVE-2023-38545:

• Do not use CURLPROXY_SOCKS5_HOSTNAME proxies with curl
• Do not set a proxy environment variable to socks5h://

For the low-severity CVE-2023-38546:

Call curl_easy_setopt(cloned_curl, CURLOPT_COOKIELIST, "ALL"); right after every curl_easy_duphandle(); call.

Getting Started with FOSSA

If you aren’t a FOSSA user, you can get started by::

• Requesting a free vulnerability scan and analysis from our security experts (recommended for larger organizations)
• Signing up for the free version of FOSSA (Recommended for individuals and small organizations)

GitHub Copilot and other generative AI tools have become increasingly popular in software development, and for good reason. Developers report significant productivity gains, plus greater professional fulfillment, when using AI coding tools.

But as tends to be the case with early-stage technologies, there’s still a lot we don’t know about generative AI, including potential legal, security, privacy, and maintainability risks.

For organizations with very high risk tolerances, these concerns may not be a barrier to adoption. On the other end of the spectrum, risk-averse businesses may determine the uncertainty with generative AI is too great to justify its use.

There’s also a third category: organizations that want to adopt ML coding tools, but only if they can get appropriate risk-mitigation measures in place. And, in this blog, we’ll explain several of the biggest areas of uncertainty with tools like Copilot — along with tools and best practices to manage them.

Note: Many of the processes and best practices we cover in this blog will be specific to GitHub Copilot, but the higher-level concepts are applicable regardless of your specific AI coding tool.

1. Legal and Intellectual Property

Open source license compliance and copyright law are perhaps the biggest areas of uncertainty around AI coding tools. This is the case for several reasons.

A common concern we’ve heard from in-house legal teams relates to the fact that ML models are trained on open source libraries, including copyleft-licensed ones. This has raised questions on whether generative AI output is also copyleft — and, as such, whether users would need to comply with the original copyleft licenses.

Additionally, a March 2023 decision from the U.S. Copyright Office held that some works created with generative AI aren’t copyrightable. This, of course, could limit an organization’s ability to protect the IP they create.

Strategies to Reduce Legal and IP Risks

In response to concerns over potential IP risk stemming from GitHub Copilot, Microsoft recently announced that it would offer certain legal protections to Copilot customers. Specifically, Microsoft will assume legal responsibility for any copyright infringement claims directed at paying GitHub Copilot customers (stemming from the use of Copilot). The offer is valid only for customers who use Copilot’s built-in “guardrails and content filters,” which we’ll discuss more later in this section.

Although this commitment will certainly be welcomed by paying Copilot users, it doesn’t erase all risks that can come with Copilot (nor does it impact other AI coding tools, of course). Here are a few other steps organizations can take to further manage IP-related risk.

Scan generative AI code output

As you would with any open source code, it’s a best practice to conduct license scanning on generative AI output. Tools like FOSSA help detect copyleft-licensed files and surface the accompanying compliance obligations. Additionally, FOSSA’s new snippet scanning feature can detect and match copyleft-licensed snippets potentially included in AI output.

Enable GitHub Copilot’s optional duplication detection filter

Configuring GitHub Copilot to avoid using exact matches of training libraries in your code can help reduce license compliance risk. It’s also worth noting that to the extent your company gets an IP indemnity from GitHub, GitHub will only honor it if you do have the duplication detection filter turned out. (See Clause 4 in this document for details.)

You can turn the duplication detection filter on by clicking your profile picture in the upper-right corner of any page and then selecting “Settings.” Next, select “GitHub Copilot” in the left sidebar. Finally, under “Suggestions Matching Public Code,” select “Block,” and then save your updated settings.

Tag AI-produced code

It’s a good practice to consider implementing a code-tagging system to differentiate between AI- and human-created code. This will come in handy in the event you need to rip and replace the AI-created portions.

2. Security

Code AI tools like GitHub Copilot train on a wide range of open source libraries, some of which are impacted by known vulnerabilities. This can, in theory, mean that the ML tool will produce output that’s also affected by security issues. For example, a Cornell University study found that roughly 40 percent of programs completed with Copilot were vulnerable.

Strategies to Reduce Security Risks

Use Scanning Tools

Scanning AI coding tool output with an SCA tool (like FOSSA) is a best practice. If and when FOSSA matches an AI snippet to a dependency, we’ll surface known vulnerabilities associated with that dependency along with suggested fixes.

It’s also a good practice to add any confirmed matches to your software bill of materials (SBOM) and to request SBOMs from your software suppliers when and where possible.

3. Code Privacy

In some situations, GitHub collects user data — suggestions and prompts — to retrain the Copilot model. This can result in GitHub accessing, storing, and using data that you may not want it to.

Copilot defines prompts as “the bundle of contextual information the GitHub Copilot extension sends when a user is working on a file and pauses typing, or when the user opens the Copilot pane.”

Copilot defines suggestions as “one or more lines of proposed text returned to the GitHub Copilot extension after a Prompt is received and processed by the AI-model.”

GitHub doesn't train Copilot on private repos (aside from the engagement context described in this section), but it does train Copilot on public repos. So, although you can't tell GitHub to unlearn what it's trained from existing public repos, you can consider taking new repos private if this is a concern.

Strategies to Reduce Code Privacy Risks

GitHub Copilot for Business has a standard policy not to capture suggestions and prompts, but users of the free version will need to opt out. You can do this by going to “Settings” and deselecting “Allow GitHub to use my code snippets for product improvements.”

Additionally, if you’ve used Copilot before opting out of prompt and suggestion retention, you can reach out to GitHub support to request that Copilot delete prompts and suggestions associated with your account.

Both free and business versions of Copilot do retain “user engagement data” — defined as “information about your interactions with the IDE or editor… actions like accepting or dismissing suggestions, as well as general usage data and error information” — and there’s no way to opt out of this. However, GitHub notes that this user engagement data is “stored in a way that does not directly identify you.”

4. Maintainability

If you don’t understand your code, you likely won’t be able to maintain it. This can be a concern when using Copilot, especially when the AI output represents a large portion of your program.

It’s important to pay particularly close attention to auto-generated comments; Copilot can’t necessarily be trusted to explain the code being emitted. For example, Copilot will happily generate comments that aren't at all valid (e.g. code examples that don't actually work). And, we’ve seen cases where users write a comment header and then generate a certain comment and code that’s not related to that comment at all.

Strategies to Reduce Maintainability Risks

First and foremost, you should carefully review comments generated by Copilot (or other AI coding tools) to make sure you understand and agree with them. If you don’t (or if you’re uncertain), consider erring on the side of deleting and writing your own.

Ultimately, from a maintainability perspective, the most important thing is that any engineer is able to later understand why code is included. If the engineer checking it in doesn’t understand this now, you can’t possibly understand it later.

5. Code Quality and Blind Trust

For all of the ways they help developers build more efficiently and effectively, GitHub Copilot and similar AI coding tools aren’t foolproof. There’s still a risk the tools will output biased, offensive, or low-quality code.

Strategies to Reduce Code Quality Risks

It’s best to view AI coding tools as basically a more powerful autocomplete, not fire and forget, and that certainly applies to ensuring code quality. For that reason, our view is that code should be reviewed by an engineer before it goes into the codebase; blindly accepting code is a no-go. Consider making sure engineers are responsible for code they check in, regardless of how it’s generated. If engineers check in biased or offensive code, they should be prepared to accept responsibility.

Additionally, although GitHub does have filters in place to prevent offensive suggestions from being output, the organization does ask that users report any incidents to copilot-safety@github.com.

Managing GitHub Copilot Risks: The Bottom Line

Different organizations will have different risk tolerances, so there’s no one-size-fits-all set of strategies or tools to address the concerns described in this blog. But we hope you find some of the strategies we discussed useful.

Another step we’ve seen some organizations take involves a conversation about potentially starting a cross-functional generative AI office. This group (which should include representation from at least legal, DevOps, and engineering teams) can create and implement policies governing the use of generative AI tools in software development and beyond. It might also be responsible for evaluating risk reduction strategies and tools (like the ones discussed in this blog) and staying on top of new developments in the generative AI landscape.

For more information about using AI coding tools like Copilot in a safe and responsible manner, we’d recommend you consider viewing our on-demand webinar “Managing GitHub Copilot Security and Legal Risks with FOSSA.” During the webinar, we discussed the suggestions from this blog in more detail and demoed new FOSSA features designed to help manage AI coding tool-related security and legal risks.

When developers build applications, they often use entire open source files. But they  may sometimes also pull in parts of files. These smaller blocks or lines of code are known as snippets.

Historically, programmers have included snippets from sites like Stack Overflow. AI coding tools like GitHub Copilot are also potential snippet sources; the AI tool may output a snippet of the open source library upon which it’s trained.

Although a snippet is only part of a larger file, the open source license that governs  the full file still applies to the snippet. If, say, a file is licensed under the GPL v3 license, a snippet from that file would be as well. Similarly, if a file is impacted by security vulnerabilities, using a snippet from that file may pose security risks as well.

Snippet scanning tools work by analyzing a snippet and matching it against a database of known open source components. The goal is to identify the full file (and accompanying license) where the snippet originated, along with potential vulnerabilities that impact it. This way, organizations can make sure they’re complying with open source licensing requirements, managing vulnerabilities, and keeping their software bill of materials accurate and up to date; The commonly used SPDX and CycloneDX SBOM formats both support snippets.

How FOSSA Snippet Scanning Works

The growing popularity of AI coding tools — and the concerns we’ve heard from customers about the potential snippet-related risks — prompted FOSSA to add snippet scanning functionality to our software composition analysis solution.

As with other snippet scanning tools, FOSSA detects snippets, matches them to full files, and surfaces important dependency metadata (such as the file name and open source license).

However, our specific approach to snippet scanning is different from some vendors. Snippet scanning tools generally use one of two methodologies to match snippets to their parent files:

• Function-level matching
• Expression-level matching

These are significantly different snippet-scanning implementations. Function-level matching detects functions in a file, whereas expression-level matches on expressions, of which there are commonly multiple per line. FOSSA’s snippet scanning features use function-level matching since we believe it produces significantly less noise than expression-level matching while still focusing on what users actually care about.

Snippet Scanning Example

Function-level matching would, for example, index the function “levenshtein” in the code block below, and then check if this function exists in the users’ codebase.

Expression-level matching would treat many permutations of the expressions inside this function as separate snippets. For example, depending on how aggressively the expression extraction is tuned, each line in this example function could consist of multiple snippets.

Function-level matching reduces noise due to the reduction in permutations that fit our match criteria. We believe this will meet our user’s needs because the snippets we detect will be less noisy than expression-level snippets.

Additionally, our view is that expressions are an unlikely source of meaningful risk. Developers don’t copy individual expressions without modification due to compiler errors; if they somehow can do so, the expression is so vague as to be purely noise.

Learn More About FOSSA Snippet Scanning

You can get a demo of our snippet scanning feature — along with guidance on managing risks that can come from AI coding tool output — in our on-demand webinar: “Managing GitHub Copilot Security and Legal Risks with FOSSA.”

Sometimes, SBOMs (software bill of materials) can feel more theoretical than tangible. There’s a lot of talk about the potential benefits of using SBOMs, like software supply chain security and regulatory compliance, as well as popular SBOM formats like CycloneDX and SPDX. But some of our customers (especially those early in their SBOM journeys) have mentioned that they’ve faced challenges making decisions in the real-world SBOM context.

With that in mind, I figured it would be helpful to put together a sample application and pair of SBOM examples that describe it. In this blog, you’ll find links to those two samples, along with a description of their sections and data fields.

Please note that in the interest of keeping this blog to a manageable length, I didn’t analyze every data field in our sample SBOMs. Rather, in addition to providing a high-level explanation for each section, I did my best to cover some of the less intuitive and/or potentially confusing fields you might encounter, such as declared vs. concluded licenses in SPDX.

All analysis in this blog will be based on the following two SBOM examples:

• Example SPDX SBOM
• Example CycloneDX SBOM

Please feel free to reach out to resources@fossa.com if you have any questions about specific data fields in our sample SBOM that I don’t cover in this blog.

SBOM Example 1: SPDX

SPDX (Software Packet Data Exchange) supports the tag/value (which it calls a “simple text-based format”), YAML, JSON, and Excel spreadsheet formats. Our example SPDX SBOM is in JSON.

Valid SPDX SBOMs will always include a section with document creation information. Depending on the composition of the bill of materials, it may also include sections to describe packages, files, snippets, licensing information, relationships, and annotations.

Document Creation Information

Document creation information covers the “who,” “when,” and “how” of an SPDX document.

The document creation information in our sample SPDX SBOM starts in Row 2 and concludes in Row 118. Some of the data fields are:

• Row 2: SPDX ID - This provides a standardized way to refer to the SPDX bill of materials throughout the document.
• Row 3: SPDX Version - This makes clear which version of the SPDX specification the bill of materials uses. Our example uses SPDX 2.3, which is the current version (though the upcoming SPDX v3.0 is under development).
• Row 10: License List Version - The SPDX License List is a collection of commonly used open source licenses, including short-form License Identifiers. The License List is periodically updated (albeit generally with very minor changes), which is why the License List version is part of document creation information.
• Row 119: Data License - An SPDX bill of materials must include the Data License, which essentially communicates that you’re using the SPDX specification under the terms of the Creative Commons CC0 1.0 Universal license.

Package Information

The package information section of our SBOM example starts on Row 120. Since our application relies on numerous packages, our sample SBOM includes multiple package entries. However, we’ll discuss only one of them here.

Some of the data fields in the package information section are:

• Row 122: SPDX ID - This is the package SPDX identifier field. It’s used to uniquely reference the given package in the SPDX document.
• Row 128: Supplier - This is the “actual distribution source” for a given package. This should be an author (or organization), not a host website. Supplier differs from Originator (Row 127) in that the latter refers to the point of origin, while Supplier refers to the point of distribution.
• Row 131: License Declared - This is the package license as stated by the component author. This differs from the Concluded License (Row 134) in that the Concluded License is stated by the SPDX document creator (often an SBOM tool), which is why these fields sometimes have different values.
• Row 135: Checksums - The intent of the package checksum field is to help SPDX document consumers determine whether any file in the original package has been changed.
• Row 181: External References - This data field is often used to link to security documents, such as VEX (Vulnerability Exploitability eXchange), or package identifiers, like PURL.

Relationships

This part of our SPDX SBOM is used to describe the nature of relationships between SPDX elements. These elements may be packages, files, and/or snippets, or even the bill of materials itself. (Rows 4633 - 4635 explain that our SPDX SBOM is describing our Recipe Book application.) Relationships are commonly used to describe the nature of dependencies, such as one element depending on another (or containing another). SPDX offers numerous ways to describe relationships, such as “DependsOn,” "DependencyOf,” "Contains," and many more.

File Information

As mentioned, SPDX can describe not only packages, but files (and snippets), too. Our example SBOM doesn’t include any snippets, but, starting on row 6661, it describes several files. The data fields in the File Information section are similar to the Package Information section, although there are a handful of differences. (For example, although they’re not included in our sample, the Package Information section has fields that can be used to communicate release date, build date, and valid-until date. And, the File Information section has fields that can be used to communicate file notices and file contributors.)

Other Sections

These aren’t included in our example, but SPDX also supports the following sections:

• Snippet Information: Used to describe part of a file, with data fields including byte and line range.
• Annotation Information: Used to provide additional context and comments related to a part of or the full bill of materials.
• Other Licensing Information Detected: Used to provide additional context about uncommon licenses — those not on the SPDX License List — that may appear in a bill of materials.

SBOM Example 2: CycloneDX

Like SPDX, CycloneDX supports multiple types of file formats. These include JSON, XML, and Protocol Buffers. Our example CycloneDX SBOM is in the JSON format.

A valid CycloneDX bill of materials will always include document creation information (BOM Identity and Metadata sections). Depending on the composition of the bill of materials, it may also describe components, services, dependencies, compositions, vulnerabilities, formulation, annotations, and extensions.

BOM Identity

A CycloneDX bill of materials includes several data fields that identify the document version and file format (i.e. the document “Identity”). These include:

• Row 4: Spec Version - Our example uses CycloneDX v1.4. (A new version of the specification, CycloneDX v1.5, was recently released.)
• Row 5: Version - This is the first version of our bill of materials for this application. Each time we make changes to our BOM, we’ll add 1 to that number. The second version would be “2,” the third version “3,” and so on.
• Row 6: Serial Number - Each bill of materials should have a unique serial number.

Metadata

In CycloneDX, the Metadata section communicates the component (e.g. application, hardware, etc.), supplier, and manufacturer that the bill of materials describes.

• Row 9: Component - CycloneDX is a versatile standard that can be used to describe applications, libraries, hardware, files, and much more. Row 10 (Type) is used to specify which type of component the bill of materials describes. In our sample, this is an application.
• Row 28: Manufacture - This data field communicates the organization that manufactured the component.
• Row 40: Supplier - The supplier is often the same as the manufacturer, but it can sometimes be different, such as in cases where a distributor or repackager is involved. In our sample, the manufacturer and supplier are the same.

Components

This section describes the individual first- and third-party components that make up the application (or hardware, file, etc.) the CycloneDX document describes.

As you might expect, our application relies on many different components; for the purposes of this blog post, we’ll just review one of them, the CodeMirror library.

• Row 55: Type - As was the case in the Metadata section, “Type” is used to describe the nature of the component being analyzed. In our case, this is a library.
• Row 58: BOM-Ref - This is a unique identifier that’s used to identify the component elsewhere in our CycloneDX bill of materials.
• Row 74: PURL - PURL is a helpful way to accurately identify packages, including the ecosystem (package manager) and unique version.

I’d also note that although we don’t have any in our example SBOM, CycloneDX has an External Reference data field that can be used to provide additional information on a Component. CycloneDX supports an extensive list of External References, including multiple security analysis reports, VEX, release notes, and more.

Dependencies

The Dependencies section can be used to depict direct and transitive dependencies. It uses the BOM-Ref element discussed in the previous section to describe the nature of dependency relationships.

For example, in Row 2391, we see that our application depends on multiple packages, including codemirror and code-js.

Vulnerabilities

This section (which starts on Row 2933 in our example) is used to communicate vulnerabilities in components or services. Fields include ID, which is used to uniquely identify the vulnerability (such as a CVE number, like in Row 2936). The “Ratings” section (such as Row 2941) includes metrics like severity, score, and method (i.e. the methodology used to grade severity and score).

Other Sections

These aren’t included in our example, but CycloneDX also supports the following sections

• Services: External APIs your software may call
• Compositions: Communicates the completeness of a component, service, or dependency relationship
• Formulation (new to CycloneDX v1.5): Describes how something was deployed or manufactured
• Annotations (new to CycloneDX 1.5): Allows for comments or explanations that provide additional context on part (or all) of the bill of materials

Additional SBOM Resources

I hope this blog post helped bring to life the data fields and sections you might find in a software bill of materials. For more information about building and managing an effective SBOM program, I’d recommend you consider checking out the following resources:

The Minimum Required Elements of a Software Bill of Materials (Blog): The data fields in an SBOM can vary significantly depending on a number of factors, including your intended use cases. Organizations that sell into the federal government (and, as such, prioritize regulatory compliance) should make sure to generate SBOMs that include these minimum elements.

Generating, Managing, and Importing SBOMs with FOSSA (On-demand webinar): Learn how to automate SBOM document creation — as well as management and import — in this workshop-style on-demand webinar.

How SBOMs Can Strengthen Security (Blog): Security is a well-known SBOM use case. But, dig a little deeper, and you’ll find some potentially surprising ways you can leverage SBOMs (and SBOM tools) to strengthen your security program.

SPDX License Identifiers are standardized abbreviations for common open source software licenses. For example, the License Identifier for the Apache License 2.0 is Apache-2.0.

SPDX License Expressions are used to communicate the context that informs how a license(s) applies to the open source code it governs. For example, License Expressions can be used to describe license exceptions (e.g. GPL classpath) and multi-licensing scenarios, among others.

Together, License Identifiers (also referred to as License IDs) and License Expressions work in tandem to communicate open source licensing information accurately and simply in an SPDX bill of materials. They are also used in the REUSE Specification, which is designed to help reliably identify licensing information in source files.

License Identifiers and Expressions are important because they address several areas of potential confusion and friction related to communicating licensing information. These include:

• There are multiple versions of many common open source licenses, but it’s not always clear which version(s) apply to a given software component. For example, simply saying a license is “GPL” doesn’t make it clear what version of the GPL (or even the LGPL or AGPL) governs a given file. This has the potential to create confusion for SBOM consumers.
• Multi-license scenarios can be difficult to communicate and interpret.
• It can be time-consuming and difficult to add long-form license names and license text to each file.

In this blog, we’ll provide additional context around License Identifiers and explain how to use them. We’ll also discuss the six types of SDPX License Expressions, with examples for each.

License Identifiers and the SPDX License List

SPDX License Identifiers are based on the SPDX License List. The License List is a comprehensive listing of common open source licenses, including the following descriptors along with the full license text:

• Full license name
• License Identifier
• Whether the license is OSI (Open Source Initiative) approved
• Whether the license is listed as free by the Free Software Foundation

Each entry in the “Full License Name” column links to a separate page with more information and context about a given license, including links to the license text and, if applicable, the OSI page.

The License List is continuously updated to account for new licenses (and to deprecate licenses which have been superseded by other licenses). Always note the license list version, currently 3.21 2023-06-18, which you may find on both the SPDX license list or a generated SPDX SBOM.

It’s worth noting that the use of SPDX License Identifiers isn’t limited to only SPDX. CycloneDX (the other commonly used machine-readable bill of materials format) has integrated License Identifiers, meaning that if you deal in SBOMs with compliance information, you’ll often come across SPDX IDs, regardless of specification.

SPDX License Expressions

Not every software component will be under just one of the licenses on SPDX’s License List. You might encounter a choice-of-license or multi-license situation. Or, there are times when an (uncommon) open source license won’t have an SPDX License Identifier. SPDX License Expressions account for these situations along with more conventional single-license scenarios.

There are six types of license expressions, which we’ll review below.

Simple License Expressions

• Where there’s a single license and that license has an assigned SPDX License Identifier
• When there’s a single license but that license doesn’t have an assigned SPDX License Identifier
• When there’s a single license, but later versions of the license are also permitted

Composite License Expressions

License Exceptions

Sometimes, licensors choose to add permissions or restrictions to open source licenses. SPDX refers to these as exceptions. One particularly well-known example is the GPL Classpath Exception, which allows linking of GPL libraries with independent modules to produce an executable under terms of the licensee’s choice, provided that those terms are compatible with other linked libraries.

SPDX uses the syntax “WITH” to communicate License Exceptions. You can find the full list of SPDX Exceptions on the specification’s website. Interestingly, although the current SPDX 2.3 has a defined list of exceptions, the forthcoming release of SPDX v3.0 is expected to add the ability to use custom exceptions.

Choice-of-License Scenarios

In other cases, software may be offered under a choice of multiple licenses. These are also referred to as disjunctive licenses. SPDX uses the syntax “OR” to communicate disjunctive license scenarios.

Multiple-License Scenarios

The third composite license expression is when two or more licenses must be simultaneously applied; in other words, the licensee must comply with the terms of multiple licenses. These are also referred to as conjunctive licenses. SPDX uses the syntax “AND” to communicate conjunctive license scenarios.

There are also occasions when you may see a combined license expression, where, for example, there are both conjunctive and disjunctive license scenarios. This, of course, may raise the question: Which license expression takes precedence over the other?

SPDX’s default order is as follows:

+
WITH
AND
OR

For example, software under either a) the Mozilla Public License 2.0 or b) both the MIT and ISC licenses would be communicated as:

MPL-2.0 OR ISC AND MIT

Because “AND” takes precedence over “OR,” this license expression would be interpreted as:

• ISC and MIT

OR

• MPL-2.0

Much like in algebraic expression, parentheses are used in situations where there is a different order than the default. For example, if the intent of an expression is:

• MPL-2.0 OR ISC

AND

• MIT

This would be expressed:

(MPL-2.0 OR ISC) AND MIT

Using SPDX License Identifiers and Expressions

Before we explain how you can use SPDX License Identifiers with the License Expressions discussed above to communicate a range of licensing scenarios, it’s important to cover a few contextual notes

1. SPDX has multiple different license fields, including “Declared” and “Concluded” licenses. The “Declared” license is stated by the component (e.g. package or file) author, while the “Concluded” license is determined by the SPDX document creator (which is often an SBOM tool or the document creator in the case of disjunctive licenses). For the purposes of this exercise, we’ll use the “Declared” field.
2. SPDX supports multiple file types, and the formatting for each is slightly different. For the purposes of this exercise, we’ll use the tag-value format.

Simple License Expressions

Single License with an Assigned SPDX License Identifier

In a hypothetical where the “Declared License” is the MIT, this would be communicated as follows:

PackageLicenseDeclared: MIT

Single License Without an Assigned SPDX License Identifier

This is communicated with a user defined license reference. For example, consider the hypothetical new open source license “DZD,” which doesn’t have an SPDX License Identifier. This would be communicated as follows:

PackageLicenseDeclared: LicenseRef-DZD

Single License or Later Version of that License

A single license with an assigned SPDX License Identifier, where the “Declared License” is the Apache 2.0 or any later version, would be communicated as follows:

PackageLicenseDeclared: Apache-2.0+

Composite License Expressions

License Exceptions

License exceptions are communicated using “WITH.” For example, the GPL v2.0 with classpath exception is communicated as:

PackageLicenseDeclared: GPL-2.0-only WITH Classpath-exception-2.0

Choice of License (Disjunctive)

When there’s a choice between multiple licenses, the “OR” expression is used. For example, a disjunctive licensing scenario with the MIT or Apache 2.0 licenses would be communicated as:

PackageLicenseDeclared: MIT OR Apache-2.0

Multiple License (Conjunctive)

When two or more licenses must be followed, the “AND” expression is used. For example, a conjunctive licensing scenario with the Apache 2.0 and LGPL 2.1 licenses would be communicated as:

PackageLicenseDeclared: Apache-2.0 AND LGPL-2.1-only

More SPDX and SBOM Resources

We hope you found this overview of SPDX License Identifiers and Expressions useful. For a more comprehensive breakdown of using SPDX for license compliance (and some additional nuances related to License Identifiers and Expressions), we’d recommend referencing SPDX Annex D, which defines the license expression syntax, as well as the full SPDX spec.

For additional perspectives on SPDX and building an effective SBOM program, consider checking out the following on-demand webinars:

• On-Demand Webinar: An Insider’s Guide to SPDX, Featuring Gary O’Neall (SPDX Co-Tech Team Lead)
• On-Demand Webinar: Generating, Importing, and Managing SBOMs with FOSSA

The Business Source License (BSL) is a middle ground of sorts between open source and end-user licenses. The BSL (also sometimes abbreviated as BUSL) is considered a source-available license in that anyone can view or use the licensed code for internal or testing purposes, but there are limitations on commercial use.

Unlike open source licenses, the BSL prohibits the licensed code from being used in production — without explicit approval from the licensor.

But, similar to open source licenses, BSL-licensed source code is publicly available, and anyone is free to use, modify, and/or copy it for non-production purposes.

Additionally, after a set period of time, either four years or an earlier period set by the licensor, the BSL automatically converts to an open source license of the licensor's choosing. However, the open source license must be compatible with GPL, and it usually applies only to specific software versions on a rolling basis, based on the date of release.

Note: Two versions of the BSL have been released: the original 1.0 and the current 1.1. Assume all references in this blog are to the current BSL 1.1 unless otherwise stated.

Business Source License Requirements and Provisions

The Business Source License has provisions in common with both open source and end-user licenses. It also has a few non-standard clauses that are important to understand. Here’s a look at the license’s key requirements, provisions, and exceptions.

Required Change from BSL to Open Source License

Software licensed under the BSL will not stay under the BSL forever. This is because of a provision that requires software under the BSL to convert to an open source license within four years after its release date. This is sometimes called a “springing license.”

It’s important to note that this requirement applies to specific software versions. If you release v1.0 of your software under the BSL on January 1, 2025, v1.0 must convert to a GPL-compatible license by January 1, 2029. But the four-year clock won’t begin for subsequent versions until the “first publicly available distribution of a specific version.”

Within those general constraints, the licensor has the freedom to decide exactly when the license change will happen (“Change Date”) and what the new license will be (“Change License”).

• Change Date: The licensor can specify a date for the license change as long as that date is within four years of the software version’s release. If no date is specified, the change will automatically happen four years after the software is released under the BSL
• Change License: The Change License must be GPL v2 (or later), or a license compatible with GPL

Using BSL-Licensed Software in Production

The BSL doesn’t allow licensed code to be used in production unless the licensor uses the “Additional Use Grant” mechanism. The Additional Use Grant allows the licensor to identify specific circumstances where licensed code can be used commercially.

The BSL does not define “production” use. Many licensors use Additional Use Grants to clarify the definition or to broaden the rights granted.

For example, Hashicorp’s BSL implementation (which made headlines when the company announced its change from the Mozilla Public License) includes an Additional Use Grant that does allow for production use — except in products that are competitive with Hashicorp’s. Sentry (an application monitoring platform) uses a similar Additional Use Grant to prohibit competitors from using its BSL-licensed code in production.

MariaDB, the license author, takes a different approach. Its Additional Use Grant allows commercial use only if “your application uses the Licensed Work with a total of less than three server instances in production.”

In situations where you want to use BSL-licensed code — but your production use case isn’t covered by an Additional Use Grant — the license states that “You must purchase a commercial license from the Licensor, its affiliated entities, or authorized resellers, or you must refrain from using the Licensed Work.”

Other BSL Provisions

As mentioned, anyone is free to use, redistribute, copy, modify, and create derivative works of BSL-licensed code for non-production purposes. Additionally, you are required to include a copy of the BSL text in any copy or modification of a BSL-licensed work.

History of the Business Source License

In 2016, MariaDB (a cloud database company founded by members of the core MySQL team) released v1.0 of the Business Source License. MariaDB CTO Michael 'Monty' Widenius explained the rationale for creating the license in a ZDNet interview a few years prior. Widenius said, in part:

“You can get access to all the source. You can use it in any way but the source has a comment that says you can use it freely except in these circumstances when you have to pay… Because you have the code, you know that if the vendor does something stupid, somebody else can give you the support for it. So you get all the benefits of open source except that a small portion of users has to pay. As long as you continue to develop the project, each version still gets a new timeline…"

In 2017, MariaDB released its first (and to date only) new version of the license, BSL 1.1. The BSL 1.1 was created with input from Heather Meeker (a leading IP attorney and open source licensing expert) and Bruce Perens (co-founder of the Open Source Initiative).

The essence of the two versions is similar, but there were several notable differences, including:

• In v1.1, the “Change License” (e.g. the open source licenses that the BSL eventually converts into) must be GPL compatible. There was no such requirement in v1.0.
• In v1.1, the “Change Date” (e.g. the date on which the BSL converts to an open source license) must be within four years of the software release date. This time constraint didn’t exist in v1.0.
• While v1.0 allowed the licensor to specify situations where the licensed software could not be used (“Usage Limitation”), v1.1 takes the opposite approach. It introduces “Additional Use Grants,” which the licensor can use to communicate circumstances where the licensed code can be used in production.

Additional Software Licensing Resources

For more information on software licensing, consider checking out the following articles from leading IP attorney Heather Meeker:

• Heather Meeker on the AGPL: Heather analyzes the AGPL (a network copyleft license), including its source code disclosure provision
• Heather Meeker on Open Source License Notices and Automation: Heather discusses open source license notices (including how they differ from copyright notices) and the role of automation in simplifying notice creation
• Heather Meeker on Open Source License Compliance Tools: Heather shares guidance on evaluating license compliance technologies and strategies for getting more value from existing tools