トップ > テクノロジー > えっ、ソース名とパッケージ名って違うんですか？ ― 脅威インテリジェンスインターンで挑んだSBOM調査バトル

えっ、ソース名とパッケージ名って違うんですか？ ― 脅威インテリジェンスインターンで挑んだSBOM調査バトル

テクノロジー インターン セキュリティ

はじめに

こんにちは、NTTドコモグループの現場受け入れ型インターンシップ2025に参加した博士1年の樋口です。 私が参加したポストは、【D3】脅威インテリジェンスを生成・活用するセキュリティエンジニア/アナリストです。前半は Network Analytics for Security PJ（以下、NA4Sec）、後半は Metemcyber PJ（以下、Metemcyber）に参加し、幅広い内容を学ぶことができました。 本体験記が、来年以降に参加を検討されている方の一助となりましたら幸いです。

インターンシップの説明

参加した経緯

きっかけは、論文の査読コメントに書かれていた一言でした。

main issue: Why this research is important? Threat model should be added to this manuscript.

前半については、単に私の書き方が悪かっただけなので、すぐに修正できました。 一方で、後半に書かれていた「Threat model」とは何なのかが気になり、調べ始めたことが、脅威インテリジェンスに興味を持つ最初のきっかけになりました。 調べていくうちに、実際の調査方法や扱う範囲の広さから、「これを一人で独学するのはかなり大変そうだ」と感じるようになりました。

どうせ学ぶなら、最先端で業務として脅威インテリジェンスに取り組んでいる現場で学びたい。そう考えて情報を探していたところ、このインターンシップに出会いました。 また、私自身が博士課程に在籍していることもあり、インターンシップに申し込んでよいのか正直迷っていました。 そんな中、NA4Sec の神田さんから「気にせず申し込んで大丈夫」と背中を押していただけたことも、参加を決める大きなきっかけになりました。

概要

インターンシップは2週間にわたって実施され、1 週目は本ポストにも参加している脇本くんと同じ内容に取り組み、2 週目は互いに異なる活動に取り組みました。 本ポストのインターン生だった脇本くんのインターンシップ体験記はすでに公開されていますので、よろしければそちらもあわせてご覧ください。 私は、2週間のインターンシップで以下の活動を行いました。

1週目 (Na4Secチーム):

  • Cobalt Strike の調査/分析・ハンズオン1
  • フィッシングサイトに関する調査/分析・ハンズオン2

2週目 (Metemcyberチーム):

  • SBOM 生成ツール「Threatconnectome」の研究開発

2週目の Metemcyber では朝会があり、私も参加させていただきました。 毎朝、その日に何を進めるのか、どの程度進捗しているのかを共有するのですが、とても新鮮でした。「今週の目標が何で、いまどの位置にいるのか」をチーム全体でそろえることで、進捗や課題の共有がとてもスムーズになるのだと実感しました。

以降では、このような 2週目での経験を踏まえつつ、SBOM 生成ツール「Threatconnectome」の研究開発について、主にお話ししていきます。

SBOM

SBOMとは何か

SBOMとは「Software Bill of Materials」の略称で、ソフトウェアがどのような要素から構成されているのかを一覧表としてまとめたものを指します。 経済産業省の「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引 Ver 2.0」では、SBOM について次のように説明されています。

SBOM とは、ソフトウェアコンポーネントやそれらの依存関係の情報も含めた機械処理可能な一覧リストである。SBOM には、ソフトウェアに含まれるコンポーネントの名称やバージョン情報、コンポーネントの開発者等の情報が含まれ、OSS だけではなくプロプライエタリソフトウェアに関する情報も含めることができる。また、SBOM をソフトウェアサプライチェーンの上流から下流に向かって組織を越えて相互共有することで、ソフトウェアサプライチェーンの透明性を高めることが期待されており、特に、コンポーネントの脆弱性管理の課題に対する一つの解決策として期待されている。

フォーマットごとの差分

