Go to Qiita Advent Calendar 2024 Top
LoginSignup
4
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

NTTテクノクロスAdvent Calendar 2024

Day 11
@yuitomo

Docker Scoutでイメージ丸ごとのSBOMを作ってセキュリティ意識を高めよう

Last updated at Posted at 2024-12-10

1.はじめに

この記事はNTTテクノクロスAdvent Calendar 2024の11日目です。

こんにちは、NTTテクノクロスの広瀬です。
普段の業務では、医療機器ソフトウェアの開発や話題のLLMから生体信号・メディア処理、心理統計分析などを扱う組織のリードをしています。その他、セキュリティやネットワーク、総務系等データサイエンスを専門としない部署の方々にも分析技術を身に着けてもらうための社内研修講師などもしています。

さて、近年はソフトウェアの開発段階で悪意のあるプログラムを仕込む、「ソフトウェアサプライチェーン攻撃」 が増加しているようです1。
この攻撃は、OSSなどに不正コードを混入させることで開発工程を侵害し、ターゲットとなるユーザ企業に提供された後に侵入を試みるサプライチェーンに対する攻撃です。主な対策として、依存ライブラリの可視化や脆弱性の早期発見はもちろん、プロダクト初期の開発環境からリリース、運用環境に至るまで依存関係ライブラリ情報をトレースすることが極めて重要です。

この記事では、Docker Scout2を使ってDockerイメージのSBOMを生成し、どのようにしてセキュリティリスクを可視化し管理できるかを紹介します。

2.SBOMとは？

SBOM（Software Bill of Materials） とは、ソフトウェア構成部品表とも呼ばれ、ソフトウェアに含まれるすべてのコンポーネント、ライブラリ、依存関係をリストアップするものです。これにより、使用されているソフトウェアの全体像を明確にし、透明性を確保します。
経済産業省も導入の手引3を公開するなど、国を上げた推進もされているものとなっています。

たとえば、工場で生産される製品に必要な部品がリストアップされているのと同じイメージで、SBOMを使うことでソフトウェアの構成要素を把握できます。

2.1 SBOMがあると何が嬉しい？

1. セキュリティリスク発見の効率化・セキュリティ強化
SBOMを活用することで、どの依存ライブラリに脆弱性等の問題があるのかをすぐに特定し、早急に対応できます。開発初期からセキュリティリスクを効率的に発見し、ソフトウェアライフサイクル全体の安全性を高めることが可能です。

2. コンプライアンス管理の効率化
SBOMは、ソフトウェアが適切なライセンスのもとで使用されているか、あるいは規制に反していないかを確認するためにも使われます。これにより、法的なリスクや不適切なライセンス利用を防ぐことができ、コンプライアンス管理も効率化できます。

3. 透明性把握
ソフトウェアがどのような依存関係を持つのか、脆弱性はあるのか・把握できているのか、ライセンス上は問題ないか。こういった構成部品の情報を事細かに把握できているという状態は、すなわち透明性の高い状態であるといえます。サプライチェーン全体でSBOMを管理することで、開発者だけでなく、関係者全員がソフトウェアの安全性を意識できます。

このような理由から、セキュリティのだけでなくライフサイクルにおけるソフトウェアの構成管理や品質保証の観点でも重要となってきます。
また、SBOMは一度作成すれば終わりというものではありません。工程やバックログが完了したタイミングで作成する事で、意図しないライブラリのアップデートやそれに伴う脆弱性の混入が検知できるなど、継続的にソフトウェアの品質を高めることに寄与します。

3.Docker Scoutの概要とSBOM生成の手順

ここからは、実際にDocker Scoutについて簡単に触れてから、生成手順とどのようなものがSBOMとして出力されるのかを紹介します。

Docker Scoutは、Composeなどと同様CLI Pluginとして提供されている、コンテナイメージに対してSBOMを生成し、依存ライブラリの可視化とセキュリティリスクの評価を支援するツールです。開発者はイメージ内の依存関係を把握し、潜在的なセキュリティ問題に迅速に対応することが可能になります。

