The Importance of Accurate Open Source Licenses in SBOMs

In today's software development landscape, open source software has become ubiquitous. Developers rely on third-party libraries and frameworks to accelerate development and enhance functionality. However, with the increasing use of open source components, it has become crucial to manage and understand the licenses associated with these components. This is where a software bill of materials (SBOMs) with accurate holistic detection of open source license detection plays a vital role.

How SBOMs relate to third-party software

A Software Bill of Materials (SBOM) is a nested inventory or a list of components that comprise a software package. This list includes but is not limited to open source components, proprietary components, and third-party libraries that a piece of software directly uses or includes.

It provides detailed information about the components, including their origins, versions, and dependencies. SBOMs offer transparency and ensure effective management of software supply chains, enabling organizations to track and mitigate security vulnerabilities and license compliance issues. They are crucial for third-party software because they help organizations understand the composition of their software, identify vulnerabilities or known issues, and make informed decisions regarding patching or upgrading. They provide transparency and traceability, allowing developers to track, update, and patch third-party components accurately.

The Significance of Snippet Level License Detection

Open source licenses govern the terms and conditions under which open source software can be used, modified, and distributed. They define the rights and obligations of the software user. Each open source project typically has its own license, and it is vital to understand and comply with these licenses to avoid legal and compliance risks. Some licenses require that any derivative work should be under the same license (copyleft), while others allow for more liberal use without such obligations.

Snippet-level detection refers to identifying and analyzing the licenses of individual code snippets within a larger codebase. This detection level is crucial because a single codebase can consist of multiple open source components, each with its own or multiple attached licenses. By identifying licenses at the snippet level, organizations can accurately determine the licensing obligations associated with specific code fragments, ensuring compliance and avoiding license conflicts. An SCA tool that only looks at the component or library level will miss any licenses in copied and pasted code, including the snippets commonly discovered in code generated by AI developer tools such as Github Copilot. Snippet-level detection ensures the legal integrity of a software project and contributes to the broader culture of credit and collaboration in the open-source community.

Perceived Accuracy

One important aspect of open source licenses that is often overlooked is that they can and do change over time. These changes can have significant impacts on users of the software, particularly if the license changes from a permissive type, which allows a broad range of uses, to a copyleft or "viral" license, which requires derivative works to be released under the same license.

There are many reasons why a project might change its license. The project maintainers may want to encourage certain types of use or discourage others. They might want to ensure that anyone who modifies the software contributes their changes to the community, which is a common motivation for switching to a copyleft license. Regardless of the reason, when a license changes, it's important for users of the software to be aware of the change and understand its implications.

Knowing that you are being given the correct license involves trusting the software composition analysis tool that provides license compliance as part of its solution. All licenses should come with a URL pointing to where the code is hosted. Thereby allowing the auditor to verify the proof of the original author.

MongoDB is an example of a well-known open source project that changed its license. In 2018, MongoDB switched from the AGPL (Affero General Public License), which is a moderately permissive open-source license, to the Server Side Public License (SSPL). The SSPL is much more restrictive and has been described as a "viral" license because any service that uses MongoDB as a component must also be open source and released under the SSPL. This change was controversial and led to some organizations, such as Red Hat, deciding to no longer include MongoDB in their distributions.

An accurate SBOM

Component Details: A comprehensive list of all open source components used, including their names, versions, and origins, with a URL pointing to where the code is hosted. The list of components should always include declared components from dependency managers and discovered or source components from source code files, forked projects, CDN references, and snippets of code, among numerous other ways developers use open source.

License Information: Each component's associated license(s) should be clearly stated, including the license type, version, and additional permissions or restrictions.

Dependencies: The SBOM should capture the dependencies between components, ensuring that organizations completely understand the software's composition and potential vulnerabilities, including how components are related and which components depend on others.

Vulnerability Information: It is essential to include any known vulnerabilities associated with the open source components, enabling organizations to prioritize and address security issues effectively.

Best Practices?

To effectively manage licenses, organizations should consider the following best practices.

Establish License Management Policies: Define clear policies and guidelines for selecting, evaluating, and using open source components through documented policies. This should include guidelines on what licenses are acceptable and which are not, based on the organization's business model and risk tolerance. This helps ensure that all stakeholders know their license compliance responsibilities.

Leverage Automation: Leverage Threatrix to assist in scanning codebases for open source components and identifying all single and dual-licensed projects down to the snippet level. This will significantly reduce the manual effort required to manage licenses.

Build Time Generated SBOMs: Keep SBOMs up to date by continuously monitoring for new vulnerabilities and updates to open source components during the build process of the software. New open source components get added, existing ones may be updated or removed, and new vulnerabilities may be discovered in these components.?

Integrating SBOMs into the build process ensures that changes to the components of the software are immediately reflected. This provides a real-time view of the software's composition and helps in tracking any potential vulnerabilities that might arise from these changes. This practice encourages automation, which improves efficiency and accuracy. This leads to decreased technical debt by quickly alerting developers to issues that need their attention.

This will serve as an important tool in maintaining up-to-date and secure software, fostering best practices in open source license management, and supporting ongoing risk assessment and mitigation efforts.

These challenges highlight the importance of combining the use of Threatrix with other practices for managing #opensource licenses, such as regular audits, manual reviews, and developer education. Even the best tools should be seen as aids that can help manage open source licenses more effectively, but not as the sole solution.