sbom-diff

SBOM Compliance & License Policies Explained

Last updated November 2026

Software Bills of Materials (SBOMs) are increasingly required for compliance, supply chain security, and license management. This guide covers regulatory requirements, common license policies, and how to implement automated checks.

Regulatory Compliance Requirements

1. U.S. Executive Order 14028 (2021)

President Biden's cybersecurity executive order mandates SBOMs for software sold to federal agencies. Key requirements:

2. NTIA Minimum Elements (2021)

The National Telecommunications and Information Administration (NTIA) defined seven minimum required fields for SBOMs:

Field Description CycloneDX SPDX
Component Name Human-readable name name name
Component Version Version identifier version versionInfo
Unique Identifier PURL, CPE, or SWID purl externalRefs
Dependency Relationships How components relate dependencies relationships
Author Component creator author originator
Timestamp SBOM creation time metadata.timestamp created
Supplier Component source supplier supplier
Note: Both CycloneDX and SPDX can carry all NTIA minimum elements, but generators do not always fill them in. Check that supplier, version and unique identifiers (purls) are actually populated.

3. CISA Guidelines

The Cybersecurity and Infrastructure Security Agency (CISA) provides guidance on SBOM implementation. In 2026 it published updated minimum elements that replace NTIA's 2021 list, adding fields such as component hash, component license, the name of the tool that generated the SBOM, and the generation context. General practice it recommends:

4. EU Cyber Resilience Act (Regulation (EU) 2024/2847)

The CRA is in force. Manufacturers' duty to report actively exploited vulnerabilities and severe incidents applies from 11 September 2026; the remaining obligations, including the SBOM requirement, apply from 11 December 2027. It requires:

Open Source License Policies

License compliance is a critical reason for generating SBOMs. Here are common license policies and their implications:

1. No GPL Policy

What it means: Block all GNU General Public License (GPL) versions.

Why: GPL requires derivative works to be open-sourced under GPL. If you link GPL code into proprietary software, you may be legally required to release your source code.

Variants:

Common misconception: Using GPL libraries in a microservice or container may still trigger copyleft obligations if the service is distributed to customers. Consult legal counsel for your specific use case.

2. No AGPL Policy

What it means: Block all Affero General Public License (AGPL) versions.

Why: AGPL extends GPL's copyleft to network services. If you modify AGPL code and run it as a web service, you must release your modifications—even if you don't distribute the software.

Impact: AGPL is particularly restrictive for SaaS companies. Many enterprises ban AGPL entirely.

3. No Copyleft Policy

What it blocks: GPL, AGPL, LGPL (Lesser GPL), MPL (Mozilla Public License), EPL (Eclipse Public License), and similar "share-alike" licenses.

Why: Maximum flexibility for proprietary software. Avoid any obligation to share source code.

4. No SSPL Policy

What it means: Block Server Side Public License (used by MongoDB, Elastic).

Why: SSPL requires cloud providers to open-source their entire service stack if they offer the software as a service. Even more restrictive than AGPL.

5. Permissive Only Policy

What it allows: Only MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC, Unlicense, and similar permissive licenses.

Why: Maximum freedom to use, modify, and distribute without source code disclosure obligations.

How to Implement License Policies

Option 1: Use Our SBOM Diff Tool

  1. Generate your SBOM (see How to Generate SBOM)
  2. Load it into SBOM Diff (it runs in your browser; nothing is uploaded)
  3. Enable "License Policy" and select a preset (No GPL, No AGPL, etc.)
  4. Review violations and remediate by replacing libraries

Option 2: Automate in CI/CD

Integrate license checking into your build pipeline:

# Example: GitHub Actions with Syft + Grype
name: License Check
on: [push]
jobs:
  license-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Generate SBOM
        run: syft dir:. -o cyclonedx-json > sbom.json
      - name: Check for GPL
        run: |
          if grep -q "GPL-" sbom.json; then
            echo "GPL license detected"
            exit 1
          fi

Option 3: Use Dedicated Tools

Common License Violations & Remediation

Scenario 1: GPL in Proprietary Software

Problem: You're building a proprietary desktop app and discover a GPL-licensed library in your SBOM.

Solutions:

Scenario 2: AGPL in SaaS Platform

Problem: You're running a SaaS product and find an AGPL library in your SBOM.

Solutions:

Scenario 3: Unknown Licenses

Problem: Your SBOM shows components with "UNKNOWN" or "NOASSERTION" licenses.

Solutions:

Best Practices

  1. Generate SBOMs early: Add SBOM generation to your CI/CD pipeline from day one
  2. Automate policy checks: Block builds that violate license policies
  3. Track changes: Compare SBOMs between versions to catch new violations (use our diff tool)
  4. Educate developers: Teach teams to check licenses before adding dependencies
  5. Document exceptions: If you must use a restricted license, document why and get legal approval
  6. Update regularly: Re-generate SBOMs with each release to catch transitive dependency changes

Industry-Specific Guidelines

Healthcare (HIPAA, FDA)

Financial Services (PCI-DSS, SOX)

Government Contracting

Related Guides