依存関係分析によるライセンスコンプライアンス監査

インコム 2026 年 9 月 7 日コンプライアンス, Rescale データ, 企業の最新化, 影響分析, レガシーシステム

M&Aのデューデリジェンス要求は火曜日の朝に届く。すべてのソフトウェアに関する完全なオープンソースライセンス遵守レポートを金曜日までに提出せよというのだ。法務チームは、買収者の法的審査を受ける前に、製品コードベース全体のすべてのオープンソースコンポーネント、適用されるすべてのライセンス、そして履行しなければならないすべての義務を網羅したインベントリを作成するために3日間しか時間がない。ライセンス遵守を定期的な手動レビュー作業として扱っている組織にとって、その火曜日の朝は、エンタープライズソフトウェアにおける最も費用のかかる緊急対応の始まりとなる。一方、成熟した依存関係分析インフラストラクチャを備えている組織にとっては、レポートの実行から始まる。

ソフトウェアは主に記述ではなく、組み立てによって作られます。Black Duck 2026 OSSRA レポートによると、商用コードベースの 98% にオープンソースコンポーネントが含まれており、87% に少なくとも 1 つの既知の脆弱性があり、コードベースあたりの脆弱性の平均数は前年比で 2 倍以上に増加しています。ライセンスコンプライアンス監査は、異なるものの関連する疑問に答える分野です。どのコンポーネントに脆弱性が含まれているかだけでなく、どのコンポーネントがソフトウェアの配布、変更、または商用化の方法に法的義務を課しているかも明らかにします。独自の商用製品で GPL-2.0 の依存関係が欠落していたとしても、それはセキュリティインシデントではありません。それはライセンス違反であり、ソースコードの開示、法的和解、または製品の回収が必要になる可能性があります。

ライセンスコンプライアンス監査の基盤となるのは依存関係分析です。これは、コードベースが直接的または間接的に依存するすべてのソフトウェアコンポーネントを体系的に特定し、各コンポーネントを規定するライセンスを完全に特定するものです。依存関係分析は、パッケージマニフェストをスキャンするものではありません。宣言されているか、推移的であるか、ベンダー提供であるか、暗黙的であるかに関わらず、ビルド時および実行時にソフトウェアが実際に何を含んでいるかを構造的に完全に検証するものです。

ライセンス変更？その影響を把握しましょう。

SMART TS XL 標準的なSBOM生成ツールでは対応できない、メインフレームソフトウェアのコンポーネントインベントリを作成します。

さらに詳しく…

依存関係分析が基礎となる理由

ライセンス遵守は、法的問題である以前に、依存関係の問題です。ソフトウェア製品のライセンス義務を評価するには、まずその製品が何で構成されているのか、つまりすべてのコンポーネント、すべてのライブラリ、すべてのコピーされたコードスニペットを把握する必要があります。ライセンス分析は、依存関係のインベントリの下流で行われます。インベントリを誤ると、ライセンス分析は不完全な情報に基づいて行われることになります。

ライセンス遵守のために、依存関係分析が答えなければならない3つの質問：

どのようなコンポーネントが含まれていますか? 宣言されている直接的な依存関係だけではありません package.json or pom.xmlしかし、それらが取り込むすべての推移的依存関係、ソースツリーにコピーされるすべてのベンダーライブラリ、バイナリにコンパイルされるすべての静的リンクコンポーネント、および実行時に呼び出されるすべての動的ロードモジュールも対象となります。優れたSCAエンジンは、これらのコンポーネントをNVDなどの脆弱性データベースと相互参照し、ライセンスメタデータをチェックし、配信パイプラインに影響を与える前に既知のエクスプロイトや法的リスクを警告します。ライセンス分析が信頼できるものとなるためには、同じエンジンがインベントリレベル、つまりソフトウェアに実際に何が含まれているかについても正確である必要があります。

