Documentation Index
Fetch the complete documentation index at: https://docs.semgrep.dev/llms.txt
Use this file to discover all available pages before exploring further.
PREREQUISITEAt least one repository that scans for dependencies through Semgrep Supply Chain. See Scan third-party dependencies.
Language support
Licenses are detected based on the package manager used. See Supported languages for a list of supported package managers.Types of license policies
Licenses in Semgrep can be assigned any of the following policies:| Description | |
|---|---|
| Allow | Packages with licenses assigned this type of permission are allowed for use in the codebase. |
| Comment | Packages with licenses assigned this type of permission are allowed for use in the codebase. A comment is added to the PR or MR introducing the package into the codebase. This permission can be useful when you want to remind or warn developers to use certain licenses for internal use only. |
| Block | Packages with licenses assigned this type of permission are not allowed into the codebase. A comment is added to the PR or MR introducing the package into the codebase and the diff-aware scan exits with code 1. |
View license policy
To view a package’s license policy:Change the license policy
To change the policies of packages based on the license:Sign in to Semgrep AppSec Platform, and navigate to Rules & Policies > Policies > Supply Chain > License configuration.
License information
License information is often stored in the package’s repository alongside the source code. You can generally find this information in:- A license file, such as
LICENSEorLICENSE.txt - The manifest file, such as the
pyproject.tomlorpackage.json, which typically specifies alicensefield
License categories
Semgrep Supply Chain can identify the following licenses and license categories.Popular Weak-copyleft licenses
Software using packages with weak copyleft licenses may have to maintain the same license as the package. To determine if this applies to your project, consult your legal department. Developers typically choose these packages based on individual preferences, so usage should be monitored to ensure license compliance.- LGPL-3.0
- LGPL-2.1
- MPL-2.0
- EPL-2.0
- OSL-3.0
- EUPL-1.2
Popular Copyleft licenses
Software using packages with copyleft licenses must maintain the same license as the packages. To prevent license complications, developers often avoid packages using these licenses.- GPL-3.0
- GPL-2.0
- AGPL-3.0
- AGPL-2.0
- CC-BY-SA-4.0
- APSL
Popular Permissive licenses
Packages with permissive licenses have minimal restrictions on how they can be used or modified. This makes permissive licenses popular among developers for their flexibility, ease of use, and lack of legal concerns.- MIT
- Apache-2.0
- BSD-3
- BSD-2
- BSD-3-Clause
- BSD-2-Clause
- CC_BY-4.0
- WTFPL
- MS-PL
- Unlicensed
Other licenses
Packages tagged as Other are those with licenses that aren’t yet categorized by Semgrep Supply Chain or aren’t included in the categories of weak-copyleft licenses, copyleft licenses, or permissive licenses. This category includes all other standard Software Package Data Exchange (SPDX) licenses. The Other license category may include packages with copyleft or permissive licenses. Consult your legal department before using packages in this category.Multiple license types
Some packages utilize multiple licenses. Semgrep treats packages with multiple licenses as if all licenses apply and behaves according to the strictest policy. For example, if a package allows use under the MIT license or the GPL-3.0 license, and the GPL-3.0 license is set to Block, but the MIT license is set to Allow, a pull request that adds the package is blocked. You can add an exemption for the package if subsequent review indicates the dependency is safe for use under any of the detected licenses.Create exemptions
You can create exemptions to allow specific dependencies with licenses that are typically blocked. This feature is useful for internal dependencies not accessed by users or external APIs. exemptions are currently version-specific, so each version used must be exempted individually. To exempt a package:
Exempted dependencies appear in the Supply Chain > Settings tab.
Create custom dependency exceptions
Custom dependency exceptions allow you to manually list the dependencies that should NOT prevent Semgrep from blocking a pull request or merge request due to licensing issues. For example, ifbitwarden/cli@2023.9.0, which has a GPL-3.0 license, is on the allowlist, you must add an additional exception when upgrading to bitwarden/cli@2023.9.1. However, the dependency to which you’re upgrading isn’t yet listed in Dependencies; they appear only after you’ve scanned your project. Because the dependency isn’t listed, you must manually create the exception. This ensures that the exclusion won’t fail when you upgrade to bitwarden/cli@2023.9.1 and scan your project again with Semgrep Supply Chain.
To set a custom dependency exception:
In the Add custom dependency exception window that appears:i. Select the Ecosystem where this dependency applies.ii. Provide the Package name, for example,
bitwarden/cli.iii. Provide the Version information for the package. The major, minor, and patch version information is required; pre-release and build metadata are optional.iv. Click Add to save and add the exception.