Dockerの公式プラグインであるため、Dockerワークフローに容易に統合でき、イメージのセキュリティ管理を効率的に行うことができるのでとても助かります。

3.1 Docker ScoutのセットアップとSBOM生成

前提条件

この手順は以下の環境で確認しています。

  • Ubuntu 24.04 LTS
  • Docker version 27.3.1, build ce12230

Docer Scoutの導入・SBOM作成手順

手順1. Docker Scoutのインストール

Docker Scoutのインストールは、インストールスクリプトが用意されています。ダウンロードのうえ実行するだけで簡単にインストールできます。

docker scoutのインストール
curl -fsSL https://raw.githubusercontent.com/docker/scout-cli/main/install.sh -o install-scout.sh
sh install-scout.sh

インストール後、バージョンを確認します。

インストール出来たかを確認
docker scout version
バージョン情報の出力結果
バージョン情報の出力結果
手順2. Dockerイメージの準備

DockerイメージのSBOMを作成するので、なにはなくともDockerイメージが必要です。
今回は、サンプルとして公式が公開している脆弱性を検知できるデモイメージをビルドして使っていきます。

もちろん、お手元にイメージがあればそちらをご利用いただくのもよいです。

デモ用イメージのビルド
git clone https://github.com/docker/scout-demo-service.git
cd ./scout-demo-service/
docker build -t scout-demo:v1 .
cd ../
手順3. SBOMの生成

いよいよ、Docker Scoutを使用してSBOMを生成します。
とはいえ以下のコマンドを実行するだけで、SBOMは作成できてしまいます。

sbom生成
docker scout sbom --format spdx --output scout-demo.spdx.json scout-demo:v1

docker scout sbomコマンドへ、出力フォーマットはSPDX、出力ファイル名はscout-demo.spdx.jsonを指定し、先ほどビルドしたscout-demo:v1イメージからSBOMを作成しています。

ここで出力フォーマットにSPDXを指定していますが、SPDX(System Package Data Exchange)4と呼ばれる、ソフトウェアライセンス情報を標準化して共有するための形式を提供するオープンな規格です。

手順4. 出力されたSBOMの確認

それでは、出力されたSBOMを実際に見てみましょう。
SPDXのドキュメント情報や生成日付に続いて、packagesには各パッケージのバージョン情報や、開発者情報、ライセンス情報などが記載されているのがわかると思います。