SBOM は、一般的に次の 2 つのフォーマットで生成されることが多いです。 ただし、極端な話、下記 2 つに準拠していなくても「SBOM」と名乗ること自体は可能である点には注意が必要です。

  • SPDX
  • CycloneDX

以降では、実際にこの 2 つのフォーマットを生成し、生成された JSON ファイルを確認しながら、どのような違いがあるかを比較してみましょう。 ここでは、コンテナ／ファイルシステム向けのセキュリティスキャナ兼 SBOM 生成ツールである Trivy を使い、コンテナイメージ nginx:latest から SBOM を作成します。

SPDX

SPDXは、Linux Foundationが策定している SBOM フォーマットです。SPDXの公式サイトでは、SPDX を次のように説明しています。

SPDX is an open standard for communicating software bill of material information, including provenance, license, security, and other related information.

また、SPDX は国際標準規格 ISO/IEC 5962:2021 としても認定されており、 ソフトウェアのライセンスやコンプライアンス、セキュリティなどの情報をやり取りするための標準として位置づけられています。

これらを踏まえると、SPDX は「ソフトウェアに含まれるコンポーネントやライセンス情報、著作権情報などを詳細かつ厳密に記述できる SBOM フォーマット」と言えます。 特に、法務・コンプライアンスの観点での活用を想定しており、ライセンス遵守状況の確認や監査対応に向いています。

それでは、SPDX の SBOM を生成してみましょう。以下に、trivyを用いた生成例を示します。

trivy image --format spdx-json --output sbom.spdx.json nginx:latest

このコマンドを実行すると、sbom.spdx.json という SPDX 形式の SBOM ファイルが出力されます。

