> 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/code-security/code-security-scanners/software-composition-analysis-sca-scanners/license-miscompliance-issues/navigate-to-license-miscompliance-issues.md). # Investigate, prioritize, and remediate license miscompliance issues To effectively managelicense miscompliance, follow this lifecycle, moving from an open backlog to a resolved and prevented issue. **Important:** License miscompliance issues do not receive Urgency classification. Urgency metrics are calculated only for vulnerability, code weakness, IaC misconfiguration, and secret issues, and a license obligation measures neither exploitability nor deployment exposure. This guide replaces the Urgency-driven prioritization and reachability model with an obligation-driven model. Every other structural element of the lifecycle is unchanged. ```mermaid flowchart LR A[Assess: read the shape of the backlog] --> B[Prioritize: order by obligation weight] B --> C[Investigate: establish the obligation and whether it is triggered] C --> D[Resolve: accept, replace, or license the dependency] D --> E[Prevent: block the license class at the pull request] ``` | Stage | Decision | Primary surface | Guide that owns the detail | | --------------- | ------------------------------------------------------------------------------------ | ------------------------------------------------------- | ---------------------------------------- | | **Assess** | How much legal review capacity to commit, and to what | Severity widget and SLA widget above the Licenses table | This guide | | **Prioritize** | Which license class to review next | Insights widget above the Licenses table | Understand the Licenses table | | **Investigate** | What the license requires, and whether distribution triggers the requirement | Issue side panel | This guide | | **Remediate** | Whether to accept the obligation, replace the dependency, or license it commercially | **Resolution** tab in the issue side panel | License miscompliance issues: user guide | | **Prevent** | Which enforcement point blocks the license class | Unified Application Security Policies | Unified Application Security Policies | > **Important:** License review is category work, not instance work. A ruling on `GPL-3.0` applies to every dependency carrying that license, now and in future. Structure every stage to produce reusable license rulings rather than per-package decisions, or the same review recurs on the next dependency. ### Assess Before selecting an issue, read the shape of the backlog. Two widgets above the Licenses table answer that question, and neither is a work queue — each describes a distribution, so that you commit review capacity against a measured posture rather than against the first issue you happen to open. **The severity widget — how obligation weight is distributed.** Because license issues carry no Urgency classification, severity is the primary distribution the widget charts, and severity is derived from the license category. Read the proportions rather than the absolute counts. | Shape | What the shape means | What to do | | ------------------------------------------------- | ----------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | A visible Critical and High segment | Strong copyleft or non-permissive licenses are attached to consumed dependencies | Commit legal review capacity here first. These licenses carry derivative work disclosure or commercial use restrictions | | A concentration in the Unknown license population | Licenses the scanner could not classify against a recognized identifier | Review before assuming low risk. An unclassified license is unquantified legal risk, not absent risk | | A large Medium and Low population | Weak copyleft and permissive licenses that impose attribution or notice obligations | Confirm that a standing organizational ruling covers these categories, then process in bulk | **The SLA widget — how much of the backlog is already late.** The SLA widget charts open issues by SLA status. An overdue population is a commitment already broken. Because license obligations attach on distribution rather than on exploitation, an overdue license issue on a dependency that already shipped is materially different from an overdue issue on a dependency still in development. > **Note:** Insights on the Licenses table are defined on Severity rather than Urgency, which follows from the absence of an Urgency classification for this finding type. ### Prioritize **Prioritize by license category, not by package.** This replaces the Urgency-first rule that governs security issue types. Urgency does not apply, and severity alone is a proxy for the category that produced it, so order the backlog by the obligation the license imposes. | Order | License population | Why the population ranks here | | ----- | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | Strong copyleft found in code | Imposes derivative work disclosure obligations. The highest-cost obligation to discover after distribution, because compliance may require publishing source that was never intended to be public | | 2 | Unknown or unrecognized licenses | Unquantified obligation. Cannot be cleared without legal review, and cannot be assumed permissive | | 3 | Non-permissive found in code | Restricts commercial use or imposes fees. Cost is quantifiable but may require a negotiated license | | 4 | Weak copyleft found in code | Imposes obligations bounded to the modified library rather than to the whole work. Usually satisfiable by a notice or by keeping the library unmodified | **Use the Insights widget.** Each insight card pairs a severity level with a second compliance dimension and states how many issues satisfy both conditions. Selecting a card applies both filters to the Licenses table. **Scope to distributed software before reviewing.** An obligation attaches when software is distributed. Filtering to the release branch separates the dependencies that trigger obligations from those confined to internal tooling, which frequently reduces the review population substantially before any legal time is spent. **Sort by package to consolidate.** One dependency consumed across many repositories produces many issues that one replacement resolves. > **Note:** For the column and filter model of the table itself, see Understand the Licenses table. ### Investigate A severity level tells you the license category. It does not tell you what the license requires in your specific distribution model, or what replacing the dependency would cost. Investigation answers three questions, and each answer changes the action you take. #### What does this license require? This question replaces the reachability question that governs a security issue investigation. A license imposes obligations by its terms, not by whether an attacker can reach the code. The issue side panel supplies the obligation evidence: the SPDX license identifier, the license category, whether the license is OSI approved, and the detection rule that matched, from `BC_LIC_1` through `BC_LIC_5`. | Evidence | Consequence | | ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | Strong copyleft, SPDX-recognized | Distribution may require releasing the source of the combined work under the same license. Escalate to legal review before shipping | | Non-permissive, SPDX-recognized | Commercial use may be restricted or may require a fee. Determine whether your use case falls inside the restriction | | Weak copyleft, SPDX-recognized | Obligations are bounded to the library itself. Usually satisfiable by dynamic linking and a notice, without affecting your own source | | Not OSI approved, or the license is Unknown | The obligation cannot be determined from the identifier. Legal review is required before the dependency can be cleared | #### Is the obligation triggered? Blast radius for a license issue is a question of distribution, not of exposure. Most license obligations attach on distribution — conveying the software to a third party — rather than on use. Establish how the dependency reaches users. A package that ships inside a distributed binary, a container image, or a client-side bundle triggers distribution obligations. A package used only by an internal build tool, or executed only on servers you operate, may not, depending on the license and the jurisdiction. The **Dependency Path** and **Root Package** identify how the dependency entered the build, and the branch identifies whether the dependency reaches a release artifact. > **Note:** Whether the package ships in a distributed artifact is the license equivalent of reachability. A dependency that never reaches a distributed artifact carries the same license but frequently does not trigger the same obligation. #### What does resolution cost? The **code evidence** names the repository, the branch, the manifest file, and the commit that introduced the dependency, along with the commit author. Two attributes determine cost. **Dependency Type** determines who can act: a direct dependency can be replaced by the owning team, while a transitive dependency requires upgrading or overriding the root package that introduced it — and the owning team may have no reason to care about your license constraint. **Package Manager** determines whether an override mechanism is available at all. Establish both during the investigation, because a strong copyleft license on a deeply transitive dependency is a substantially larger undertaking than the same license on a direct one. > **Important:** Assign license issues to the legal or compliance reviewer rather than to the developer who added the dependency. Whether to accept an obligation is a legal determination; the code change follows from that determination and not before it. ### Remediate Open the **Resolution** tab in the issue side panel. The **Resolution** tab presents the resolution paths available for the issue. | Path | Use when | | ---------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Accept the obligation** | Legal review determines the obligation is satisfiable in your distribution model. Satisfy the terms — attribution, notice, or source availability — and record the ruling in the resolution comment | | **Replace the dependency** | The obligation is not acceptable and a permissively licensed equivalent exists. The standard path for a strong copyleft license in distributed software | | **Obtain a commercial license** | The dependency is not replaceable and the license offers a commercial alternative to the restrictive terms. Requires procurement, not engineering | | **Restrict the distribution path** | The obligation triggers only on distribution and the dependency can be confined to internal tooling. Removes the trigger without removing the dependency | Sequence by license category rather than by package. Reviewing all `GPL-3.0` dependencies in one pass produces a single ruling that resolves every issue in the category, while reviewing package by package produces the same legal question repeatedly. Escalate to a Case when the resolution requires procurement or a coordinated replacement across multiple teams. > **Note:** For triaging license issues and remediating non-compliant dependencies, see License miscompliance issues: user guide. For the package the license is attached to, see Software packages as an asset. *** ### Prevent A cleared dependency that the next commit reintroduces returns the same license question to legal review. Close the loop with a Unified Application Security Policy that blocks the license class at the earliest enforcement point. Select the trigger in shift-left order: a **PR Scan** trigger blocks the non-compliant dependency before the code merges, and a **CI Scan** trigger blocks the affected artifact before distribution. **Encode the legal ruling as policy.** This is the highest-value action in the license lifecycle. A legal ruling that a license category is unacceptable is durable organizational policy, and encoding the ruling into an Application Security Policy converts a recurring review into an automatic block. The alternative is re-litigating the same license every time a developer adds a dependency carrying it. **Scope prevention to distributed code.** A blanket block on strong copyleft across all branches generates friction on internal tooling where the obligation does not trigger. Scope the policy to production-bound branches so that enforcement matches where obligations actually attach. > **Note:** For policy triggers, actions, conditions, and grace period configuration, see Unified Application Security Policies. ### When the backlog itself is unreliable Two conditions distort the license backlog. **A third-party scanner without license coverage.** A third-party SCA scanner typically provides vulnerability detection and may or may not provide license compliance. If the tenant relies on a third-party scanner for SCA, an empty Licenses table may reflect absent license coverage rather than a compliant dependency set. Verify license coverage before relying on a third-party scanner for license posture. **Unrecognized licenses reading as low risk.** A license the scanner cannot classify against a recognized identifier may surface at a low severity, because severity derives from the license category and no category was determined. An unclassified license is unquantified risk. Filter for the Unknown population explicitly rather than allowing severity ordering to bury it. > **Note:** For third-party scanners, see Third-party ingestion. For verifying that the license capability of the SCA scanner completed successfully, see Application Security coverage. --- # 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/code-security/code-security-scanners/software-composition-analysis-sca-scanners/license-miscompliance-issues/navigate-to-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.