1. ソフトウェア構成分析とは？

ソフトウェア構成分析(Software Composition Analysis, SCA)は、コードベース内のサードパーティコンポーネントを特定し、それらの脆弱性やライセンス情報を検出・追跡する自動化されたプロセスを指します。

自社で開発するソフトウェア/調達するソフトウェアに既知の脆弱性があるコンポーネントが存在していないかや、ソースコードの公開に繋がるようなライセンス形態のコンポーネントが存在していないかなどを検査するために使用されます。最近の例だと、Log4ShellやSpring4Shellの脆弱性が存在するライブラリを使用してないかどうかを調査するのに役立ちます。

2. ソフトウェア構成分析のツール

NISTのRecommended Minimum Standards for Vendor or Developer Verification (Testing) of Software Under Executive Order (EO) 14028を参照すると、以下のようなソフトウェア構成分析ツール（以下、SCAツール）が紹介されています。なお、NISTは、これらのツールの使用を推奨していません（NISTが検証しお墨付きを与えているものではなく、こういうツールが世の中にはあるよ！的な…）。

Black Duck
Binary Analysis Tool (BAT)
Contrast Assess
FlexNet Code Insight
FOSSA
JFrog Xray
OWASP Dependency-Check
Snyk
Sonatype IQ Server
Veracode SCA
WhiteHat Sentinel SCA
WhiteSource Bolt

3. Dependency-Trackについて

前述のNISTでは紹介されていませんが、オープンソースのSCAツールとして、Dependency-Trackというものがあります。上述のDependency-Checkと名称が似ていますが、違うソフトウェアです（両方ともOWASPが絡んでいるのは共通ですが…）。

3.1. Dependency-Trackプロジェクトでの説明

組織がソフトウェアサプライチェーンのリスクを特定して削減できるようにするインテリジェントなコンポーネント分析プラットフォーム。
Apache 2.0ライセンス下で配布されるオープンソースソフトウェア。
下記の機能を持つ。
- 脆弱性の検出
  脆弱性インテリジェンスの複数のソースから、サードパーティおよびオープンソースコンポーネントの既知の脆弱性を特定。
- ポリシーによる評価
  個々のプロジェクトまたはポートフォリオ全体のセキュリティ、運用、およびライセンスポリシーのコンプライアンスを測定および実施。
- 影響分析
  脆弱なコンポーネントの影響を受けるプロジェクトで特定された脆弱性に迅速に対応。
- 時系列の指標
  ポートフォリオ内のすべてのプロジェクトとコンポーネントに対する継承リスクとポリシー違反の傾向の詳細を提供。
- 監査ワークフロー
  調査結果とポリシー違反を迅速にトリアージし、コメントと分析の決定を監査証跡に取り込む。
- 古いバージョンの検出
  プロジェクトの健全性とリスクに間接的に影響を与える、入手可能な最新のものではないコンポーネントを特定。
- フルスタックのインベントリ
  ライブラリ、フレームワーク、アプリケーション、コンテナ、オペレーティングシステム、ファームウェア、ハードウェア、およびサービスの使用状況を追跡。
- 部品表（Bill of Materials, BOM）
  オープンソースの業界標準であるCycloneDXソフトウェア部品表（SBOM）を取込、分析、および作成。
- 脆弱性の集約
  複数のアプリケーションリスクプラットフォームとのネイティブ統合により、優先順位の高い調査結果の統合ビューが組織に提供。
- エンタープライズ対応
  OpenID Connect（OIDC）を介したシングルサインオン（SSO）をサポートし、ActiveDirectoryおよびLDAP認証をサポート。
- APIと統合
  十分に文書化されたAPIファーストの設計は、他のシステムと簡単に統合でき、無限の可能性を提供。
- 通知
  Slack、Microsoft Teams、アウトバウンドWebhook、および電子メールに通知を送信し、新しいレベルのコラボレーションと自動化を可能に。

3.2. 導入方法

基本、Dockerコンテナを取得してデプロイするだけです。デフォルトでは、データ保存にH2 Databaseを使いますが、本格的に使う場合にはRDBMS（Microsoft SQL Server >= 2012, MySQL 5.6 and 5.7, PostgreSQL >= 9.0）を使用することが推奨されています。

curl -LO https://dependencytrack.org/docker-compose.yml
docker-compose up -d

なお、システム要件は以下のとおりです。参考になるか不明ですが、私は、ESXi上のUbuntu 20.04にRAM 6GB、CPU 2コアを割り当ててDockerコンテナを使用しています。

APIサーバ：【最低】RAM 4.5 GB, CPUコア数 2 /【推奨】RAM 16GB, CPUコア数 4
フロントエンドサーバ：【最低】RAM 512 MB, CPUコア数 1 /【推奨】RAM 1GB, CPUコア数 2

PostgreSQLのDockerコンテナの利用方法について

公式ページには利用方法について記載がなかったので、備忘録を兼ねて記載します。

(1) docker-compose.ymlへの追記

