License Compliance Risk in SBOM-Disclosed Dependencies
Transitive dependencies hide license risks that SBOMs can expose.
License compliance used to be an internal engineering matter, but now it's a business condition with legal and financial teeth. Three forces are converging at once to push it there. On the federal procurement side, Executive Order 14028 and the rules that followed it once said software had to come with an SBOM and a signed attestation before it could qualify. OMB Memorandum M-26-05, issued in January 2026, rescinded that mandatory requirement, and agencies can now choose, contract by contract, whether to require SBOMs and attestations based on their own risk assessment. A vendor who cannot produce one can still lose a contract at an individual agency's discretion, so the floor dropped but the ceiling did not move.
The sharper driver is mergers and acquisitions. Acquirers now routinely commission license audits as part of due diligence, and finding undisclosed strong-copyleft code buried in a target's codebase changes the deal. This is especially damaging in SaaS products where copyleft obligations were never honored in the first place, since the business model itself (closed, hosted, metered) can sit in direct tension with what a license like the AGPL requires. A finding like that can lower a valuation, force expensive remediation before the deal closes, or end the acquisition.
The organizations in the best position when either scenario lands are the ones that built license governance before a regulator or an acquirer asked for it. Retrofitting compliance under deal pressure or audit deadline costs far more than building it into the pipeline from the start, in dollars and in time. What used to be a hygiene practice, something a engineering lead might get to eventually, now produces consequences that appear on a term sheet or a disqualification notice. The rest of this piece is about the mechanism that makes this risk hard to see coming, and the instrument, the SBOM, that makes it visible before it becomes either one.
How transitive dependencies make license obligations accumulate invisibly
Almost none of the license exposure in a typical codebase comes from a component that someone on the team chose on purpose. It comes from transitive dependencies, the packages pulled in automatically because a direct dependency needed them, which in turn needed others. You add one library to a project, and the build tool might quietly pull in dozens more packages underneath it, each with its own license terms that nobody on the team read, agreed to, or in many cases even saw listed anywhere.
Those obligations bind the organization regardless of whether anyone reviewed them. Copyright law does not grant an exemption for licenses nobody noticed. Every component an organization distributes, directly chosen or three layers removed, comes with terms the organization is legally bound to honor the moment it ships.
Code with no license attached is, if anything, a sharper problem than code with an unwelcome license. If code carries no explicit license grant, it stays under default copyright, so the author keeps every right and the organization using it has no legal basis to do so. That is not a rare edge case tucked away in a footnote; it is a documented category of exposure that shows up in real dependency trees.
AI coding assistants add a newer version of the same problem. Tools trained on large public codebases can reproduce code that originated in a restrictively licensed project, with nothing in the generated output indicating where it came from. Some call this license laundering. Whatever the name, it is invisible to any tool that only scans declared dependencies, because there is no declared dependency to scan.
Version drift adds a quieter risk on top of all of this. A library that shipped under a permissive license at version 1.x can switch to something far more restrictive at version 2.x, and a routine upgrade will not trigger a re-review unless the pipeline is specifically built to catch and flag that kind of change. Revenera documented exactly this kind of event with a small utility called "my_magic," where a licensing conflict led to the removal of earlier MIT-licensed versions and caused global build failures overnight. One unreviewed license change, in one small transitive dependency, stopped builds everywhere that depended on it. That is the shape of the risk this entire piece is about: a structural blind spot that nobody chose, not a developer making a bad choice.
What an SBOM actually discloses about license obligations, and where the gaps are
An SBOM is the instrument that makes transitive license exposure visible, but how much it actually reveals depends on how it was built, what format it uses, and how deep into the dependency tree it reaches. Treating any SBOM as a complete picture of license risk is a mistake, because the format and the tooling behind it set hard limits on what gets disclosed.
SPDX, one of the two dominant formats, separates what a package author claims about its license (PackageLicenseDeclared) from what a generator or human reviewer independently determined (PackageLicenseConcluded). Most automated tools populate only the declared field, pulled straight from a package manifest, and they leave the concluded field empty or set to NOASSERTION. That distinction matters because NOASSERTION is not a stand-in for a permissive license. Treating it as one in an automated policy check is simply wrong, and it is a mistake that is easy to make if the field is read without understanding what it represents.
CycloneDX, the other major format, handles license data through a licenses array attached to each component, and it accepts SPDX identifiers, free-text descriptions, or attached license text directly. That flexibility is useful, but it has a cost: two different tools generating CycloneDX output from the identical codebase can produce structurally different license representations, which makes automated policy evaluation harder to standardize across a toolchain. SPDX identifiers like MIT, Apache-2.0, GPL-2.0-only, and LGPL-2.1-or-later function as the common currency most automated policy engines are built to read. A custom license string, a free-text expression, or a blank field gets kicked into a manual review queue instead. SPDX's design leans license-first, built around SPDX expressions and compliance lineage from the ground up, which is part of why it functions as a widely used reference standard for software supply chain and license documentation.
Format aside, completeness is the bigger gap. If an SBOM only records top-level packages, it catches just a small fraction of the real license risk, because most obligations live in the transitive layer underneath it. Many SBOMs get generated too late in the development cycle to be useful, without context on how a component is actually used, and without reflecting what actually ships. The document satisfies a checklist requirement without telling anyone anything they can act on.
The hardest cases operationally are the unresolved ones: a component with no license field at all, a NOASSERTION value, or a license expression the policy engine doesn't recognize. None of these can be classified automatically, so the pipeline has to either block the build or flag it for review, and a slow review process will push developers to find a way around it. On the regulatory side, the EU Cyber Resilience Act requires SBOMs that cover at least top-level dependencies, and associated guidance such as BSI TR-03183-2 recommends mapping dependency relationships more deeply, though that depth is not written into the binding regulatory text itself. Combined with license fields increasingly named as an expectation in federal guidance, the direction of travel points toward SBOMs that capture both the full dependency graph and the license sitting at every node in it, not just the ones at the top.
How license conflict rates map to industry-specific dependency patterns
License conflicts are not spread evenly across the software industry, and the unevenness tells you something useful about where to look first. Codebases built around Big Data, AI, and machine learning carry the highest license conflict rates of any sector, because their dependency trees are both unusually complex and unusually fast-moving. These are exactly the stacks where transitive dependencies multiply the fastest, and the ones where teams have the least visibility into what they're actually shipping without systematic SBOM tooling in place. Financial services and FinTech codebases rank third, trailing EdTech, in a landscape where regulatory frameworks like India's CERT-In SBOM Guidelines from 2025 are pushing SBOM practice toward a standard expectation for government, public, and essential-services organizations, even as that framework stays voluntary.
To make sense of conflict risk across any of these sectors, you start by sorting licenses into three tiers. Permissive licenses, the MIT license, Apache 2.0, the BSD variants, and ISC, are Category A and are generally safe for automated, policy-level approval across most enterprise use cases. Weak copyleft licenses, chiefly LGPL and MPL, are Category B and require engineering and legal review focused on how the component is actually integrated into the product; whether the linking is dynamic or static changes the degree of obligation involved, with dynamic linking generally requiring notices and the ability to relink, and static linking adding the burden of shipping object files or another relink path. Strong copyleft licenses, GPL and AGPL, are Category C, and you need an explicit policy decision before you can use them. AGPL carries particular weight here, since its obligations can sit in direct conflict with SaaS distribution models, a conflict that often isn't discovered until legal review or, worse, until an acquirer's diligence team finds it first.
A fourth category sits outside this tiering: components with no detected license. If explicit terms are absent, default copyright applies, so an organization that uses that code needs permission it almost certainly never obtained. This is the category least likely to be caught by a casual scan and most likely to surprise a legal team months later.
Conflict rates this high, concentrated this unevenly by sector, are not a hypothetical risk to plan around someday. They describe a condition already present in active codebases right now, raising the question of how a team catches these conflicts before they reach a release gate, an audit, or a data room.
Treating SBOM license disclosure as a live signal inside the build pipeline
An SBOM only does useful work if it's generated at build time and its license data actively drives decisions in the pipeline, rather than being produced afterward as a document to file away. Everything in the previous sections, the invisible accumulation of transitive risk, the gaps in what different formats disclose, the uneven conflict rates by sector, points to the same conclusion: license data has to behave like a live signal, checked continuously, not a report compiled once a release is already built.
That starts with when the SBOM gets generated. It has to happen at build time, capturing the full dependency tree down through the transitive layers, because generating it afterward from a manifest alone only reflects what was declared rather than what was actually compiled or bundled into the final artifact. From there, policy rules map each license category to a specific gate action. Category A licenses clear automatically. Category B licenses trigger a warning gate: the build continues, but a review flag goes out to a defined owner who has to look at it. Category C licenses trigger a blocking gate, and the build fails until someone documents and approves an exception. Anything unknown, anything marked NOASSERTION, or anything with no license field at all goes into a mandatory review queue, and the pipeline has to choose between blocking or flagging it. Blocking is the more defensible choice from a compliance standpoint, but it only works if the review process behind it moves fast enough that developers don't start working around the block out of frustration.
Warning gates and blocking gates serve different purposes, and treating them as interchangeable produces one of two bad outcomes: either builds fail constantly over issues that didn't need to stop anything, or risk slides through disguised as a warning nobody acted on. Attribution and notice-file generation should come out of SBOM data at the same build stage that produces the binary itself, not get assembled by hand after the fact once someone remembers it's due. Exception and waiver workflows need a named owner, a documented reason for the exception, and a retention trail that survives staff turnover and contract changes, since a waiver nobody can explain two years later is functionally the same as no waiver.
Version-change detection deserves its own control, not an assumption that it's covered elsewhere. A license change introduced at a new component version will not trigger re-review on its own; the pipeline has to actively compare the incoming version's license field against the one previously approved and flag any divergence it finds. Dependency provenance, including the transitive layer, should be tracked end to end, with license-change alerts running alongside CVE alerts as a parallel category of signal inside the same system. None of this holds up, though, if the environment producing the SBOM isn't consistent. A build environment that varies from one run to the next can generate a clean-looking SBOM that doesn't actually describe what shipped, which is the problem the next section addresses directly.
Keeping the SBOM accurate when environments drift across developer machines, CI, and production
A license policy enforced against an inaccurate SBOM gives a team false confidence, and the most common reason an SBOM goes inaccurate is drift between the environments where software gets built, tested, and shipped. A developer's laptop, the CI runner, and the production environment can each resolve a slightly different set of dependency versions, and when they do, the SBOM generated at one stage stops describing what actually runs at another.
Declarative, version-pinned environment definitions, where exact package versions, transitive dependencies included, are specified and locked rather than resolved fresh at each stage, remove the variability that makes drift possible. Without that kind of pinning, an SBOM's accuracy depends on environmental conditions nobody is actually controlling or auditing, and a document like that cannot support a compliance decision no matter how well-formatted it is.
Hashes derived from the build input, attached to the environment itself, let a team confirm that the environment used to produce a given artifact is the exact one whose contents were scanned for license obligations. That closes a gap that otherwise stays open between scanning the dependencies a manifest declares and knowing what was actually present when the build ran. Platform engineering has a direct role here too: golden-path environments that encode an already-approved, license-reviewed set of dependencies mean a developer works inside a space that's already been checked, instead of assembling a dependency stack from scratch that might introduce exposure nobody has looked at yet.
Sonatype's 2025 global software assurance analysis describes this as a shift from policy to code: license compliance enforced programmatically inside the environment and the pipeline itself, rather than checked by a person at the moment of release. Teams that approach license transparency as an engineering problem to design for, rather than a document to produce after the fact, are the ones positioned to meet the audit and procurement demands already arriving, whether those demands come from a federal contract, a regulator, or an acquirer's due diligence team reading the SBOM for exactly the obligations this piece has described.