生成されたJSONファイルは以下のようになります(一部抜粋)。

    {
      "name": "apt",
      "SPDXID": "SPDXRef-Package-4289b9e5f32d574b",
      "versionInfo": "3.0.3",
      "supplier": "Organization: APT Development Team \u003cdeity@lists.debian.org\u003e",
      "downloadLocation": "NONE",
      "filesAnalyzed": false,
      "sourceInfo": "built package from: apt 3.0.3",
      "licenseConcluded": "GPL-2.0-or-later AND LicenseRef-aba21f0b27260cd4 AND BSD-3-Clause AND MIT AND GPL-2.0-only",
      "licenseDeclared": "GPL-2.0-or-later AND LicenseRef-aba21f0b27260cd4 AND BSD-3-Clause AND MIT AND GPL-2.0-only",
      "externalRefs": [
        {
          "referenceCategory": "PACKAGE-MANAGER",
          "referenceType": "purl",
          "referenceLocator": "pkg:deb/debian/apt@3.0.3?arch=amd64\u0026distro=debian-13.2"
        }
      ],

上の例では、apt パッケージについての情報が含まれています。

このようなエントリが多数並ぶことで、コンテナイメージ内部のパッケージ構成とそれぞれのライセンス情報を、SPDX 形式の SBOM として機械可読に表現できます。 また、ライセンス管理やコンプライアンス管理をしやすくするために、このフォーマットが設計されていることがわかります。

CycloneDX

CycloneDX は OWASP が主導している SBOM フォーマットで、CycloneDXの公式サイトでは次のように紹介されています。

OWASP CycloneDX is a full-stack Bill of Materials (BOM) standard that provides advanced supply chain capabilities for cyber risk reduction.

さらに、CycloneDX 自身も Ecma International の標準（ECMA-424）として策定されており、 ソフトウェアサプライチェーンにおけるサイバーリスク低減を強く意識した仕様になっています。

このことから、CycloneDX は「セキュリティや脆弱性管理への利用を強く意識して設計された SBOM フォーマット」と言えます。 依存関係の構造や、脆弱性スキャナ・セキュリティツールとの連携を前提としたフィールドが充実しており、セキュリティ運用のワークフローに組み込みやすい点が特徴です。

それでは、CycloneDX の SBOM を生成してみましょう。以下に、trivyを用いた生成例を示します。

trivy image --format cyclonedx --output sbom.cyclonedx.json nginx:latest

こちらのコマンドでは、CycloneDX形式のSBOMがsbom.cyclonedx.jsonとして出力されます。 生成されたJSONファイルは以下のようになります(一部抜粋)。

{
  "components": [
    {
      "bom-ref": "pkg:deb/debian/apt@3.0.3?arch=amd64&distro=debian-13.2",
      "type": "library",
      "supplier": {
        "name": "APT Development Team <deity@lists.debian.org>"
      },
      "name": "apt",
      "version": "3.0.3",
      "licenses": [
        {
          "license": {
            "id": "GPL-2.0-or-later"
          }
        },
        {
          "license": {
            "name": "curl"
          }
        },
        {
          "license": {
            "id": "BSD-3-Clause"
          }
        },
        {
          "license": {
            "id": "MIT"
          }
        },
        {
          "license": {
            "id": "GPL-2.0-only"
          }
        }
      ],
      "purl": "pkg:deb/debian/apt@3.0.3?arch=amd64&distro=debian-13.2"
    }
  ],
  "dependencies": [
    {
      "ref": "nginx:latest",
      "dependsOn": [
        "pkg:deb/debian/apt@3.0.3?arch=amd64&distro=debian-13.2"
      ]
    }
  ]
}

ref と dependsOn の組み合わせで、「どのコンポーネントがどのコンポーネントに依存しているか」という依存関係のグラフを定義しています。 これによって、あるライブラリに脆弱性が見つかったときに、以下をツール側で自動的に追跡できるようになります。

  • どのイメージがそのライブラリに依存しているか
  • 依存関係を辿ったとき、どこまで影響が波及するか

上記項目が入ることで、「どのコンポーネントがどのコンポーネントに依存しているか」を表現できていることが分かります。

このように、CycloneDX の JSON をそのままセキュリティツールが読み取ることで、「どのコンポーネントにどんな脆弱性やライセンスリスクがあるか」や「そのコンポーネントに依存しているのはどの部分か」といった情報を機械的に解析できるようになり、結果として脆弱性や依存関係の管理がしやすくなります。

小括

一般的には、次のように整理できます。

  • SPDX：ライセンス管理やコンプライアンス対応に向いている
  • CycloneDX：コンポーネントの脆弱性管理や依存関係の把握に向いている

以上を踏まえて、要点を表にまとめると以下の通りです。

観点 SPDX CycloneDX
主な用途 ライセンス・著作権・コンプライアンスを主目的として発展 サプライチェーンにおける脆弱性・依存関係・セキュリティ運用を意識して設計
提唱元 Linux Foundation OWASP
脆弱性・影響範囲の追跡 可能だが、フォーマットとしては汎用寄り CVE 突き合わせや影響範囲の追跡をツール側で行いやすい設計
今回の Trivy での出力例 --format spdx-json --format cyclonedx
ざっくりイメージ 「法務・ライセンスに強い部品表」 「セキュリティ運用に強い部品表」

Threatconnectome

以降では、SBOM をインポートして脆弱性管理を行う Metemcyber のOSSプロジェクト Threatconnectome を前提に議論するため、まずその概要を紹介します。

Threatconnectomeの紹介

Threatconnectomeは現在、GitHubで公開されており、以下のように説明されています。

Threatconnectome supports vulnerability management in industries where products are hard to update, such as automotive, manufacturing and communications infrastructure.

ここからわかるように、自動車・製造業・通信インフラなど、製品のアップデートが難しい領域向けの脆弱性管理プラットフォームとして提供されています。つまり、先ほどのようにSBOMを生成し、それをわかりやすく管理できるプラットフォームとなっています。 なお、2025年11月現在、SPDX2.3、CycloneDX1.6がサポート対象となっています。 先ほど紹介した GitHub リポジトリでは、Threatconnectome のデモ環境が公開されているため、実際にアクセスしてみましょう。 デモ環境へのアクセス方法は、リポジトリ内の README に記載されています。

アクセスすると、まず次のような画面が表示されます。

もし脆弱性が検知された場合は、下記のようにアラート画面が表示され、 誰が対応を担当するか、といったアサイン操作などを行うことができます。

画面中央の Uploadから、ユーザが生成した SBOM をアップロードすることも可能です。 実際に、先ほど生成した CycloneDX 形式の SBOM をアップロードしてみると、次のように表示されます。

このように、Threatconnectome は「生成した SBOM を取り込み、脆弱性の有無をチェックし、 必要に応じてアラートや担当者アサインまで行える脆弱性管理プラットフォーム」として動作していることが分かります。

抱える課題

Threatconnectome では、SBOMをインポートし、Trivy が利用している脆弱性データベースである Trivy DB の情報を用いて脆弱性管理を行っています。 現在は Trivy および Syft が生成した SBOM のみを入力対象としていますが、将来的には対応する SBOM 生成ツールの種類を広げていきたいという課題を抱えています。

ここで問題になるのが、Linux ディストリビューションのパッケージマネージャ（dpkg / apt / rpm / apk など）で管理される OS パッケージの脆弱性検知です。 Trivy DB は Ubuntu / Debian 系の脆弱性情報を、ソースパッケージ（Source Package）の名前をキーとして管理しています。 Ubuntu / Debian 系では、ビルドの単位となる「ソースパッケージ」と、実際にインストールされる「バイナリパッケージ」が区別されています。SrcName は、このソースパッケージ名を SBOM 上で表現するために、Trivy が独自プロパティとして付与しているものです。

Trivy が生成する CycloneDX 形式の SBOM には、次のような項目が存在します。

        {
          "name": "aquasecurity:trivy:SrcName",
          "value": "openssl"
        },

Trivy で生成した CycloneDX 形式の SBOM では、properties フィールドに生成ツール固有のメタデータが出力されます。 そのうち、Trivy 固有の項目である aquasecurity:trivy:SrcName の value がソースパッケージ名を表します。 しかし、同じコンポーネントには name として次のような情報が記載されています。

            "name": "libssl3t64",

Trivy が生成する CycloneDX 形式の SBOM では、この name がバイナリパッケージ名を表すことが多く、上記からわかるように両者は必ずしも一致しません。 その結果、SBOM から得た情報だけでは、ソースパッケージ名と正しく突き合わせて脆弱性を検知することが難しくなる可能性があります。 また、ソースパッケージ名を扱うためには SBOM 中に SrcName が含まれている必要がありますが、その有無や表現方法は SBOM 生成ツールに依存します。 このため、対応ツールを拡張するにあたっては、各ツールの出力における SrcName 相当情報の扱いを確認する必要があります。

実施した調査

方針

本調査では、SBOM 生成ツールを用いて実際に SBOM ファイルを生成し、主に次の点を確認しました。

  • 生成される SBOM のフォーマット
  • 独自プロパティSrcName (または同等の情報）の有無と表現方法

その結果を踏まえ、各 SBOM 生成ツールが出力する SBOM を Threatconnectome が処理できるかどうかを判断しました。

なお、OS パッケージの分類やソースパッケージ名／バイナリパッケージ名の違い、そこから生じる問題点については、最近公開されたエンジニアブログエントリーでも整理されています。 本調査でも同様の整理に基づいて問題を位置づけています。

本調査で対象としたツールは以下の 2 つです。

  • OSS Review Toolkit (ORT)
  • ScanCode

OSS Review Toolkit (ORT)

概要

OSS Review Toolkit（以下 ORT）は、ソフトウェアプロジェクトの管理と分析を支援するツールキットとして提供されています。 複数の機能に分かれており、それぞれ Analyzer、Scanner、Advisor、Evaluator、Reporter の 5 つのコンポーネントが独立して動作しつつ、結果を連携させて処理を進めることができます。

今回、CycloneDX 形式の JSON ファイルを生成するためには、Analyzer → Reporter の順に実行する必要があります。

なお、本調査では「OS パッケージが検知できるか」を確認するため、test ディレクトリに OS パッケージのみを配置した環境を用意しました。

環境構築

今回は、Gradle 経由で ORT をインストールしました。 Gradle 経由でインストールした場合、ORT を起動するための実行スクリプトが cli/build/install/ort/bin/ort というパスに作成されます。 以降は、この方法でインストールした ORT を前提に説明します。

実行方法

# 通常の実行例
./ort analyze --input-dir test --output-dir .

# 短縮オプションを用いる場合
./ort analyze -i test -o .

# ORT のルートディレクトリから直接実行する場合
cli/build/install/ort/bin/ort analyze -i test -o .

上記コマンドを実行すると、Analyzerの結果としてYAMLファイルが生成されます。

---
repository:
  vcs:
    type: "Git"
    url: "https://github.com/oss-review-toolkit/ort"
    revision: "d47c9ac5d6f922020aa8ddc14605686e2bf955fa"
    path: "cli/build/install/ort/bin/test"
  vcs_processed:
    type: "Git"
    url: "https://github.com/oss-review-toolkit/ort.git"
    revision: "d47c9ac5d6f922020aa8ddc14605686e2bf955fa"
    path: "cli/build/install/ort/bin/test"
  config: {}
analyzer:
  start_time: "2025-09-02T06:36:17.500581Z"
  end_time: "2025-09-02T06:36:17.785581Z"
  environment:
    ort_version: "66.1.0"
    build_jdk: "21.0.7+6-LTS"
    java_version: "21.0.8"
    os: "Mac OS X"
    processors: 8
    max_memory: 8589934592
    variables:
      HOME: "/Users/sectu"
      SHELL: "/bin/zsh"
      TERM: "xterm-256color"
    tool_versions: {}
  config:
    allow_dynamic_versions: false
    enabled_package_managers:
    - "Bazel"
    - "Bower"
    - "Bundler"
    - "Cargo"
    - "Carthage"
    - "CocoaPods"
    - "Composer"
    - "Conan"
    - "GoMod"
    - "GradleInspector"
    - "Maven"
    - "NPM"
    - "NuGet"
    - "PIP"
    - "Pipenv"
    - "PNPM"
    - "Poetry"
    - "Pub"
    - "SBT"
    - "SpdxDocumentFile"
    - "Stack"
    - "SwiftPM"
    - "Tycho"
    - "Unmanaged"
    - "Yarn"
    - "Yarn2"
    skip_excluded: false
  result:
    projects:
    - id: "Unmanaged::ort:d47c9ac5d6f922020aa8ddc14605686e2bf955fa"
      definition_file_path: ""
      declared_licenses: []
      declared_licenses_processed: {}
      vcs:
        type: ""
        url: ""
        revision: ""
        path: ""
      vcs_processed:
        type: "Git"
        url: "https://github.com/oss-review-toolkit/ort"
        revision: "d47c9ac5d6f922020aa8ddc14605686e2bf955fa"
        path: "cli/build/install/ort/bin/test"
      homepage_url: ""
      scopes: []
    packages: []
scanner: null
advisor: null
evaluator: null
resolved_configuration:
  package_curations:
  - provider:
      id: "DefaultDir"
    curations: []
  - provider:
      id: "DefaultFile"
    curations: []

次に、この YAMLファイルをReporterに渡してCycloneDX形式のSBOMを生成します。

./ort report -f CycloneDX --ort-file analyzer-result.yml --output-dir .

これにより、bom.cyclonedx.json が生成されます。

{
  "bomFormat" : "CycloneDX",
  "specVersion" : "1.6",
  "serialNumber" : "urn:uuid:2b46dd12-caa0-40c2-a5f9-8ca2958fc134",
  "version" : 1,
  "metadata" : {
    "timestamp" : "2025-09-02T06:23:22Z",
    "tools" : {
      "components" : [
        {
          "type" : "application",
          "name" : "OSS Review Toolkit",
          "version" : "66.1.0"
        }
      ],
      "services" : [ ]
    },
    "component" : {
      "type" : "file",
      "bom-ref" : "https://github.com/oss-review-toolkit/ort.git@d47c9ac5d6f922020aa8ddc14605686e2bf955fa",
      "name" : "https://github.com/oss-review-toolkit/ort.git",
      "version" : "d47c9ac5d6f922020aa8ddc14605686e2bf955fa"
    },
    "licenses" : [
      {
        "expression" : "CC0-1.0"
      }
    ]
  },
  "externalReferences" : [
    {
      "type" : "vcs",
      "url" : "https://github.com/oss-review-toolkit/ort.git",
      "comment" : "URL to the Git repository of the projects"
    }
  ]
}

考察

生成された yaml、json を確認すると、packages が空であることから、今回はパッケージ情報が取得できていないことが分かります。 今回用意した test フォルダの内容に対して、ORT では OS パッケージを取得できていない可能性が高いと考えられます。

また、ORT の公式ドキュメントによると、

The analyzer is a Software Composition Analysis (SCA) tool that determines the dependencies of software projects inside the specified version-controlled input directory ( -i ). It is the only mandatory tool to run from ORT as its output is the input for all other tools. Analysis works by querying the detected package managers; no modifications to your existing project source code, like applying build system plugins, are necessary for that to work if the following preconditions are met

と記されています。

上記の通り、Analyzer は ORT の他ツールすべての入力となるコンポーネントであり、同時に「ソフトウェアプロジェクトの依存関係を解析する SCA ツール」として提供されています。 この設計上の前提から、OS パッケージのような「プロジェクト外のベースイメージ由来のパッケージ」については、そもそも取得対象になっていないのではないかと考えられます。

なお、関連ツールとして tern というツールでは OS パッケージが検知できるとされていますが、私のインターン期間中には環境構築が間に合わず、実際に確認することはできませんでした。

ただし、少なくとも現時点で得られた結果からは、「ORT の Analyzer / Reporter の組み合わせだけでは、今回の test ディレクトリに含めた OS パッケージを CycloneDX SBOM として取得することはできなかった。」と結論付けました。

ScanCode

概要

ScanCode は、OSS のライセンスやパッケージ情報を解析し、SBOM などを生成できるツールです。比較的簡単にインストール・実行でき、CI/CD パイプラインにも組み込みやすい設計になっています。 また、複数のパイプラインが用意されており、コンテナイメージを対象とした SBOM 生成も可能です。

環境構築

まず、リポジトリをクローンして Docker イメージをビルドします。

git clone https://github.com/aboutcode-org/scancode.io.git
cd scancode.io
make envfile
docker compose build

Apple Silicon を採用した Mac を使う場合、docker-compose.yml を編集します。

Docker 側は Linux 向けの arm64 イメージを使おうとしますが、Apple Silicon 自体も arm64 であるため、macOS 向けの arm64 用リポジトリに向かってしまい、うまく動作しないケースがあります。 これを解決するためには、platform: linux/amd64を追加する必要があります。 そのため、本調査では web, worker, clamav サービスに以下の設定を追加し、Linux の amd64 としてコンテナを動かすようにしました。

web:
  build: .
  command: >
    sh -c "
    ./manage.py migrate &&
    ./manage.py collectstatic --no-input --verbosity 0 --clear &&
    gunicorn scancodeio.wsgi:application --bind :8000 --timeout 600
    --workers 8 ${GUNICORN_RELOAD_FLAG:-}"
  platform: linux/amd64
  env_file:
    - docker.env
  expose:
    - 8000
  volumes:
    - .env:/opt/scancodeio/.env
    - /etc/scancodeio/:/etc/scancodeio/
    - workspace:/var/scancodeio/workspace/
    - static:/var/scancodeio/static/
  depends_on:
    db:
      condition: service_healthy
    redis:
      condition: service_started
    chown:
      condition: service_completed_successfully

worker:
  build: .
  # potential db migrations が完了するまで "web" を待つ
  command: >
    wait-for-it --strict --timeout=600 web:8000 -- sh -c "
    ./manage.py rqworker --worker-class scancodeio.worker.ScanCodeIOWorker
    --queue-class scancodeio.worker.ScanCodeIOQueue
    --verbosity 1"
  platform: linux/amd64
  env_file:
    - docker.env
  volumes:
    - .env:/opt/scancodeio/.env
    - /etc/scancodeio/:/etc/scancodeio/
    - workspace:/var/scancodeio/workspace/
  depends_on:
    - redis
    - db
    - web
    - chown

clamav:
  image: docker.io/clamav/clamav:latest
  platform: linux/amd64
  volumes:
    - clamav_data:/var/lib/clamav
    - workspace:/var/scancodeio/workspace/
  restart: always

設定変更後、以下を実行してコンテナ群を起動します。

docker compose up

実行方法

まず、ブラウザから ScanCode.ioのUIにアクセスし、New Projectから Dockerイメージを指定します。その後、下側の pipeline には analyze_docker_image を選択します。

Download URLs には次のような形式で Docker イメージを指定します。今回はalpine:latestを指定しています。

docker://<image name>:<tag>
e.g.)docker://alpine:latest

処理が完了すると、プロジェクト一覧でステータスが Success と表示されます。 自分が作成したプロジェクトをクリックし、画面上部の緑色のボタンから CycloneDX を選択して、CycloneDX 形式の SBOM をダウンロードします。

以下に、生成したjsonを示します(一部抜粋)。

      "name": "libcrypto3",
      "properties": [
        {
          "name": "aboutcode:homepage_url",
          "value": "https://www.openssl.org/"
        },
        {
          "name": "aboutcode:package_uid",
          "value": "pkg:alpine/libcrypto3@3.5.1-r0?arch=x86_64&uuid=bd3ad788-4a83-4509-965b-1068090db4cf"
        }
      ],
      "purl": "pkg:alpine/libcrypto3@3.5.1-r0?arch=x86_64",
      "type": "library",
      "version": "3.5.1-r0"
    },
    {
      "bom-ref": "pkg:alpine/libssl3@3.5.1-r0?arch=x86_64&uuid=d6a913c7-309a-4741-89dc-3207e125348e",
      "copyright": "",
      "description": "SSL shared libraries",
      "externalReferences": [
        {
          "type": "vcs",
          "url": "git+https://git.alpinelinux.org/aports/commit/?id=370a62f0ac139d30d09aba7ed93fcbf455a032ae"
        }
      ],
      "licenses": [
        {
          "expression": "Apache-2.0"
        }
      ],

考察

今回の調査では、ScanCode のパイプライン analyze_docker_image を用いることで、OS パッケージも SBOM に含まれていることを確認できました。 一方で、Trivy の例で登場した SrcName のような「ソースパッケージ名」に相当する情報は取得できず、SrcName そのものを CycloneDX の properties 等として明示的に出力することはできませんでした。 以上より、ScanCode については、「OS パッケージを対象にした CycloneDX SBOM を生成することはできる一方で、SrcName をキーとした検知漏れ対策という観点では、そのままでは要件を満たさない可能性がある。」と結論付けました。

本調査から得られたこと

本調査などを通じて、大きく 2 つのことを学びました。

第一に、ツールの開発元の考え方や背景を事前に調べておく必要がある、という点です。 今回扱った ORT、ScanCodeはいずれも「SBOM を生成できるツール」として紹介されていますが、実際には想定しているユースケースや設計思想がそれぞれ異なっていました。 例えば ORT は、SCA（Software Composition Analysis）ツールとして「プロジェクトの依存関係」を主な対象としており、OS パッケージの取得はそもそも守備範囲外である可能性が高いことが分かりました。

このように「どの企業／コミュニティが、どんな目的で作ったツールなのか」を押さえておかないと、自分たちの要件（SrcName ベースでのマッチングなど）と微妙にズレたツールを選んでしまい、期待した情報（source_name / SrcName など）が出てこない、というミスマッチが起こり得ます。 そのため、ツール選定時には機能一覧だけでなく、開発元やプロジェクトの背景も含めて確認することが重要だと分かりました。

また、開発元の「国」にも注意を払う必要があることを学びました。 特に、脅威インテリジェンスと組み合わせて利用する場合には、

  • 特定の国や地域の法規制・政治状況
  • インフラやデータへのアクセス権限がどこに帰属するか

といった点によって、特定の国で開発された OSS を利用することがリスク要因となる可能性があります。 このため、ツールの技術的な機能だけでなく、地政学的・コンプライアンス上の観点からも慎重に評価する必要があると感じました。

第二に、生成された SBOM やツールの「使いやすさ」にも注意する必要がある、という点です。

今回の調査では、どのツールも CycloneDX 形式の SBOM を出力できる一方で、

  • OS パッケージがどこまで取得できるか
  • SrcName のような独自プロパティが出力されるか
  • CLI や Web UI でどこまで簡単に取得・確認できるか

といった「使いやすさ」の面で差があることが分かりました。

例えば ScanCode は、OS パッケージを含めた CycloneDX SBOM を生成できたものの、 SrcName に相当する情報は出力されず、そのままでは TrivyDB を使ったマッチング要件を満たせませんでした。 そのため、追加の変換や補完を行わない限り、SrcName ベースの検知漏れ対策には使いにくいという結果になりました。

このことから、「CycloneDX に対応しているか」だけで満足するのではなく、 生成された SBOM が自分たちの分析フロー（例：TrivyDB との連携、SrcName をキーにしたマッチング）に、どの程度そのまま載せられるかという「使いやすさ」も評価軸に含める必要があると分かりました。

まとめ

本記事では、インターンシップ2週目の内容にフォーカスしてご紹介しました。 単なる体験記にとどまらず、初めて読む方でも「SBOM とは何か」「インターンに参加することでどんな観点が身につくのか」が伝わるよう意識して執筆しました。

まず、1週目を担当してくださった NA4Sec の神田さん、益本さん、鮫嶋さん、本当にありがとうございました。「脅威インテリジェンスとは何か」という根本的な部分から、脅威調査・分析やフィッシングサイトの調査・分析に至るまで、幅広いテーマを深く学ばせていただきました。

2週目を担当してくださった Metemcyber の高橋さん、西野さん、志村さんにも感謝いたします。 インターン開始時点では、SBOM について正直ふんわりとした理解しかありませんでした。 しかし、3日間の調査や議論を通じて、SBOM の考え方だけでなく OSS 開発や脅威インテリジェンスを組み合わせたときの難しさや面白さも身をもって学べました。

言葉では言い尽くせないほど、多くの貴重な経験をさせていただき、本当にありがとうございました。

本文中でお名前を挙げきれませんでしたが、NA4Sec の皆さま、Metemcyber の皆さま、そして PJ は異なりますがOffensive Security PJ、OsecT Tech PJで関わってくださった皆さま、すべての方々に心より感謝申し上げます。

そして最後に、一緒にインターン生として、そして友人として関わってくれたみんなへ。 ここに書き切れないくらいの感謝の気持ちを込めて、本記事を締めくくりたいと思います。

参考文献

  1. インターンシップ体験記 〜Cobalt StrikeのC2サーバ追跡〜, https://engineers.ntt.com/entry/2023/03/24/081829 （閲覧日: 2025年11月28日）↩
  2. フィッシングキットの詳細分析に挑戦！（インターンシップ体験記）, https://engineers.ntt.com/entry/202410-summer-internship-phishing/entry（閲覧日: 2025年11月28日）↩