Open Source License Risk
Know what your dependencies oblige you to do
Catalog open-source dependencies across your repositories with license analysis, risk scoring, and CycloneDX SBOM export, keeping supply chain evidence audit-ready for SOC 2, ISO 27001, and customer security reviews.
Why license risk matters
A license is a contract you agreed to by installing a package.
It can reach your own source code
Reciprocal licenses such as GPL and AGPL can require you to publish the code you built around them. That obligation attaches to how you ship, not to whether you noticed the license.
It arrives through dependencies you never chose
Your direct dependencies get reviewed. Theirs do not. Most license exposure enters through transitive packages several levels down the tree.
It surfaces at the worst moment
License questions tend to appear during an acquisition, an enterprise security review, or a funding round, when the timeline is fixed and the answer is needed now.
Know what is in your software
A generated SBOM, license risk sorted from noise, and obligations in plain language.
Generate an SBOM for Every Repository
Connect GitHub, add the repository you want covered, and SecureSlate builds its software bill of materials, using SPDX through the GitHub dependency graph and CycloneDX through manifest parsing. The inventory spans every package manager in the repository, including npm, PyPI, RubyGems, and Packagist, and records the version, license, and package URL of each component. Export or regenerate it whenever the dependency tree changes.
See Which Licenses Actually Put You at Risk
Every component is sorted into permissive, restrictive, or unknown, and shown alongside the licenses your codebase actually depends on. Copyleft and restrictive licenses are flagged for legal review, and unknown licenses are surfaced rather than quietly counted as clean, because no stated license means no permission granted.
Obligations in Plain Language, With a Recommended Action
License texts are written for lawyers. SecureSlate explains what a license actually requires, such as that GPL obliges any distributed derivative work to ship under the same license, and pairs it with a recommended action, whether that is replacing the dependency with a permissively licensed alternative or obtaining a commercial license from the maintainer.
FAQs
License and SBOM questions answered.
Free to obtain is not the same as free of obligations. Reciprocal licenses such as GPL and AGPL can require you to release your own source code when you distribute or, in the AGPL case, network-serve software that includes them. Others require attribution notices or a statement of changes. The risk is rarely deliberate: it usually arrives through a transitive dependency nobody reviewed.
A software bill of materials is a machine-readable inventory of every component in your software, with versions and licenses. Enterprise customers increasingly request one during security review, and public sector and regulated buyers may require it. Having one ready shortens procurement rather than stalling it.
CycloneDX and SPDX, the two formats most requesters accept. SPDX is generated from the GitHub dependency graph and CycloneDX from parsing your manifests. You can regenerate and export at any time, so the SBOM reflects your current dependency tree rather than a snapshot that aged out months ago.
SBOM generation currently supports GitHub repositories. Within a repository, components are picked up across the package managers in use, including npm, PyPI, RubyGems, and Packagist, and the dashboard shows the split between them so you can see where your dependencies actually come from.
Permissive covers licenses such as MIT, BSD, and Apache-2.0 that let you use the component with few obligations beyond attribution. Restrictive covers copyleft licenses such as GPL that can reach your own code depending on how you ship. Unknown means the component declares no license we can resolve, which is a legal question to answer rather than a clean result.
It is flagged for legal review on the dashboard and on the affected repository. Opening the component shows the license, the version, its package URL and registry, an explanation of what the license requires, and a recommended action such as replacing it with a permissively licensed alternative or obtaining a commercial license.
No, and it should not be treated as one. SecureSlate identifies which licenses are present, what obligations they typically carry, and where they entered your stack, so your counsel can review a short list of real questions rather than an unsorted dependency dump. The determination remains a legal one.
Both frameworks expect you to know what is in your software and to manage supply chain risk. A current component inventory and license review give you that evidence on demand, so the SBOM does double duty for procurement and for audit.
Know what you are shipping
Connect your repositories and get a full component inventory with license risk flagged.
