Introducing Grant: A new OSS project from Anchore for inspecting and checking license compliance from SBOMs

Today Anchore has released Grant, a tool to help users discover and reason about software licenses. Grant represents our latest efforts to build OSS tools oriented around the fundamental idea of creating SBOMs as part of your development process, so that they can be used for multiple purposes. We maintain Syft for generating SBOMs, and Grype for taking an SBOM and performing a vulnerability scan. Now with Grant, that same SBOM can also be used for performing license checks.

Knowing what licenses you have is critical to ensure the delivery of your software. It’s important to account for all of the licenses that you are beholden to in your transitive dependencies before introducing new dependencies (and well before shipping to production!). For example, you might want to know the package under which a GPL (General Public License) is discovered within the dependencies of a certain software before releasing, or what license a new software library might require. This evaluation tends to not be a one-time decision: you need to continually ensure that the dependencies you are using are not swapping to different licenses after you initially brought that dependency into your codebase. Grant aims to aid in solving the above issues through the use of its check and list commands.

Grant - Design and Launch Features

Grant takes either a Software Bills of Material (SBOM), a filesystem with a collection of license files, or a container image as input. Grant can either generate an SBOM for the different provided inputs or read an SBOM provided as input. Grant has two primary commands:

• list: show me discovered licenses
• check: evaluate a list of licenses to ensure your artifacts are compliant to a given policy

List 

The list command can display licenses discovered from the SBOM and their related packages. It can also filter licenses to show which licenses are not OSI approved, which licenses are not associated with a package, and which packages were found with no associated license. Users can use the list to show the discovered licenses for a given container image. Here is an example using grant to display all the licenses found for the latest redis image:

You can also get more detailed information about the licenses from the json output by using the -o json flag. This flag provides a json formatted output which shows the locations of the discovered license, if it has an SPDX expression, and the packages and locations of those packages for which it was discovered

Check

The check command can evaluate given inputs for license compliance relative to the provided license rules. One thing users can look out for when trying to understand their license posture is if a license that was previously permissive has changed. Check allows the user to express simple policies that will pass/fail the command depending on what Grant discovers:

rules:
    - pattern: "*gpl*"
      name: "deny-gply"
      mode: "deny"
      reason: "GPL licenses are not allowed"

Here is grant running check with the above configuration against the same redis image as the list example

Users can also use a -o json option to return a more detailed and machine readable view. This output allows users to see more detailed license information if a license is matched to an official SPDX ID. This includes text of the license, references to its clauses, and sections or rules showing if a license was not found for a package.

Grant can be configured to accept multiple sources, including those from container images, directories, licenses, and software bills of materials. Grant stitches these sources into a report that can then display the license contents of each source. This report of licenses can be optionally paired with a policy file that gates/limits an execution (pass/fail) on the presence or lack of a predetermined set of licenses. Policy files have the ability to include exceptions for packages that are not used or that organizations deem are not applicable to their compliance policy.

Grant’s approach to license identification

Grant takes a simplified approach to asserting on and establishing a license’s presence. It first tries to match all discoveries when possible to the SPDX license list. For sources with more complex expressions, grant will try to break those expressions into the individual license IDs. This should allow the user to make decisions about which licenses are relevant to the project they are working on. An example of this is something like the SPDX expression `LGPL-2.1-only OR MIT OR BSD-3-Clause`discovered for the package `foobar`. If this expression was discovered then the 3 different licenses would be associated with the package. If users need an exception they can then construct a policy that allows them to exclude non permissive licenses from the statement:

pattern: "LGPL-2.1"
name: "deny-LGPL-2.1"
mode: "deny"
reason: "LGPL-2.1 licenses are not allowed by new corporate policy"
exclusions:
    - "foobar"

One notable inclusion in the code is grants use of the license classifier from google to recognize licenses that are input to the tool and assign them a confidence level. Further enhancements are planned to allow for SBOMs that provide the original license text to also be run against the classifier.

SPDX license compatibility

The landscape of open source licenses is vast and complex with various licenses having different terms and conditions. It can be challenging to understand and manage the obligations associated with each license. While grant makes no claim on establishing if licenses are compatible with each other, it can establish if a discovered license has an ID found in the latest SPDX license list. Users can use the grant list command with the --non-spdx flag to get an idea of which licenses were unable to be matched to a corresponding SPDX ID. This should allow users to find gaps where Grant might not be making the right choice for SPDX ID association, while also pointing out interesting one off licenses and their locations that might be private or custom to a certain vendor:

Conclusion

Grant is another open source tool from Anchore that can help improve your software processes. Simply by generating SBOMs for your software and making them available, you can now easily gate incoming code changes and steps of your delivery pipeline that are sensitive to licensing concerns.

Go download Grant here and try it for yourself!