Someone on your team merges a pull request that pulls in a transitive dependency under AGPL-3.0. Nobody notices, because the license lives four levels deep in the dependency tree, and the change ships in the next release of your SaaS product. Six months later, a customer's legal team asks for your open source attribution file. It doesn't exist. This scenario plays out constantly: a typical enterprise application now pulls in several hundred open source packages, and every one of them carries its own license terms, obligations, and risk profile. GitHub's dependency graph shows you what you're using. It does not tell you whether shipping it violates your license policy, your customer contracts, or your ability to keep your source code proprietary. GitHub Advanced Security (GHAS) was built to catch vulnerable and leaked-secret code, not license exposure. Here's what that gap actually looks like, and how to close it.
What Does "Open Source License Compliance" Actually Mean on GitHub?
It means knowing, for every dependency in your dependency graph, which license governs it and whether that license is compatible with how you distribute your software — and GitHub's default tooling only gets you partway there. GitHub's Dependency Graph does surface a license field for packages that publish one in their manifest (npm, PyPI, RubyGems, Maven, and a handful of other ecosystems), and the Dependency Review action lets you configure an allow-list or deny-list of SPDX license identifiers that blocks a pull request on a match. That's useful for catching a brand-new GPL-3.0 dependency added in a diff. It does nothing for the AGPL-3.0 package that was already merged eighteen months ago, the dependency with no declared license at all (common in abandoned or internal-tool-turned-public repos), or the dual-licensed package where the free tier requires a copyleft license unless you buy a commercial key. In practice, license compliance means continuous inventory (an SBOM), continuous classification (permissive vs. copyleft vs. proprietary vs. unknown), and continuous policy enforcement — not a one-time PR gate.
Does GitHub Advanced Security Check License Compliance?
Only at the edges, through a manually configured allow/deny list on new pull requests — it has no org-wide license policy engine, no obligation tracking, and no historical scanning of what's already merged. GHAS's core products are code scanning (CodeQL), secret scanning, and Dependabot alerts, all aimed squarely at vulnerabilities and credential leaks. The Dependency Review action is the only piece that touches licensing, and it works exclusively at diff-time on pull requests in repos with the graph enabled — it cannot retroactively flag the 40 GPL-family packages your organization has been shipping in production since 2021. It also has no concept of copyleft "obligations" (attribution files, source-disclosure requirements, license text bundling) and produces no artifact you can hand to legal or a customer's procurement team as proof of compliance. If your auditor asks "show me the license for every component in this build, and show me it hasn't changed since last quarter," GHAS has no report for that question.
Why Do Permissive Licenses Suddenly Turn Into Compliance Problems?
Because maintainers relicense their projects, and a dependency that was safe the day you added it can become legally hazardous without a single line of your own code changing. This isn't hypothetical. In January 2021, Elastic moved Elasticsearch and Kibana from the Apache 2.0 license to the dual SSPL/Elastic License, specifically to block AWS from offering a managed version — companies still pinned to older tags were fine, but anyone tracking "latest" inherited new restrictions overnight. In August 2023, HashiCorp switched Terraform, Vault, and Consul from the permissive MPL 2.0 to the Business Source License (BSL) 1.1, which restricts competitive commercial use for four years before converting to MPL. In March 2024, Redis Ltd. moved the Redis core from the three-clause BSD license to a dual SSPL/RSALv2 license, prompting the Linux Foundation to spin up the Valkey fork within weeks. None of these events show up as a CVE. None of them trigger a Dependabot alert. A dependency-graph snapshot taken on the day you onboarded the package tells you nothing about the license it ships under today, and GitHub does not re-check.
How Much Does License Non-Compliance Actually Cost?
It costs deals, audits, and in the worst cases, forced code disclosure — and the exposure is more common than most engineering teams assume. Synopsys's Open Source Security and Risk Analysis (OSSRA) report has repeatedly found that the large majority of commercial codebases it audits contain open source with unresolved license conflicts, and a meaningful share contain components with no license at all, which is arguably worse than a restrictive one because there's no legal basis to use the code commercially. The business impact shows up in three places: M&A due diligence, where undocumented copyleft dependencies have delayed or repriced acquisitions because the buyer's counsel won't sign off without a clean bill of materials; enterprise procurement, where SOC 2 and vendor security questionnaires increasingly ask for an SBOM with license metadata as a checkbox item; and litigation risk, where companies distributing GPL-licensed code inside proprietary binaries without complying with source-disclosure terms have faced real legal claims from organizations like the Software Freedom Conservancy. A missed license isn't an abstract governance gap — it's a line item that shows up in a term sheet or a lawyer's letter.
What Should a Real License Compliance Workflow Look Like?
It should generate a continuously updated SBOM, classify every license against a policy your legal and engineering teams both signed off on, and re-check that classification every time a dependency updates or a maintainer changes its terms — not just at merge time. Concretely, that means: an automated SBOM (CycloneDX or SPDX format) generated on every build, not just on request; a license policy that goes beyond "block GPL" to categorize permissive (MIT, Apache-2.0, BSD), weak copyleft (LGPL, MPL), strong copyleft (GPL-3.0, AGPL-3.0), and source-available/restrictive (SSPL, BSL, Elastic License) tiers with different approval rules for each; alerts when an existing, already-approved dependency changes its license on a new release (which is exactly what caught teams off guard with Elastic, HashiCorp, and Redis); and an audit trail that ties every dependency's license history to the specific build and release it shipped in, so you can answer "what license did we ship in v3.2.1" a year later without re-scanning anything. Very few teams have this today because it requires stitching together a dependency-review action, a separate SBOM generator, a spreadsheet of policy exceptions, and manual legal review — a workflow that decays the moment someone forgets a step.
How Safeguard Helps
Safeguard treats license compliance as a first-class, continuous signal in the software supply chain — not a one-time gate bolted onto a pull request. Every scan produces a complete SBOM across your full dependency tree, including transitive dependencies that never show up in a manifest file, with each component classified against a normalized license taxonomy (permissive, weak copyleft, strong copyleft, source-available/restrictive, and unknown/no-license). You define policy once — for example, "block AGPL-3.0 and SSPL in anything we distribute to customers, flag LGPL for review, auto-approve MIT/Apache/BSD" — and Safeguard enforces it across every repository in your organization, not just the ones where someone remembered to turn on a GitHub Action.
Because Safeguard monitors dependencies continuously rather than only at merge time, it catches the exact failure mode that hit teams during the Elastic, HashiCorp, and Redis relicensing events: an already-approved, already-shipped dependency changing its terms on a new release. You get an alert the moment a tracked component's license shifts, with a clear diff of what changed and which of your services are affected, instead of finding out from a customer's legal team. Every finding ties back to a build-level audit trail, so when a customer, auditor, or acquirer asks for proof of license compliance on a specific release, you can produce it in minutes rather than reconstructing it from git history. Combined with Safeguard's vulnerability and provenance checks, license compliance becomes one more automated, continuously enforced layer of software supply chain security — not a manual process that only gets attention right before a compliance deadline.