Most startup engineering teams have Dependabot enabled. They get alerts about vulnerable packages, they update dependencies, they consider themselves covered. From a security standpoint, that is a reasonable baseline. From an IP standpoint, it covers almost nothing.
Security scanning and github dependency IP risk scanning operate on completely different data. A package can have zero CVEs — no known security vulnerabilities — and still carry a GPL v3 license that contaminates your entire codebase. Dependabot will never alert you to this. GitHub's Advanced Security will not catch it either. The IP contamination layer is invisible to security tooling, and it requires a separate, dedicated review.
There is no tool in GitHub's native security suite that detects open source license risks, copyleft contamination, or IP compliance gaps. These are legal risks, not technical vulnerabilities — and they require a different kind of code audit.
What GitHub's Scanning Tools Actually Cover
GitHub provides several automated scanning features, primarily through Dependabot and GitHub Advanced Security. Understanding what each covers is the first step to understanding the IP risk gap:
Dependabot Security Alerts
Dependabot monitors your dependency manifests against the GitHub Advisory Database — a database of known security vulnerabilities (CVEs) in open source packages. When a dependency with a known vulnerability is detected, Dependabot creates an alert and, if configured, a pull request to update to a patched version.
What it checks: security vulnerabilities in known package versions. What it does not check: license information, copyleft status, or IP compliance obligations of any package.
Dependabot Version Updates
This feature automatically creates pull requests to keep dependencies up to date. Relevant to IP risk because license changes between versions are not flagged — a package that was MIT in version 1.x may have relicensed to AGPL in version 2.x, and Dependabot will happily suggest upgrading without any IP risk warning.
GitHub Advanced Security (CodeQL)
CodeQL is GitHub's semantic code analysis tool. It detects security vulnerabilities in code logic — SQL injection, buffer overflows, insecure authentication patterns. It is not a license scanner. It has no awareness of open source license obligations.
Secret Scanning
GitHub's secret scanning detects accidentally committed API keys, passwords, and credentials. This is relevant to IP risk in one specific way: accidentally exposing proprietary code in public repositories is an IP risk, and secret scanning addresses the credential exposure component. But it does not detect license contamination in dependencies.
The IP Risk Gap: What GitHub Cannot See
The IP risk layer that GitHub scanning misses entirely includes:
- License identity of each dependency: Whether a package is MIT, Apache 2.0, GPL v3, AGPL v3, or something else. This information is in the package metadata, not in the vulnerability database.
- Transitive license contamination: A direct MIT dependency pulling in a GPL transitive dependency. GitHub's dependency graph shows the tree structure but applies no license analysis to it.
- License version changes: When a dependency relicenses from a permissive to a copyleft license between versions (a practice that has become more common as companies seek to protect commercial value from cloud providers).
- License compatibility conflicts: Apache 2.0 and GPL v2 in the same compiled work is a compatibility conflict. No GitHub tool detects this.
- DMCA Section 512 compliance: If your product incorporates third-party content — not code libraries, but actual creative or documentary content — DMCA obligations apply. This requires a content audit, not a code audit.
- Creative Commons licensed content: Images, datasets, documentation, and training data licensed under Creative Commons Non-Commercial or ShareAlike licenses can create IP obligations distinct from code license obligations.
The practical consequence: A startup that runs Dependabot diligently and has zero security alerts may simultaneously have an AGPL component in their SaaS backend, an Apache 2.0 + GPL v2 mixing conflict, missing attribution for 300 MIT packages, and a Creative Commons NC-licensed dataset used in their ML model. None of this will ever produce a Dependabot alert. All of it will surface in IP due diligence.
Security Scanning vs IP Risk Scanning: A Direct Comparison
| Risk Category | Dependabot / CodeQL | IP Risk Scan |
|---|---|---|
| Known CVEs in dependencies | Yes — full coverage | Out of scope |
| License identity of packages | No | Yes — full transitive tree |
| GPL/AGPL contamination | No | Yes — with copyleft analysis |
| Apache 2.0 + GPL v2 conflict | No | Yes |
| License version changes (relicensing) | No | Yes |
| Attribution compliance | No | Yes |
| DMCA / Creative Commons content | No | Yes (content audit component) |
| Accidentally exposed secrets | Yes (partial) | Out of scope |
| IP assignment verification | No | Yes (contractor code review) |
| Investor-ready documentation | No | Yes — designed for due diligence |
The Four Layers of a Proper IP Risk Scan
An IP risk scan that complements GitHub's security tooling operates across four layers:
Layer 1: Dependency Tree License Map
Constructing the full transitive dependency graph — not just the direct dependencies in your manifest files — and classifying each package with its SPDX license identifier. For a typical Node.js or Python project, this can involve hundreds or thousands of packages. The SPDX license list provides standardized identifiers for all major open source licenses and is the reference used in professional IP audits.
Layer 2: Copyleft Contamination Analysis
Identifying all GPL v2, GPL v3, AGPL v3, LGPL, MPL, and similar copyleft-licensed packages in the dependency tree, and analyzing whether the copyleft conditions are triggered by the startup's use of those packages. This is a legal analysis, not just a technical scan — it requires understanding how the software is used (SaaS, distributed binary, library), not just what packages are present.
Layer 3: Source File and Repository History Review
Scanning source code files directly for embedded GPL headers, license statements, or copyright notices — which may indicate code copied from open source projects rather than included as a managed dependency. Also reviewing repository history for accidentally committed proprietary data or credentials.
Layer 4: Content and Dataset IP Review
For AI/ML products or content-heavy applications, reviewing the provenance of training datasets, images, documentation, and other non-code content for Creative Commons Non-Commercial, ShareAlike, or other license conditions that create IP obligations distinct from code licenses.
DMCA and Creative Commons: The Non-Code IP Layer
The Digital Millennium Copyright Act (DMCA) is a US law with global reach for companies operating in or serving US markets. Its Section 512 safe harbor provisions are relevant for platforms hosting user-generated content. But for startups building products, the more common DMCA risk is in the content layer: images, icons, fonts, audio, and documentation that were sourced from the internet without adequate license review.
Creative Commons licenses introduce their own complexity. The Creative Commons framework includes six main license combinations:
For AI/ML startups specifically, the provenance of training datasets is an emerging and high-stakes IP issue. Multiple jurisdictions are currently working through questions of whether training an ML model on copyrighted content constitutes infringement, and what license conditions apply to model outputs. An IP audit for an AI/ML product should specifically address dataset licensing as a separate category.
GitHub IP Scanning for LATAM Startups
For startups with engineering teams in Argentina or elsewhere in Latin America, github dependency IP risk scanning has specific relevance beyond the dependency tree:
One LATAM-specific issue: open source projects developed by engineers at LATAM startups that are then incorporated into the commercial product without proper IP assignment. If an engineer published an open source library under MIT or GPL before joining the company, and the company's product uses that library, the company may or may not own the IP in that library — depending on the terms of the employment agreement and whether a separate assignment was executed. An IP scan that includes repository history analysis can surface these situations.
Frequently Asked Questions
Does GitHub's Dependency Graph show license information?
GitHub's Dependency Graph shows which packages your project depends on, including transitive dependencies — but it does not provide license analysis, copyleft risk classification, or IP compliance assessment. The license metadata is available in individual package registries (npm, PyPI, Maven Central) and can be extracted via tools like SPDX-compliant scanners, but GitHub does not surface this information natively or flag license risks. A dedicated IP risk scan is required to analyze the license data.
Can a package have no CVEs but still be an IP risk?
Yes — frequently. Security vulnerabilities and license obligations are completely separate attributes of a package. A package can be perfectly secure (no CVEs, actively maintained, well-audited code) and simultaneously carry an AGPL v3 license that creates significant IP obligations for a commercial SaaS product. The two risk dimensions are orthogonal — you need separate tooling and separate reviews to assess each.
What is open source compliance in the context of GitHub scanning?
Open source compliance refers to meeting all legal obligations imposed by the open source licenses governing the packages in your codebase. For commercial software, this means: no copyleft license conditions are violated (no undisclosed GPL/AGPL contamination), attribution requirements are met for all MIT and Apache 2.0 packages, license compatibility conflicts are absent, and proprietary IP is properly segregated from open source. None of these are assessed by GitHub's security scanning tools — they require a dedicated code audit by legal and technical reviewers.
How does the LexMap GitHub IP Audit differ from running a license scanner myself?
License scanning tools (FOSSA, WhiteSource, Black Duck, etc.) generate license lists — they tell you what licenses are present. The LexMap GitHub IP Audit Standard ($299) adds the legal analysis layer: it classifies each finding by risk level (Red/Amber/Green), explains the legal implication of each copyleft or compatibility issue, provides a prioritized remediation plan, and delivers output formatted for investor due diligence data rooms. It is the difference between a list of ingredients and a nutritional assessment — the raw data versus the professional interpretation. Fixed price, 48-hour delivery.
Close the IP Risk Gap GitHub Scanning Leaves Open
The GitHub IP Audit Standard ($299) runs the dependency scan that Dependabot does not — covering license identity, copyleft contamination, Apache 2.0 / GPL v2 conflicts, and attribution compliance. Delivered in 48 hours. Fixed price. Investor-ready output. Get your report before due diligence does.
Related Reading
Open Source Compliance Audit for LATAM Startups GPL Contamination Risks in Startup Code Open Source Audit Before Series A: Complete GuideFor startups operating in Argentina or elsewhere in Latin America, integrating IP risk scanning into your GitHub workflow is increasingly a prerequisite for institutional investment. VCs conducting Series A due diligence now routinely request evidence of systematic IP compliance processes, not just a one-time audit. A fixed price GitHub IP Audit Standard report at $299 gives your team the documentation it needs, with 48-hour delivery that fits into even the most compressed fundraising timelines. Get your report and transform your IP compliance from a vulnerability into a competitive advantage across LATAM markets.