以下のようにservices:ブロック配下にPostgreSQLのコンテナ情報の追加します（postgres10: のブロック全体とdtrack-apiserver: の末尾）。データベースのユーザ名はdtrack決め打ちですが、パスワードは任意に設定できます。

docker-compose.yml

…（中略）…
services:
  postgres10:
    environment:
    - POSTGRES_USER=dtrack
    - POSTGRES_PASSWORD=password
    image: 'postgres:10.5'
    volumes:
    - './postgres-data:/var/lib/postgresql/data'
    restart: always
  dtrack-apiserver:
…（中略）…
    depends_on:
      - postgres10

また、元々コメントアウトされている以下の箇所（ALPINE_DATABASE_*）を有効にして適切な設定を入れます。

docker-compose.yml

  dtrack-apiserver:
    image: dependencytrack/apiserver
    environment:
    # The Dependency-Track container can be configured using any of the
    # available configuration properties defined in:
    # https://docs.dependencytrack.org/getting-started/configuration/
    # All properties are upper case with periods replaced by underscores.
    #
    # Database Properties
    - ALPINE_DATABASE_MODE=external
    - ALPINE_DATABASE_URL=jdbc:postgresql://postgres10:5432/dtrack
    - ALPINE_DATABASE_DRIVER=org.postgresql.Driver
    - ALPINE_DATABASE_USERNAME=dtrack
    - ALPINE_DATABASE_PASSWORD=password

(2) 起動

docker-compose up -d

3.3. 日本語化

Dependency-Trackは、2022年4月時点で表示言語は英語のみですが、Vue-I18Nによる多言語化の仕組みが準備されているので、日本語メッセージファイルを用意してビルドすることで表示言語を切り替えることが可能です。

【参考】以降の4.で入力する情報（プロジェクト名やポリシー名など）の日本語対応には、PostgreSQLの日本語対応が必要です。やり方は、Google検索すればわかると思います。

(1) ソースコードの取得

GitHubレポジトリからDependency-Track FrontEndのソースを取得します。

git clone https://github.com/DependencyTrack/frontend.git

(2) 日本語メッセージファイルの作成

取得したソースの src/i18n/locales 配下に en.json があるので、ja.jsonという名称でコピーします。

cp src/i18n/locales/en.json src/i18n/locales/ja.json

ja.json をエディタで開き、JSONの値を日本語に翻訳して置換します。書き方の例は以下のとおりです。

src/i18n/locales/ja.json

