They should keep the raw declared and discovered licence evidence, but govern reporting and issue handling with an explicit policy that identifies the dominant licence for each component. That preserves auditability while reducing unnecessary manual review. The key is to separate evidence collection from the compliance decision, then document when overrides are allowed.
Why licence conflicts in SBOMs need a policy decision, not ad hoc debate
Licence conflicts are common when an SBOM aggregates declarations from upstream projects, package metadata, scanners, and transitive dependencies that do not all agree. Compliance teams should not “fix” that by deleting evidence or forcing every reviewer to interpret the conflict independently. The practical goal is to preserve the full evidence trail, then make one governed decision about which licence outcome governs reporting and remediation.
The dominant-licence approach works because it separates evidence from judgement. Declared and discovered licences remain available for audit, dispute resolution, and later re-review, while the workflow assigns one controlling outcome for the component so the queue does not stall on repeated manual analysis. That is especially important where the same artefact shows a permissive declaration in one source and a more restrictive notice in another.
Conflicts also arise because SBOM tooling is optimised for discovery, not legal finality. A scanner may surface multiple SPDX expressions, a package may embed dual licensing, or a downstream distribution may inherit notices that differ from the source project. Treating every mismatch as an unresolved exception creates noise; treating every mismatch as automatically resolved creates legal risk. The policy needs a documented rule for when the dominant licence is the declared one, when the discovered licence prevails, and when legal review is mandatory.
How to structure the workflow so auditability is preserved
The safest workflow keeps two layers separate: evidence capture and compliance disposition. Capture every licence signal exactly as found, including the source, timestamp, scanner output, and package version, then normalise the component record so the decision engine can point to one governing licence for reporting. That record should explain why the chosen licence was treated as dominant, especially when the choice is based on distribution terms, bundled notices, or a legal exception.
When the evidence is contradictory, the workflow should route the component by decision rule rather than by personal interpretation. A simple rule set may use declared licence first, discovered licence second, and override by counsel or policy owner only when a defined exception applies. The important control is that overrides are explicit, attributable, and reviewable, not informal corrections made inside a ticket comment or spreadsheet.
This separation is also what makes the process scalable across thousands of components. Reviewers can triage against one policy instead of re-litigating the same conflict on every release. For broader supply-chain governance, teams often pair this approach with OpenSSF guidance and a component inventory that records both raw signals and the final compliance decision.
What compliance teams should document when licences disagree
Document the licence evidence, the dominance rule, the exception criteria, and the ownership of the final decision. If the workflow allows one licence to override another, the rationale should be explicit enough for a future auditor or legal reviewer to reconstruct the decision without guessing. The record should also show whether the component was accepted, remediated, substituted, or escalated for legal review.
For teams managing software and AI supply chains together, this is similar in spirit to maintaining an AI Supply Chain Security and AI-BOM Guide, where raw provenance is kept distinct from the governance decision. The same pattern applies here: evidence collection tells you what was observed, while policy tells you what the organisation will count as authoritative for compliance purposes.
Where the licence conflict affects a distributable product, the decision record should also note any downstream obligations, such as attribution, notice preservation, source disclosure, or distribution restrictions. That keeps remediation anchored to the actual obligation rather than to the scanner output alone.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply chain provenance and integrity | SBOM licence conflicts sit in software supply-chain governance and provenance handling. |
| Recommendation — Preserve component provenance and track licence evidence through the build and release chain. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | SBOM workflows support software inventory, review, and remediation discipline for shipped components. |
| Recommendation — Maintain component inventories and route conflicting licence findings into governed review. | ||
| ISO/IEC 27001:2022 | A.5.31 — Legal, statutory, regulatory and contractual requirements | Licence conflicts affect contractual and legal obligations tied to software distribution. |
| Recommendation — Document the legal basis for licence decisions and keep reviewable exception records. | ||
Practitioner Guidance
What to prioritise: Establish one explicit dominance rule for licence conflicts and apply it consistently across tools, teams, and release trains. In practice, the biggest failure mode is not the conflict itself, but inconsistent handling that makes audit evidence unreliable.
What to verify: Confirm that the raw declared and discovered licence data remain intact, and that every override has a named approver, a reason code, and a versioned policy reference. If those fields are missing, the workflow is not yet compliance-grade.
Decision rule: If a conflict can be resolved by policy without legal judgement, classify it once and move on. If the outcome changes distribution rights, attribution duties, or notice obligations, escalate before release rather than after the component is embedded in a product.
Practitioner takeaway: Good SBOM licence handling is not about choosing the “right” string in every scan result, it is about making one defensible compliance decision while preserving enough evidence to prove why that decision was made.