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.
Visible columns (default)
This tables describes exposed table attributes. Select Menu settings to view additional attributes.
Column | Description |
|---|---|
Severity | The severity level assigned to the license issue: Critical, High, Medium, Low, Informational, or Unknown. Severity is determined by the license category and detection rule, and may be overridden by a matched unified policy |
Name | The descriptive name of the license issue (such as |
License | The specific license identifier detected in the package (such as |
License Category | The license classification: Strong copyleft, Weak copyleft, Non-permissive |
Asset Name | The name of the repository, project, or codebase asset where the license miscompliance or security issue was detected |
Package Manager | The package ecosystem where the dependency was detected (NPM, Maven, Go Modules, PyPI, NuGet, RubyGems) |
Dependency Type | Whether the package is a Direct dependency or a Transitive dependency. |
Repository | The repository containing the package with the non-compliant license |
Branch | The repository branch where the license issue was detected (such as |
Domain Provider | The cloud provider domain associated with the issue |
Data Source | The VCS provider where the repository is hosted (GitHub, GitLab, Bitbucket, Azure DevOps, and variants) |
Created | The timestamp when the issue was first detected |
Assignee | The user assigned to the issue |
File Path | The path to the dependency manifest file containing the non-compliant package, including the affected line range |
AppSec Policy ID | The unique identifier of the Application Security policy that evaluated the raw scanner finding and triggered the creation of the issue |
SLA | The Service Level Agreement compliance status for the issue. This is calculated based on the issue's creation date and the target resolution window assigned to its specific severity level. Values: Approaching, On Track, Overdue |
Status | The current triage and remediation state of the issue, categorized as New, In Progress, or Resolved |
Business Application Names | The names of the defined business applications, logical groupings, or projects that the affected asset or repository hosting the license belongs to, providing organizational context for the issue |
Backlog Status | The classification of the issue within your remediation backlog. Values: Backlog, New |
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)
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.
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 |