{
 "spdxVersion": "SPDX-2.3",
 "dataLicense": "CC0-1.0",
 "SPDXID": "SPDXRef-DOCUMENT",
 "name": "scout-demo",
 "documentNamespace": "https://docker.com/docker-scout/image/scout-demo-ca1a0a7c-4c12-4627-8cce-4a2fc3b106c6",
 "creationInfo": {
  "creators": [
   "Organization: Docker, Inc",
   "Tool: docker-scout-1.14.0"
  ],
  "created": "2024-10-31T00:58:03Z"
 },
 "packages": [
    {
   "name": "busybox",
   "SPDXID": "SPDXRef-Package-e3f45db017d771221d305975eeb43be9",
   "versionInfo": "1.33.1-r3",
   "supplier": "Person: Natanael Copa <ncopa@alpinelinux.org>",
   "originator": "Person: Natanael Copa <ncopa@alpinelinux.org>",
   "downloadLocation": "https://busybox.net/",
   "filesAnalyzed": false,
   "licenseConcluded": "NOASSERTION",
   "licenseDeclared": "GPL-2.0-only",
   "description": "Size optimized toolbox of many common UNIX utilities",
   "externalRefs": [
    {
     "referenceCategory": "PACKAGE-MANAGER",
     "referenceType": "purl",
     "referenceLocator": "pkg:apk/alpine/busybox@1.33.1-r3?os_name=alpine&os_version=3.14"
    }
   ]
  },
  ...以下略

4. OSV Scannerを利用してSBOMから脆弱性情報を入手する

OSV Scanner5は、Go言語で実装されたGoogleが提供するオープンソースの脆弱性スキャナーで、SBOMなどの依存関係ファイルを解析し、それらに含まれる既知の脆弱性を検出するためのツールです。このツールは、オープンソース脆弱性（Open Source Vulnerabilities）データベースを参照しており、ソフトウェアの依存関係に関する最新の脆弱性情報を提供します。

Docker ScoutにもImageの脆弱性情報をスキャンする機能が備わっているようですが、Docker Desktopの有償ライセンスに紐づく付帯機能67 として提供されるもののようですので、今回は取り扱いません。

  • トレーサビリティの観点で、出力しておいた過去のSBOM情報と照らし合わせたい
  • GitHub Actionsでの自動化のために専用ツール化されてると取り回しが楽

など、独立したツールである利点もあるので、今回はOSV Svannerを使っていきます。

4.1. OSV Scannerのインストール方法

公式インストール手順がさまざま提供されていますが、執筆時点でv2のリリースが間近だというアナウンスがでていたので、最新版のバイナリをダウンロードすることにしています。

osv scannerのインストール
$ sudo wget -qO /usr/local/bin/osv-scanner https://github.com/google/osv-scanner/releases/latest/download/osv-scanner_linux_amd64
$ sudo chmod a+x /usr/local/bin/osv-scanner
$ osv-scanner --version

> osv-scanner version: 1.9.1
> commit: b13f37e1a1e4cb98556c1d34cd3256a876929be1
> built at: 2024-10-30T23:38:00Z

4.2. OSV Scannerを使用した脆弱性情報の出力

生成したSBOMファイルを使用して、OSV Scannerで脆弱性を確認します。以下のコマンドを使用して、SBOMファイルを入力として脆弱性情報を出力します。

osv-scanner --sbom=scout-demo.spdx.json

このコマンドを実行すると、SBOMに記載されている依存関係に対する既知の脆弱性がリストアップされます。
どのバージョンのどのパッケージがどの脆弱性があるか、OSVのURLと共に表示されます。

URLの先で詳細な脆弱性情報を確認することが出来、試しに表示させてみたものはDoS攻撃の踏み台となるかもしれないという脆弱性でした。

OSV Scannerの実行結果
OSV Scannerの実行結果
出力されたリンク先で表示されるOSV情報

5. まとめ

Docker Scoutを使うことでSBOMを作成し、セキュリティリスクを可視化する重要性とその手順を紹介してきました。SBOMの導入は、依存関係の透明性を高め、リスクの早期発見と管理を容易にし、最終的なプロダクトの品質向上に寄与するものとなります。そういった意味でも、プロジェクトの初期から作っておくのが望ましいですが、手遅れということはありませんので、これをきっかけに早速導入することを強くオススメします。

今回は脆弱性情報を参照しただけですが、

  • SBOMそのものに改ざん防止の仕組みを取り入れる
  • CI/CDに脆弱性情報出力を組み込んで監視する
  • プロダクトのSBOMをCIRTと共有してアライアンス体制を構築

など、活用のためには、体制を整えセキュリティへの意識を組織として高めていく取り組みも重要となってきます。

自分たちのプロダクトの価値と品質向上のため、DockerイメージのSBOM作成から始めてみるのはいかがでしょうか。

明日は@akinori-oが多変量解析手法の1つである重回帰分析について記事を書いてくれるようです。
NTTテクノクロスアドベントカレンダー引き続きお楽しみください！

  1. IPA 独立行政法人情報処理推進機構, 情報セキュリティ10大脅威 2024 ↩

  2. docker docs, Docker Scout ↩

  3. 経済産業省, ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引ver2.0概要資料 ↩

  4. The Linux Foundation Projects, System Package Data Exchange (SPDX®) ↩

  5. Open Source Vulnerabilities, osv-scanner ↩

  6. Docker Subscription Service Agreement ↩

  7. Docker Core Subscriptions ↩

4
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
4
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?