> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/application-security/software-supply-chain-security/risk-and-remediation/software-composition-analysis-sca-scanners/license-miscompliance-issues.md). # License miscompliance issues License compliance scanners safeguard your software supply chain by identifying non-compliant open-source licenses in packages and third-party libraries consumed by your applications. By detecting license violations at code-time, the license scanner closes the gap between open-source dependency consumption and organizational license compliance policies, preventing copyleft obligations, commercial use restrictions, and undisclosed licensing terms from silently propagating into production environments through unvetted upstream packages. The Licenses page consolidates all scanner-detected license miscompliance issues across monitored repositories into a single view where you can prioritize, investigate, escalate to legal review, and track SLA compliance. **Scope:** The Licenses page displays license compliance issues detected in open-source dependencies through Software Composition Analysis (SCA). ## Prerequisites Before viewing and acting on license miscompliance issues, verify the following: | Prerequisite | Description | | ------------------- | ---------------------------------------------------------------------------------------------------- | | License | An active Cortex Cloud license with Application Security entitlements | | RBAC Role | The AppSec Admin or SOC Analyst role, or an equivalent custom role with issue management permissions | | VCS Integration | At least one Version Control System (GitHub, GitLab, Bitbucket, Azure DevOps) integrated and active | | SCA Scanner | The SCA scanner enabled for the target repositories | | Periodic or PR Scan | At least one completed periodic scan or PR scan that includes SCA scanning results | ### What license miscompliance issues deliver License miscompliance issues close the gap between the open-source dependencies declared in your codebase and the license compliance posture of your organization. Without pre-deployment license scanning, packages with strong copyleft obligations, non-permissive restrictions, or unknown licensing terms propagate silently into production environments, creating legal exposure that is expensive to remediate after deployment, including mandatory source code disclosure, licensing fees, and restrictions on commercial distribution. ### Core achievements * **Shifting compliance left:** Detecting non-compliant open-source licenses at code-time, before packages with restrictive terms are deployed, reduces the cost and risk of post-deployment legal remediation * **Reducing legal risk exposure:** License category classification isolates strong copyleft, non-permissive, and unknown licenses from permissive licenses, enabling targeted legal review of the highest-risk dependencies * **Establishing compliance baselines:** Mapping license findings to OSI approval status and SPDX recognition provides auditable evidence of compliance with organizational open-source policies and regulatory mandates * **Accelerating legal review:** Surfacing non-compliant packages with license category, dependency type, and package manager context enables the legal team to evaluate license compatibility without manual dependency audits ## Understand the Licenses table The Licenses table provides a consolidated view of all license miscompliance issues. Each row represents an issue created when a scanner finding matches a unified policy, linking the license violation to a specific license identifier, package, dependency manifest file, repository, and the policy that triggered the issue. By default, the table displays issues that are unresolved and not excluded. The columns in this table are documented in a shared reference. For descriptions of every available column, the attributes common to all code scan issue tables and the attributes specific to this issue type, see [Issue table attributes reference](/application-security/code-security/code-security-scanners/issue-table-attributes-reference.md). ### Filter and sort the table Use the filter bar at the top of the Licenses table to narrow results by any filterable column. Common filtering strategies include: * **Severity:** Filter to High severity to focus on strong copyleft and non-permissive license violations that carry the greatest legal risk * **License Category:** Filter to Strong copyleft to identify packages with derivative work obligations that may require source code disclosure * **License:** Filter to a specific license identifier (such as GPL-2.0, AGPL-3.0) to scope review to a single license type * **Package Manager:** Filter to a specific package ecosystem (such as NPM, Maven) to scope review by technology stack * **Dependency Type:** Filter to Direct to focus on dependencies explicitly declared in the project, or to Transitive to identify non-compliant licenses inherited through the dependency chain * **Repository:** Filter to a specific repository to scope review to a single codebase * **Branch:** Filter to the main or production branch to focus on license issues that affect production-bound code * **Resolution Status:** Filter to New to identify untriaged license issues, or to In Progress to monitor active remediation * **Approved OSI:** Filter to False to identify packages with licenses that are not approved by the Open Source Initiative ## Investigate a license miscompliance issue Select any row in the Licenses table to open the issue side panel. The side panel provides detailed context for investigation and legal escalation. **General details** The top section of the side panel displays the following fields: * **Severity:** The severity level of the license miscompliance issue * **Status:** The current resolution status (New, In Progress, Resolved). * **Assignee:** The user assigned to the issue * **SLA:** The SLA compliance status, calculated from the issue creation date and the severity-based target resolution window * **Backlog Status:** The backlog classification of the issue (New, Active, Stale) {% hint style="info" %} ### Note **Important:** License miscompliance issues do not have urgency signals. Unlike CVE vulnerability issues, license issues are legal compliance risks — not security vulnerabilities. Urgency signals such as EPSS score, KEV status, reachability analysis, and Code-to-Cloud deployment context do not apply to license compliance evaluation. {% endhint %} **Impact section** The Impact section in the side panel provides the legal risk context for the detected license: * **Package Manager:** The package ecosystem where the non-compliant dependency was detected * **License Impact:** A description of the legal implications of the detected license, including obligations such as source code disclosure, licensing fees, or restrictions on commercial use **Evidence section** The Evidence section displays the source context of the license violation: * **License:** The specific license identifier detected in the package * **Branch:** The repository branch where the license issue was detected * **Evidence Link:** A direct link to the dependency manifest file in the VCS provider **War Room tab** The War Room tab displays the issue details in markdown format, including: * Package name and version * License identifier and license category * Detection rule identifier * Repository and file path context **Actions tab** The Actions tab provides remediation guidance for the license miscompliance issue. * **Remediation guidance:** License issues display the guidance: **Contact the legal team for further investigation** Remediation requires legal team consultation to evaluate license compatibility, negotiate licensing terms, or identify alternative packages with compliant licenses. ## Prioritize license miscompliance issues Effective prioritization of license miscompliance issues requires evaluating the license category, severity, and dependency type. License issues are legal compliance risks; prioritize based on the legal obligations and restrictions imposed by the detected license. ### Prioritize by severity Severity reflects the legal risk of the license violation based on the license category. Use severity as the baseline filter: | Severity | License risk | Recommended action | | ---------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | | **High** | Strong copyleft licenses (GPL, AGPL) or non-permissive licenses that impose derivative work obligations, source code disclosure requirements, or commercial use restrictions | Immediate legal review. Evaluate whether the package must be replaced with a permissively licensed alternative | | **Medium** | Weak copyleft licenses (LGPL, MPL, EPL) or non-OSI-approved licenses that impose conditional obligations such as linking exceptions or file-level copyleft | Schedule legal review. Evaluate license compatibility with the project distribution model | | **Low** | Unknown or unrecognized licenses where the licensing terms cannot be determined from the package metadata | Verify the license. Update the package metadata or contact the package maintainer to clarify licensing terms | ### Prioritize by license category Prioritize license miscompliance issues using the following license category hierarchy: | Priority | License category | Legal risk | | ----------- | ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Highest** | Strong copyleft | Strong copyleft licenses (GPL-2.0, GPL-3.0, AGPL-3.0) require that derivative works be distributed under the same license terms. Using a strong copyleft package may obligate your organization to disclose proprietary source code | | **High** | Non-permissive | Non-permissive licenses (BUSL-1.1, CC-BY-NC variants, Hippocratic-2.1) restrict commercial use, impose additional conditions, or prohibit specific use cases. Using a non-permissive package may violate commercial distribution terms | | **Medium** | Weak copyleft | Weak copyleft licenses (LGPL-2.0, LGPL-3.0, MPL-2.0, EPL-1.0, EPL-2.0, CDDL-1.0) impose copyleft obligations at the file or library level. Linking exceptions may apply depending on the integration method | | **Review** | OSI non-approved | Licenses that are not approved by the Open Source Initiative may not meet organizational open-source policy requirements. Review for compliance with internal standards | | **Verify** | Unknown / Unrecognized | Licenses that cannot be identified or are not recognized by the SPDX standard. Verify the license by inspecting the package source or contacting the package maintainer | ## Take action on license miscompliance issues The Licenses page supports the following actions for individual issues and bulk selections. #### Change resolution status Update the resolution status to track remediation progress. 1. Select one or more issues in the Licenses table. 2. Right-click to open the context menu. 3. Select the target resolution status: * **New** — The issue has not been triaged. * **In Progress** — Legal review or package replacement is underway. * **Resolved** — The non-compliant package has been replaced, the license has been approved by the legal team, or the issue has been accepted with documented justification. 4. Enter a **Resolution Comment** (optional) to document the action taken. #### Assign an issue Assign a license miscompliance issue to a specific user for triage and legal escalation. 1. Select the issue row in the Licenses table. 2. Open the issue side panel. 3. Select the **Assignee** field. 4. Search for and select the target user. #### Escalate to the legal team License miscompliance issues require legal team consultation as the primary remediation path. The legal team evaluates license compatibility with the project distribution model and organizational open-source policies. 1. Select the issue row to open the side panel. 2. Review the **License**, **License Category**, and **Impact** details. 3. Document the license context in the **Resolution Comment** field. 4. Assign the issue to the designated legal liaison or AppSec Manager responsible for license compliance. {% hint style="info" %} ### Important Automated fix pull requests are not available for license miscompliance issues. Remediation requires human judgment to evaluate license compatibility, negotiate licensing terms, identify alternative packages, or accept the license with documented justification. {% endhint %} #### Escalate to a Case For license miscompliance issues that require cross-team coordination or extended remediation timelines, escalate the issue to a Case. The Case captures the issue context, assigned owner, and SLA tracking in the centralized Cases workflow. 1. Select the issue row in the Licenses table. 2. Right-click to open the context menu. 3. Select the option to create or link to a Case. ## Understand SLA compliance Each license miscompliance issue is tracked against an SLA target based on the issue severity. The SLA status is displayed in the issue side panel under General Details. The SLA calculation uses the issue creation timestamp and the configured severity-to-target-days mapping. Resolved issues stop the SLA clock at the resolution timestamp. | SLA Status | Description | | --------------- | ------------------------------------------------------------- | | **On Track** | The issue is within the severity-based remediation window | | **Approaching** | The issue is nearing the SLA deadline. Prioritize remediation | | **Overdue** | The issue has exceeded the SLA deadline. Escalate or reassign | ## License miscompliance findings License miscompliance findings are potential licensing vulnerabilities in your open-source software packages. These findings allow you to assess and analyze your package license compliance. Promoting these findings to issues allows you to address license non-compliance. This ensures compliance with licensing requirements and maintain the integrity of your software supply chain. The **Licenses** **Findings** table is a filtered instance of the broader **Findings** table found under **Cases & Issues**, meaning it exclusively displays findings categorized as license miscompliance findings. However, the Licenses Findings table only displays findings detected during periodic scans. In contrast, the comprehensive **Findings** table includes all license miscompliance findings regardless of their detection source, such as periodic, pull request (PR), and continuous integration (CI) scans. **How to access license miscompliance findings** To access license miscompliance findings, under **Modules**, select **Application Security** → **Issues** → **Licenses** → **click the Findings tab**.
License miscompliance findings inventory The license findings inventory includes the following properties.
**Expanded Findings details** Clicking on a finding in the inventory table opens the **Findings** side card, which provides additional details about the finding.
Read more... * **Finding summary**: Found at the top of the card. Includes the finding name, ID and type (**Code** for license miscompliance findings) * **Description**: A description of the finding including its location * **Timestamp**: When the finding was last updated * **Asset details**: Includes **Asset** (The impacted asset. Clicking on the asset opens the asset side card without needing to navigate away to the asset section) and **Asset Type** (The specific asset type in which the license miscompliance was identified) * **Evidence**: Provides evidence and contextual details within your SDLC containing the IaC misconfiguration finding: * **Finding source** * **Data Source:** The system or integration from which the finding data was originally pulled (such as GitHub or a CI/CD pipeline). Click the icon next to the data source to navigate to the data source itself * **Collaborator**: The individual or team responsible for contributing to the code or configuration where the finding was identified * **License information** * **License**. The license (MPL-2.0) including the miscompliance * **License Category**. The category assigned to the license. Refer to [Open-source software license categories](#UUID-411277a1-e5cb-2720-d4fe-bbbfe0a13d22) for more information about license categories * **OSI Approved**. Whether the license is OSI approved or not * **Code context** * **Repository:** The name of the version control repository where the finding was located * **Package Manager**: The tool (such as PIP) that manages the dependency in which the license miscompliance was detected * **Branch:** The specific branch within the repository containing the finding * **File Path:** The exact location of the finding within the repository file structure * **First Hash:** The commit hash of the first commit where this specific finding was introduced or detected * **Scan metadata** * **Run ID:** The unique identifier of the specific scan execution during which this finding was detected
## Open-source software license categories Open-source software licenses define the terms under which open-source software can be used, modified, and distributed. In Cortex Cloud Application Security, licenses are scanned as part of the SCA vulnerability scan for open-source packages. All Critical, High and Medium license miscompliance detected in open-source software packages within an organization's environment are defined as issues. This enables structured vulnerability management and focused remediation. Where applicable, manual and automated fixes are provided. Cortex Cloud Application Security offers three types of default license categories out of the box, providing comprehensive coverage for managing license compliance within your environment: * Non-Permissive Licenses (High severity) * Strong Copyleft Licenses (High severity) * Weak Copyleft Licenses (Medium severity) Within each license type, SPDX identifiers are organized and sorted based on their characteristics and attributes. SPDX Identifiers are unique codes assigned to software licenses by the Software Package Data Exchange (SPDX) project. These identifiers are used to categorize and accurately identify software packages distributed under various types of licenses, including strong copyleft, weak copyleft, and non-permissive licenses. By associating each software package with a specific SPDX Identifier, it becomes easier to track and manage license compliance across different licensing policies, ensuring that the correct license type is identified and adhered to. ### Non-permissive licenses Non Permissive licenses policies identify software packages distributed under non-permissive or restrictive licenses. These licenses restrict how you can use, modify, and distribute the software. They may limit your ability to integrate the software into certain projects or require you to purchase a commercial license for specific uses. ### Non-permissive SPDX identifiers The following list displays supported SPDX identifiers for non-permissive licenses.
Read more... * BUSL-1.1 * C-UDA-1.0 * CC-BY-NC-3.0-DE * CC-BY-NC-ND-3.0-DE * CC-BY-NC-ND-3.0-IGO * CC-BY-NC-SA-2.0-DE * CC-BY-NC-SA-2.0-FR * CC-BY-NC-SA-2.0-UK * CC-BY-NC-SA-3.0-DE * CC-BY-NC-SA-3.0-IGO * CC-BY-ND-3.0-DE * Hippocratic-2.1 * JPL-image * MS-LPL * NCGL-UK-2.0 * PolyForm-Noncommercial-1.0.0
### Strong copyleft licenses Strong Copyleft licenses policies identify software packages distributed under strong copyleft licenses, such as the GNU General Public License (GPL). These licenses require derivative works to be distributed under the same copyleft license terms as the original work. This ensures broader access and modification rights. **Strong copyleft SDPX identifiers** The following list displays supported SPDX identifiers for strong copyleft licenses.
Read more... * AGPL-1.0 * AGPL-1.0-only * AGPL-1.0-or-later * AGPL-2.0 * AGPL-3.0 * AGPL-3.0-only * AGPL-3.0-or-later * Arphic-1999 * CERN-OHL-S-2.0 * copyleft-next-0.3.0 * copyleft-next-0.3.1 * GPL-2.0 * GPL-3.0 * Linux-man-pages-copyleft * OpenPBS-2.3
### Weak copyleft licenses Weak Copyleft Licenses policies identify software packages distributed under weak copyleft licenses. These licenses permit combining code with other licenses, including proprietary licenses, without mandating the entire derivative work to be released under the same copyleft license. ### Weak copyleft SPDX identifiers The following list displays supported SPDX identifiers for weak copyleft licenses.
Read more... * Artistic-1.0 * Artistic-2.0 * APSL * CAL-1.0-Combined-Work-Exception * CC-BY-SA-2.0-UK * CC-BY-SA-2.1-JP * CC-BY-SA-3.0-AT * CC-BY-SA-3.0-DE * CC-BY-SA-4.0 * CDDL-1.0 * CDLA-Sharing-1.0 * CERN-OHL-W-2.0 * CPOL-1.02 * EPL-1.0 * EPL-2.0 * eCos-2.0 * EUPL-3.0 * FDK-AAC * LGPL-2.0 * LGPL-2.1 * LGPL-3.0 * MPL-1.1 * MPL-2.0 * MS-RL * OSL-3.0 * QPL-1.0-INRIA-2004 * Sendmail-8.23 * SimPL-2.0 * TAPR-OHL-1.0 * TPL-1.0
## Manage license miscompliance issues Right-click on a row in the inventory table to access the following actions * **Change Status**. Modify the status of the issue. Values: New, In Progress, Resolved * **Change Severity**: Modify the severity level of the issue. Values: Critical, High, Medium, Low * **Change Assignee**: Change the user or identity assigned to address the issue * **Copy text to clipboard**: Duplicate selected text for easy pasting elsewhere * **Copy entire row**: Duplicate the entire row of data for easy pasting elsewhere * **Copy issue URL**: Duplicate the URL associated with the issue, to share or reference the issue * S**how/hide rows with the \[severity level]**: Show/hide rows matching the \[severity level] of the selected row --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://cortex-docs.paloaltonetworks.com/application-security/software-supply-chain-security/risk-and-remediation/software-composition-analysis-sca-scanners/license-miscompliance-issues.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.