{
  "message": {
    "about": "Dependency Track について",
    "login": "ログイン",
    "login_desc": "あなたのアカウントへサインインします",

(3) 言語の切り替え

適切な実装方法か不明ですが、Webブラウザの言語（具体的にはaccept-languageヘッダの値）に応じて自動的に表示言語を切り替えるようにしました。この場合のソースコード変更箇所は、src/i18n/index.jsだけです。

src/i18n/index.js

# 変数i18nの定義をコメント化または削除
#const i18n = new VueI18n({
#  locale: process.env.VUE_APP_I18N_LOCALE || 'en',
#  fallbackLocale: process.env.VUE_APP_I18N_FALLBACK_LOCALE || 'en',
#  messages: loadLocaleMessages()
#});

# 関数detectBrowserLanguage()と変数i18nの定義を追記
function detectBrowserLanguage() {
  const lng = window.navigator.userLanguage || window.navigator.language;
  
  return lng;
}

const i18n = new VueI18n({
  locale: detectBrowserLanguage() || process.env.VUE_APP_I18N_LOCALE || 'en',
  fallbackLocale: process.env.VUE_APP_I18N_FALLBACK_LOCALE || 'en',
  messages: loadLocaleMessages()
});

export default i18n;

(4) ビルド

Dependency-Track FrontEndをビルドします。ビルド環境の整備方法は省きますが、NodeJS >= 12が必要です。

npm install
npm run build

成功すれば dist 以下にコンテンツが生成されます。最後に生成されたコンテンツを既存のコンテンツに上書きするのですが、dist/static/config.json だけは消しておきます（なお、ファイル内のAPI_BASE_URLの値を稼動環境の値に合わせるのであれば消す必要はありません）。

rm dist/static/config.json

(5) FrontEndのDockerコンテナへコピー

docker cpで(4)のコンテンツをFrontEndのDockerコンテナへ上書きコピーします。上書きコピーを永続的にしたい場合は、docker commitを実行します（dockerコマンドの詳細例は省略します）。

以上により、下の画像のように日本語表示可能となります。英語表示にしたい場合は、ブラウザの表示言語を英語にします。

参考までに、日本語化ファイルを私のGitHubレポジトリに置いておきました。

4. 簡単な使い方や注意点

v4.4.0について記載します。最新版では動作や仕様が異なる可能性がありますので、最新版利用時は公式の文書（Changelogなど）を参照してください。

4.1. 初回ログイン

公式ドキュメントを見ればわかりますが、導入直後に利用可能なクレデンシャルは以下のとおりです。ログイン成功後、初回はパスワード変更が強制されます。

username: admin
password: admin

4.2. 設定

早速ソフトウェア構成情報を登録したくなりますが、以下の設定については最初に変更しておいたほうが良いと思います。

(1) OSS Indexアナライザの設定

OSS Indexは、サードパーティコンポーネントの脆弱性を特定する Sonatype 社が提供するサービスです。ソフトウェアを構成するライブラリ等の脆弱性有無を検査する際に有用です。

Sonatype社のサイトで無料アカウントを登録してAPIトークンを取得後、Dependency-Trackの"Administration"→"Analyzers"→"Sonatype OSS Index"で登録したメールアドレスと取得したAPIトークンを設定します（"Enable OSS Index analyzer"を有効にすることも忘れずに）。

(2) GitHub Advisoriesの設定

GitHub アドバイザリーは、GitHub プロジェクトに固有の脆弱性インテリジェンスの一元化されたソースです。OSS Indexと同じくソフトウェアを構成するライブラリ等の脆弱性有無を検査する際に有用です。

GitHubのサイトで無料アカウントを登録してAPIトークンを取得後、Dependency-Trackの"Administration"→"Vulnerability Sources"→"GitHub Advisories"で取得したAPIトークンを設定します（"Enable GitHub Advisories Mirroring"を有効にすることも忘れずに）。

4.3. プロジェクトの作成

ソフトウェアごとの構成情報を登録するために、プロジェクト作成します。左端のアイコン群から"Projects"を選択します。
その後、"Create Project"ボタンをクリックします。"Create Project"というウィンドウが表示されるので、最低限以下を入力し、"Create"ボタンをクリックします。

Project Name・・・プロジェクト名。大抵はソフトウェア名を入れると思います。
Classifier・・・Application、Framework、Library等8個ほど選択肢があるので、一致するものまたは近いものを選択します。

すると、プロジェクト画面に上記で指定したProject Nameの行が追加されていることがわかります。

4.4. コンポーネントの登録

プロジェクト画面で、追加されたProject Nameのリンクをクリックすると、いくつかタブが表示されますが、ここでは"Components"タブをクリックします。
この画面からコンポーネント（ソフトウェア構成情報）を登録しますが、方法は以下の2つがあります。

"Add Component"ボタンから1個1個コンポーネントを入力する
"Upload BOM"ボタンからSBOMファイルをアップロードする

SBOMは、詳細は省略しますが、コンポーネントの名称やバージョン、ハッシュ値などを定義された形式で記載したファイルです。大統領令14028の流れでNTIAが提示した最小構成要素を満たすSBOMにSPDXやCycloneDX（書式はJSONやXMLなど）がありますが、単にSBOMといった場合にはファイル形式に特に指定はありません（CSVファイルでも良い）。
Dependency-Trackでは、CycloneDX（JSONまたはXML）のSBOMのみ対応しています（SPDXはかつてDependency-Trackでも対応していましたが、SPDX側のコードコピペ事案のOWASPによる対抗措置としてDependency-Trackから該当コードが削除されています）。

※なお、SBOMは商用製品やオープンソースツールで作成できます（参考URL：https://cyclonedx.org/tool-center/ ）。
※参考までに、フリーツールによるSBOM作成方法については、https://qiita.com/prt445/private/2ac7ef1b376c34bedf4a にてまとめつつあります。

4.5. 分析結果の確認

4.4.でコンポーネント情報を登録すると、追加されたProject Nameの画面が以下のように変わります。

"Projects"タブにコンポーネント数が表示され、クリックするとコンポーネント一覧が表示される
"Audit Vulnerabilities"タブに脆弱性件数が表示され、クリックするとコンポーネントに存在する脆弱性一覧が表示される

【参考】4.4.の登録情報（SBOMや手動入力）によっては、ライブラリのCPE情報が含まれていないことが原因で、脆弱性の検出件数が少なくなることがあります。4.4.の登録情時点か、ComponentのDetailsからCPE情報を登録するかのいずれかで、脆弱性が新たに検出され検知精度が上がる可能性があります。

4.6. ポリシーの設定

Dependency-Trackでは特定の条件に合致したものを個別に検出するポリシーを定義できます。例えば、「log4j-core < 2.17.1であれば重大アラートとして検知する」ということができます。

まず、"Policy Management"→"Policies"で"Create Policy"をクリックし、ポリシー名を入力して"Create"をクリックします。すると、空のポリシーが表示されるので、条件を入力します。以下は例です。

これで、条件に合致するコンポーネントがあれば、プロジェクト内で検出されます。具体的には、"Policy Violations"タブに違反件数が表示され、クリックするとポリシー違反一覧が表示されます。
ただし、注意点として、ポリシーによる評価は、ポリシー作成や更新時には実行されず、コンポーネント登録時または1日1回のバッチ処理でのみ実行されることに注意してください。

Dependency-Trackによるソフトウェア構成分析