それらはどのライセンスに基づいて管理されているのでしょうか？コンポーネントには、単一の宣言済みライセンス、オプション付きのデュアルライセンス、異なるファイルに適用される複数のライセンス、またはバージョン間で変更されたライセンスが適用される場合があります。FOSSAのライセンス検出エンジンは99.8%の精度を誇り、これは法務チームがセキュリティインベントリと並行してオープンソースの義務を検証する必要がある場合に重要です。コンポーネントレベルでのライセンス識別は必要ではありますが、それだけでは不十分です。異なるファイルが異なるライセンスを持つコンポーネントの場合は、ファイルまたはスニペットレベルでの識別が必要です。

これらのライセンスはどのような義務を課すのでしょうか？寛容なライセンス（MIT、Apache-2.0）は帰属表示を義務付けます。弱いコピーレフトライセンス（LGPL）は、コンポーネントが動的にリンクされているか静的にリンクされているかによって、異なる義務を課します。強いコピーレフトライセンス（GPL-2.0、GPL-3.0）は、結合された作品全体のソースコードの配布を要求する場合があります。義務を理解するには、ライセンス識別子だけでなく、ライセンス条項を理解する必要があります。

ライセンスリスクを生み出す4種類の依存関係

すべての依存関係が、既存のツールによって同じように可視化または管理されるわけではありません。ライセンスリスクは、4つの異なる依存関係タイプから生じ、それぞれ異なる検出方法が必要です。

1. パッケージマネージャの依存関係（宣言済みおよび推移的）

