Implement open-source license compliance scanning
Implementation Effort: Medium – Configuring license scanning in pull requests and publishing an approved-license policy spans engineering and legal review. User Impact: Low – Enabling license checks and enforcing branch policies is an administrator and pipeline action; end users are not affected. Lifecycle Stage: Code
Overview
Implement automated open-source license compliance scanning in pull request workflows and enforce an organization-approved license policy for approved, restricted, and blocked licenses.
Modern applications depend on hundreds or thousands of open-source packages, each carrying license obligations that become the organization's legal responsibility when the software is distributed or deployed as a service. A single copyleft dependency buried deep in a transitive dependency tree can trigger disclosure requirements for proprietary source code, and packages with non-standard or unknown licenses introduce legal uncertainty that may not surface until a compliance audit or customer review.
In GitHub, configure dependency review checks in pull requests and use allow or deny license lists where the dependency review action supports license policy enforcement. For private or internal repositories, that capability requires the appropriate GitHub Code Security or GitHub Advanced Security entitlement. Azure DevOps does not currently provide a first-party license scanning control. GitHub Advanced Security for Azure DevOps provides dependency vulnerability scanning but intentionally does not include license compliance scanning. For license governance in Azure DevOps, integrate a third-party software composition analysis or license scanning tool in pull request validation pipelines and enforce results through branch policies before merge. Publish an organizational license policy that classifies licenses as approved, restricted, or blocked, and define a workflow for legal review when a restricted license has a valid business justification.
Maintain a software bill of materials that includes license metadata when customers, regulators, or internal legal policy require it. This supports SBOM and procurement expectations where license data is requested, but it should not be framed as a universal minimum element required by every CISA SBOM scenario. Validating every dependency against an approved license policy before it enters the codebase supports Verify explicitly, since each package must satisfy defined policy rather than being trusted by default.