> 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/understand-license-micompliance-findings.md).

# Understand license micompliance findings

A license miscompliance finding is the raw output of the Cortex Cloud license scanner: one record stating that one open-source package carries one license that matched one detection rule. Findings exist before policy evaluation, which makes the **Findings** tab of the **Licenses** page the only surface that answers three questions the issues table cannot — whether the license scanner is running everywhere it should, which detections a policy suppressed or never matched, and why the finding count is higher than the issue count.

### What a finding is, and why the count differs from the issue count

A finding is a detection. An issue is a decision. The license scanner emits a finding for every package-and-license pair that matches a detection rule, with no reference to policy. Cortex Cloud then evaluates each finding against the active Unified Application Security Policies, and only findings that match a policy carrying a **Create Issue** action become issues.

Two consequences follow, and both explain why the **Findings** tab is not a duplicate of the **Issues** tab:

**A finding count higher than the issue count is normal, not a defect.** Findings that match no policy remain visible on the **Findings** tab permanently and never appear on the **Issues** tab.

**One package can produce several findings.** The scanner fans out in two independent dimensions, so the finding count is not a package count:

| Fan-out dimension | Behavior                                                                                            | Source                                   |
| ----------------- | --------------------------------------------------------------------------------------------------- | ---------------------------------------- |
| **License**       | A package declaring several licenses is evaluated once per license                                  | `licensesService.ts:54`                  |
| **Rule**          | A single license matching more than one detection rule produces one finding per matched rule        | `licensesService.ts:56`                  |
| **Root package**  | A transitive dependency reached through several root packages produces one finding per root package | `licenseFindingsReportGeneratorV2.ts:33` |

> **Note:** The rule fan-out is a filter, not a first match. `getViolatedDetectionRules()` returns every detection rule whose license list contains the detected license, and the scanner emits a finding for each. A license appearing in two rule definitions therefore produces two findings for the same package.

```mermaid
flowchart LR
    A[Package asset with declared licenses] --> B[Match each license against the five detection rules]
    B --> C[Emit one finding per license and rule match]
    C --> D[Findings tab shows every finding]
    C --> E[Policy evaluation]
    E --> F[Issues tab shows only findings that matched a Create Issue policy]
```

### The five license detection rules

The license scanner ships five detection rules. The five rules split into two families that behave differently, and the distinction determines how you interpret a finding.

**Category rules match a license against an explicit list.** Rules BC\_LIC\_3, BC\_LIC\_4, and BC\_LIC\_5 each carry a fixed list of SPDX identifiers. A finding from a category rule states that the license is a named member of that category.

**Attribute rules test a property of the license.** Rules BC\_LIC\_1 and BC\_LIC\_2 test whether the license is OSI-approved and whether the license is SPDX-recognized. A finding from an attribute rule states that something is absent — recognition or approval — rather than that the license belongs to a known category.

| Rule           | Finding type name                     | Severity | What the rule detects                                                                                                                                              |
| -------------- | ------------------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **BC\_LIC\_1** | Not assigned                          | Medium   | The package license is not OSI-approved. Membership is tested against the approved-OSI set loaded at `licensesService.ts:23`                                       |
| **BC\_LIC\_2** | Not assigned                          | Low      | The package license is unknown or not SPDX-recognized                                                                                                              |
| **BC\_LIC\_3** | Weak copyleft license found in code   | Medium   | The license permits combining code with other licenses, including proprietary licenses, without requiring the entire derivative work to adopt the copyleft license |
| **BC\_LIC\_4** | Strong copyleft license found in code | High     | The license requires derivative works to be distributed under the same copyleft terms as the original work                                                         |
| **BC\_LIC\_5** | Non permissive license found in code  | High     | The license imposes strict conditions on use, modification, and distribution                                                                                       |

Rule definitions, severities, and finding type names are read from `licenses.yaml`.

> **Note:** Every license finding carries the identical remediation string, `Please contact the legal team for further investigation.`, set as a constant at `licenseFindingsReportGenerator.ts:46`. The remediation field carries no per-license guidance, which is a deliberate consequence of license remediation requiring a legal determination rather than a code change.

For the complete SPDX identifier list belonging to each category rule, refer to Reference A: License categories and SPDX identifiers.

### Audit scanner coverage and policy gaps

Use the **Findings** tab when the question concerns the scanner or the policy set rather than an individual dependency. Four audit workflows justify opening the **Findings** tab instead of the **Issues** tab.

**Verify license scanner coverage.** A repository with SCA scanning enabled and zero license findings is a coverage signal, not a clean result. Filter findings by repository and confirm that each repository containing a supported dependency manifest returns findings.

**Identify policy gaps.** Compare the finding population against the issue population. A large detection population producing few issues indicates that active policies do not cover the license categories being detected. Resolve a policy gap by extending a Unified Application Security Policy to the **License Miscompliance** finding type, not by suppressing findings. For policy configuration, refer to Unified Application Security Policies.

**Review suppressed findings.** A finding suppressed by an inline comment remains on the **Findings** tab and carries both the suppression marker and the author-supplied justification. Suppression hides the finding from the issue backlog; suppression does not delete the detection record. Reviewing suppressed findings periodically is the only way to audit whether developer-applied suppressions remain justified.

**Validate detection rules.** Confirm that a known license in a known package produces a finding under the expected rule. A missing finding for a license that appears in a rule definition indicates a license-string normalization problem in the manifest parser rather than a rule problem.

> **Caution:** Do not treat the **Findings** tab as a work queue. A finding is not assignable, carries no SLA, and has no resolution status. Perform remediation on the **Issues** tab, where the policy-evaluated work items live. 

### License categories and SPDX identifiers

See [Open-source software license categories](/application-security/code-security/code-security-scanners/software-composition-analysis-sca-scanners/license-miscompliance-issues/open-source-software-license-categories.md) for the category definitions and SPDX identifier lists.


---

# 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/understand-license-micompliance-findings.md?ask=<question>&goal=<endgoal>
```

`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.