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.

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 for the category definitions and SPDX identifier lists.