最も目に見えるレイヤー: マニフェストファイルで宣言された依存関係 (package.json, pom.xml, requirements.txt, go.mod, Cargo.toml）およびビルド時に解決される推移的依存関係。パッケージマネージャの依存関係は最も網羅されているカテゴリであり、SCAツールはマニフェスト、ロックファイル、ビルド成果物をスキャンしてそれらを列挙します。

重要な違いは、直接的依存関係と推移的依存関係です。直接的依存関係とは、開発者が選択した依存関係です。推移的依存関係とは、直接的依存関係が必要とするものです。 react-data-grid Node.jsプロジェクトにパッケージを追加すると、それぞれ独自のライセンスを持つ数十もの推移的依存関係がインポートされる可能性があります。開発者はこれらのライセンスを選択したわけではありません。それらは依存関係ツリーに存在します。

JSON

// package.json: 1 direct dependency declared
{
  "dependencies": {
    "react-data-grid": "^7.0.0"
  }
}

// npm lockfile resolves to 47 transitive dependencies, including:
// - react@18.2.0 (MIT)
// - clsx@1.2.1 (MIT)
// - scheduler@0.23.0 (MIT)
// - tslib@2.6.0 (0BSD)
// - ...43 more, each with its own license
// The developer declared 1 license obligation; they shipped 47.

推移的ライセンスの落とし穴：ライセンスのリスクは、あなたが宣言した内容にあるのではなく、あなたの依存関係が宣言した内容、そしてその依存関係が宣言した内容にあります。寛容なライセンスを用いたクリーンな直接依存関係ツリーであっても、3階層にわたるGPLライセンスの推移的依存関係が隠蔽され、配布物全体にコピーレフトの義務を課してしまう可能性があります。

2. ベンダー提供およびコピーされたソースコード

外部プロジェクトのソースコードがリポジトリに直接コピーされる。これは、C/C++プロジェクト、モジュールを使用しないGoプロジェクト、およびレガシーコードベースでよく見られるパターンである。ベンダー提供コードは、依存関係マネージャーを経由せずコピー＆ペーストで追加されたため、パッケージマネージャーのマニフェストには表示されない。

SCANOSSのスニペットレベルのスキャンは、マニフェストベースの検出をはるかに超え、ソースコードの断片をOSSKBに登録されている100億を超えるオープンソースファイルと照合します。スニペットレベルのスキャンは、ベンダー提供のコードやコピーされた関数を特定するために必要です。これらの手法はマニフェスト上の依存関係を宣言しませんが、コンポーネントが明示的に含まれている場合と同様に、完全なライセンス義務を負います。

Stack Overflowの回答からコピーされたベンダー提供のユーティリティ関数は、GPLライセンスのコードに由来するものですが、直接的なGPL依存関係と同じコピーレフトの義務を負います。しかし、パッケージマニフェスト、ロックファイル、または宣言された依存関係のみを読み取る自動スキャンには、その関数はどこにも表示されません。

3. 静的リンクライブラリ

ライブラリは、ビルド時にアプリケーションバイナリに直接コンパイルされます。実行時に別ファイルとして存在する動的リンクライブラリとは異なり、静的リンクライブラリは実行可能ファイルに埋め込まれます。パッケージマネージャのマニフェストには表示されず、ビルド構成に表示されます（Makefile, CMakeLists.txt（リンカースクリプトなど）およびコンパイル済みバイナリ自体。

LGPLライセンスのライブラリの場合、静的リンクと動的リンクの違いによってライセンス義務が決定されます。LGPLはコピーレフトの伝播を伴わない動的リンクを許可していますが、静的リンクは結合された作品にコピーレフトの要件を課す可能性があります。静的にリンクされたコンポーネントとそのライセンスを特定するには、ソースマニフェストだけでなく、コンパイルされた成果物を解析するバイナリ解析ツールが必要です。

4. 実行時にロードされる依存関係

プラグインアーキテクチャ、遅延バインディング、またはスクリプトエンジンの統合によって実行時に動的にロードされるライブラリ。これらの依存関係は、ソースコード解析だけでは解決できない場合があり、実行環境、構成、および実行パスに依存します。リフレクションによってロードされるデータベースドライバ、サービスローダーメカニズムによって検出されるパーサープラグイン、および起動時にファイルシステムパスからロードされるスクリプト拡張機能はすべて、ライセンス上の問題が発生する可能性のある実行時依存関係です。

ライセンスリスクのカテゴリーとその義務

オープンソースライセンスは、寛容なものから制限的なものまで、幅広い範囲に分布しています。各ライセンスがこの範囲のどこに位置するかを理解することで、そのライセンスが課す遵守義務を把握することができます。

寛容なライセンス（MIT、Apache-2.0、BSD-2-Clause、BSD-3-Clause、ISC）

義務：帰属表示、ライセンス条項および著作権表示を配布物に含めること。ソースコードの開示は不要。商用利用は制限なく許可。独自製品への組み込みも許可。

商用ソフトウェアのリスクレベル：低。アトリビューションは自動的に容易に実行可能です。

弱いコピーレフトライセンス（LGPL-2.0、LGPL-2.1、LGPL-3.0、MPL-2.0、EUPL-1.2）

義務：ライセンス対象コンポーネントへの帰属表示と変更内容を共有する必要があります。LGPLの場合、動的リンクは一般的に呼び出しコードにコピーレフトを適用することなくライセンスを満たしますが、静的リンクでは満たせない場合があります。

商用ソフトウェアのリスクレベル：中程度。リンク方法によって異なります。動的リンクは通常安全ですが、静的リンクの場合は慎重な法的審査が必要です。

強力なコピーレフトライセンス（GPL-2.0、GPL-3.0、AGPL-3.0）

義務：帰属表示に加え、GPLコンポーネントを含むすべての結合作品をGPLの条件（ソースコードの開示）に基づいて公開しなければならない。AGPLは、これをネットワーク経由でアクセスされるソフトウェアにも拡張する。

商用ソフトウェアのリスクレベル：高。GPLライセンスのコンポーネントが、独自の商用製品に静的にリンクされている場合、または独自の商用製品から派生している場合、独自のソースコードの開示が必要になる可能性があります。これは、最も高額な訴訟和解金が発生するライセンスリスクです。

ネットワークコピーレフト（AGPL-3.0）

義務： GPL-3.0のすべての義務に加え、ネットワーク経由でソフトウェアとやり取りするユーザーはソフトウェアを受け取っているとみなされ、バイナリを配布しないSaaS製品であってもソースコード開示義務が発生します。

SaaS製品のリスクレベル：非常に高い。AGPLは、GPLにおける「SaaSの抜け穴」を塞ぐために特別に設計されています。AGPLコンポーネントを含む商用SaaS製品は、ネットワーク経由で製品とやり取りするすべてのユーザーに対して、そのソースコードを開示しなければなりません。

専有ライセンスおよび商用ライセンス

義務：ライセンス契約によって定義され、「再配布禁止」から「単位ごとのロイヤリティ」、「エンタープライズシートライセンス」まで様々です。これらはオープンソースではありませんが、商用コンポーネントを使用する場合、依存関係ツリーに表示されます。

リスクレベル：契約条件によって異なります。買収対象製品のライセンス料に関する義務が列挙されるM&Aのデューデリジェンス中に発見されることが多いです。

ライセンス互換性：重要なマトリックス

異なるライセンスを持つコンポーネントを単一のソフトウェア製品に組み合わせる場合、ライセンスは互換性のあるものでなければなりません。ライセンスの互換性がない組み合わせは、帰属表示だけでは解決できない法的リスクを生み出し、組み合わせ自体が一方または両方のライセンスに違反する可能性があります。

組み合わせ	マサチューセッツ工科大学（MIT）	Apache 2.0	LGPL-2.1	GPL-2.0	GPL-3.0	PLFA-3.0
マサチューセッツ工科大学（MIT）	互換性のあります	互換性のあります	互換性のあります	互換性のあります	互換性のあります	互換性のあります
Apache 2.0	互換性のあります	互換性のあります	互換性のあります	互換性がない	互換性のあります	互換性のあります
LGPL-2.1	互換性のあります	互換性のあります	互換性のあります	互換性のあります	互換性がない	互換性がない
GPL-2.0	互換性のあります	互換性がない	互換性のあります	互換性のあります	互換性がない	互換性がない
GPL-3.0	互換性のあります	互換性のあります	互換性がない	互換性がない	互換性のあります	互換性のあります
プロプライエタリ	互換性のあります	互換性のあります	あぶない	互換性がない	互換性がない	互換性がない

商用ソフトウェアにとって最も重大な非互換性は、Apache-2.0とGPL-2.0の非互換性です。Apache -2.0ライセンスのライブラリとGPL-2.0ライセンスのコンポーネントを同じ作品内で組み合わせることはできません。多くの基盤となるオープンソースコンポーネント（Linuxカーネルモジュール、一部の古いJavaライブラリなど）はGPL-3.0ではなくGPL-2.0であるため、この非互換性は、異なるライセンスが混在する依存関係ツリーにおいて、実際のコンプライアンスリスクを生み出します。

AGPL-3.0の条項はSaaSにとって最も制約が厳しく、基本的にネットワークコピーレフトの義務を発生させることなく、商用製品でAGPL-3.0とうまく組み合わせられるものは存在しない。

CI/CDにおけるライセンスポリシーの適用

定期的な監査に依存するライセンス遵守は、導入の時点で失敗します。例えば、前回のスプリントで追加されたGPL依存関係は、四半期ごとの監査で検出されるまでに3週間も本番環境で稼働している可能性があります。マージゲートでの継続的な強制こそが、非準拠の依存関係がコードベースに混入するのを防ぐ唯一の方法です。

ヤムル

# GitHub Actions: license compliance gate on every PR
name: License Compliance Check

on:
  pull_request:

jobs:
  license-audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install license checker
        run: npm install -g license-checker fossa-cli

      - name: Scan dependency licenses
        run: |
          license-checker --summary --excludePrivatePackages \
            --out license-report.json

      - name: Enforce license policy
        run: |
          # Block GPL-2.0, GPL-3.0, AGPL-3.0, SSPL in commercial product
          FORBIDDEN=$(license-checker --failOn \
            "GPL-2.0;GPL-3.0;AGPL-3.0;SSPL" \
            --excludePrivatePackages 2>&1 || true)

          if echo "$FORBIDDEN" | grep -q "FAIL"; then
            echo "Forbidden license detected in dependencies"
            echo "$FORBIDDEN"
            exit 1
          fi

      - name: Generate SBOM artifact
        run: |
          # Generate CycloneDX SBOM for audit trail
          npx @cyclonedx/cyclonedx-npm \
            --output-file sbom-$(date +%Y%m%d).json

      - name: Upload SBOM as artifact
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom-*.json

注意：ライセンスポリシーは組織ごとに異なります。上記の例の禁止リストは一般的な商用ポリシーを反映したものですが、貴社の法務チームは、貴社の製品タイプ、流通モデル、および顧客契約に基づいて、どのライセンスが許可され、レビュー対象となり、禁止されるかを明確に定義する必要があります。社内ツールで許可されているライブラリが、顧客向け製品では禁止される場合もあります。

SBOM生成およびフォーマット規格

ソフトウェア部品表（SBOM）は、ライセンス遵守状況を監査可能、共有可能、かつ機械検証可能にする構造化された成果物です。SBOMがこのデータを提供することで、コンプライアンスチームは手動監査を行うことなくライセンス義務を確認できます。市場には主に2つの形式が存在します。

OWASPが開発したCycloneDXは、セキュリティおよびサプライチェーンのユースケース向けに設計されています。コンポーネント、サービス、脆弱性（VEX）、数式、機械学習モデルの部品表をサポートします。セキュリティ重視のSBOMに推奨されるフォーマットであり、最新のSCAツール統合のほとんどで必要とされるフォーマットです。

SPDXLinux Foundation が管理する ISO/IEC 規格 (ISO 5962:2021)。EO 14028 の側面を含む一部の政府調達基準で要求されています。セキュリティよりもライセンスコンプライアンスに重点を置いており、より豊富なライセンス表現言語 (SPDX 式は複雑なマルチライセンスシナリオを捉えることができます。 GPL-2.0-only AND MIT OR Apache-2.0).

大統領令14028号は既にSBOM（部品表）を提供しないベンダーを連邦政府との契約から排除しており、カナダ歳入庁（CRA）は2026年9月から脆弱性報告の義務化を開始し、PCI DSS 4.0は既に監査担当者の手に渡っています。SBOMを出荷するか、取引を失うかのどちらかです。

エンタープライズソフトウェア製品の場合、両方のフォーマットを生成するコストは、同じ依存関係分析から生成する以外にほとんどかかりません。それぞれのフォーマットの対象となるユーザーは異なります。CycloneDXはセキュリティチームや脆弱性管理ワークフローで利用され、法務チーム、調達、規制遵守ワークフローでは一般的にSPDXが好まれます。

レガシーコードベースの問題点：パッケージマネージャーもマニフェストもない

上記で説明した依存関係分析ツール（SCAスキャナ、ロックファイルパーサー、SBOMジェネレータ）は、ソフトウェアの依存関係がパッケージマネージャによって管理され、マニフェストファイルで宣言されていることを前提として動作します。この前提は、最新のJava、JavaScript、Python、Go、およびRustプロジェクトには当てはまりますが、COBOL、JCL、およびメインフレームプラットフォーム上に構築された従来のエンタープライズ環境には当てはまりません。

メインフレーム環境では、サードパーティ製ソフトウェアへの依存は、標準的なSCAツールでは検出できない3つの形で現れます。

ライセンス取得済みの仕分け・ユーティリティ製品。 JCL ジョブストリームは、ユーティリティプログラム、ソート製品 (DFSORT、SyncSort/Syncsort (現在は Precisely として知られています)、CA Sort)、レポートライター (SAS、EASYTRIEVE)、およびデータ変換ツールを呼び出します。これらは、独自のライセンス条件、保守契約、およびコンプライアンス要件を持つライセンスされた商用ソフトウェアです。これらは JCL では次のように表示されます。 PGM=SORT, PGM=IEBGENER, PGM=ICETOOLプログラム名であって、パッケージ識別子ではありません。SCAツールで読み取れるものはありません。 package.json or pom.xml 彼らを見つけるだろう。

ベンダー提供のCOBOLコピーブック。サードパーティのソフトウェアベンダーは、ライセンスソフトウェアであるCOBOLコピーブックを提供します。決済処理用のCOBOLプログラムを提供するフィンテックソフトウェアベンダーは、独自のデータ構造を定義するコピーブックを提供する場合があります。これらのコピーブックを含むすべてのCOBOLプログラムは、ライセンスソフトウェアを使用しています。ライセンス義務は現実のものであり、パッケージマネージャのエントリは存在しません。

ライセンスされたソースからの組み込みアルゴリズム。COBOLシステムを実行している金融機関は、ライセンスされたアルゴリズム、保険数理計算ルーチン、暗号化実装、数値解析ライブラリなどをCOBOLソースコードに直接組み込んでいる可能性があります。これらは、ライセンスされたソースからコンパイルされてコードベースに組み込まれたものであり、パッケージマネージャからは識別できない場合があります。

これらのコンポーネントの検出方法はソースコード解析です。具体的には、CALL文をトレースして呼び出されるプログラムを特定し、COPY文を調べて含まれるメンバーを特定し、既知のサードパーティ製コンポーネントのレジストリとプログラム名を照合します。この出力はライセンスコンプライアンスのワークフローに反映されますが、最新のパッケージマニフェスト形式だけでなく、COBOLとJCLのセマンティクスを理解するツールが必要です。

監査対応可能なコンプライアンスパッケージの構築

法務部門、コンプライアンス部門、または外部監査人がライセンス遵守の証拠を要求する場合、スキャンレポートは必要ではあるものの、それだけでは十分ではありません。監査対応コンプライアンスパッケージには以下が含まれます。

完全な依存関係リスト製品とバージョンごとに整理された、推移的依存関係を含むすべてのコンポーネント、バージョン、ライセンス
ライセンス義務マトリックスライセンスのカテゴリーごとに、具体的な義務（帰属表示、出典開示、変更通知）と、それぞれの履行方法
著作権表示ファイル帰属表示が必要なすべてのコンポーネントについて、各ライセンスで要求される形式（Apache-2.0の場合はNOTICEファイル、MITの場合はLICENSEファイルなど）で法的通知をまとめました。
不適合性分析結合製品に互換性のないライセンスの組み合わせが存在しないことを示す文書、および境界事例に関する法的根拠
SBOMアーティファクト署名とタイムスタンプが付与された、対象となるすべてのコンポーネントを網羅した最新のCycloneDXまたはSPDXファイル
ポリシー文書組織の文書化されたオープンソースライセンスポリシー（新規ライセンスの承認プロセスを含む）
承認記録法的審査が必要なライセンスについては、承認文書と事業上の正当性を示す書類
修復履歴以前に特定された違反行為とその解決のために講じられた措置に関する文書

M&Aにおけるデューデリジェンスに関して言えば、買収側は技術デューデリジェンスの一環として、このパッケージを要求するケースが増えています。未解決の違反事項がないクリーンなコンプライアンスパッケージは、デューデリジェンスのプロセスを加速させます。独自製品に未解決のGPL違反が見つかった場合、通常は価格調整、エスクロー要件、または是正措置がクロージング条件として課せられますが、いずれも、違反を未然に防ぐことができたはずのコンプライアンスプログラムよりもコストがかかります。

認定条件 SMART TS XL エンタープライズコードベースにおけるライセンスコンプライアンスをサポートします。

SMART TS XLさんアプリケーション依存関係マッピングエンタープライズコードベース、特に標準的なSCAツールでは限界に達するレガシー環境において、構造的依存関係分析レイヤーを提供します。

メインフレーム環境の場合、依存関係マップは、他のすべてのプログラムから呼び出されるすべてのプログラム（JCLおよびCOBOLに埋め込まれたサードパーティ製ユーティリティ呼び出しを可視化）、すべてのプログラムに含まれるすべてのコピーブック（ベンダー提供のコピーブックの依存関係を可視化）、およびすべてのプログラムからアクセスされるすべてのデータセット（ライセンスされたデータベース製品に対するデータ層の依存関係を可視化）を特定します。この分析により、パッケージマネージャが存在しない環境におけるライセンスコンプライアンス監査の前提条件となるコンポーネントインベントリが生成されます。

静的コード分析機能は、特定のサードパーティコンポーネントに関連付けられたコードパターン（独自のAPI呼び出しシグネチャ、ベンダー固有のデータ構造規則、カスタムCOBOLソースに組み込まれたライセンス付きアルゴリズム実装など）を特定します。これらの分析結果は、マニフェストベースのインベントリを補完し、マニフェストスキャンでは到達できないコードレベルの依存関係を明らかにします。

影響分析機能により、ライセンスポリシーの変更を具体的な対策に結びつけることができます。コンポーネントのライセンスが変更された場合、依存関係にあるコンポーネントのライセンスがMITからAGPL-3.0に変更された場合、ベンダーが利用規約を変更した場合、影響分析機能は、そのコンポーネントに直接的または間接的に依存するポートフォリオ内のすべてのプログラムを特定します。これにより、ライセンス変更という事象が、未知のリスクから明確な対策範囲へと変換されます。

エンタープライズ検索機能により、コンプライアンス目的で依存関係インベントリを照会できるようになります。特定のユーティリティを呼び出すすべてのプログラム、特定のベンダー提供メンバーを含むすべてのコピーブック、特定のライセンスコンポーネントに依存するすべてのプログラムを、レガシーポートフォリオ全体にわたって数秒で検索できます。この検索機能は、火曜日の朝に発生するM&A監査要求に対応する実用的なツールです。手動レビューではなく、クエリを実行するだけで済みます。

最新システムとレガシーシステムの両方を網羅する包括的なSBOMカバレッジを構築する組織にとって、 SMART TS XL 標準的なSBOMジェネレーターでは生成できないレガシーコンポーネントのインベントリを提供し、最新のスタック向けにSyft、FOSSA、Dependency-Trackなどのツールを補完します。

決して驚くべきことではない監査

ライセンス遵守監査は、規制当局ではなく、ライセンス条項を読み、遵守の証拠を求めるビジネスパートナー、買収者、顧客の法務チーム、または販売代理店によって違反の罰則が発覚することが多い、数少ない規制分野の一つです。その発覚に伴うコストは、違反の重大性や取引の段階によって、気まずい思いをするものから、事業存続に関わるものまで様々です。

この発見が予期せぬ事態にならないようにするための依存関係分析プログラムは、軽減できるリスクに比べれば決して高価ではありません。必要なのは、ソフトウェアに含まれるすべてのコンポーネント、すべての推移的依存関係、すべてのベンダー提供のコードスニペット、すべてのレガシーユーティリティを把握し、組織のライセンスポリシーに照らし合わせて、定期的にではなく継続的にチェックすることです。必要なツールは既に存在します。標準規格（SBOM、SPDX、CycloneDX）も存在します。規制要件（EO 14028、CRA、PCI-DSS 4.0）も存在します。ほとんどの組織にとって唯一欠けているのは、依存関係分析を監査作業ではなくインフラストラクチャとして扱うという規律です。

火災訓練ではなく報告書作成から始まる火曜日の朝は、依存関係分析のインフラストラクチャによって可能になった火曜日の朝だ。