SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

Developers Summit 2022 Summer レポート(AD)

SBOMの脆弱性管理がもたらす品質とスピード向上でDevSecOpsを進めよう【デブサミ2022夏】

【D-6】「サプライチェーン攻撃」に立ち向かう!SBOMを使った脆弱性管理がもたらす品質とスピード向上

  • X ポスト
  • このエントリーをはてなブックマークに追加

 テーマはSBOM。最近ではカンファレンスのキーワードで扱われる機会が増えてきている。JFrog Japan デベロッパーアドボケイト 横田紋奈氏は顧客からの問い合わせが増えているのを感じているという。「こういうのは浸透するまで時間もエネルギーもかかります。前回のデブサミでも取りあげましたが『この人しつこいな』と思われるまでやっていきます!」と元気にDevSecOpsの重要性について解説した。

  • X ポスト
  • このエントリーをはてなブックマークに追加

(上)JFrog Japan株式会社 デベロッパーアドボケイト Java女子部 JJUG 横田紋奈氏、(下)JFrog Japan株式会社 デベロッパー・アドボケイト 佐藤由久氏
(上)JFrog Japan株式会社 デベロッパーアドボケイト Java女子部 JJUG 横田紋奈氏、(下)JFrog Japan株式会社 デベロッパー・アドボケイト 佐藤由久氏

ソフトウェアの推移的依存関係をどこまで把握できるか?

 まずはソフトウェアのサプライチェーンについて考えてみよう。簡単に言えば、ソフトウェアが本番環境にデプロイされ、ユーザーの元へ届くまでの一連の流れを指す。物流のサプライチェーンを想像してみると分かりやすい。原料が工場に届き、加工され、別の工場に移送されて別の加工が施され……最終的には消費者の元へと届けられる。そうした供給の一連の流れだ。

 一方、ソフトウェアのサプライチェーンの流れを見ると、コードには外部ライブラリ(主にOSS)が多く組み込まれている。つまりソースコードは何らかのOSSに依存し、そのOSSはまた別のOSSに依存し、それが何重にも連鎖したものとなっている。悪意あるコードやパッケージを潜ませることをソフトウェアのサプライチェーン攻撃と言う。

 開発から本番環境までのサプライチェーン全体に良くないものが混入していないかをチェックするフレームワークにSLSAがある(元々はGoogle社内で使われていたもの)。ソースコードに脆弱性などが混入するポイントには多数ある。例えばソースコードは外部から攻撃されるようなリポジトリに置かれていないか、ビルドされたソースコードが後から改ざんされていないかなど。ソフトウェア開発ではサプライチェーン全体を見て、脆弱性を割り込ませる隙を作らないようにする必要がある。それがサプライチェーン攻撃の防止策となる。

さまざまなフェーズに潜む脅威
さまざまなフェーズに潜む脅威

 どのくらいの脅威があるのかを数字で見ていこう。JFrog Japanの横田氏は自身の調査結果として「ソフトウェアの99%、エンタープライズ向けソフトウェアなら85%にオープンソースのコンポーネントが含まれます。昨今生じている攻撃の62%がサプライヤーの信頼を悪用したものとなり、2015〜2021年で6.5倍に増加しました。2022年にはさらに4倍に増加すると予想されています」とまとめた。

 直近で印象的な事例がLog4Shellだ。2021年末にJavaでよく使われるロギングのライブラリに致命的な脆弱性が含まれていたことが発覚し、問題となった。クリスマス前後で対応に追われた人もいるだろう。

 繰り返しになるが、ソフトウェアの依存関係は深く連鎖している。推移的依存関係とも言われる。多くのプログラマが自分のコードや自分が参照したコードであれば、目が届く。しかし遠い依存先までは把握するのは難しい。

 横田氏は「身近なところならパッケージマネージャを定義しているファイルがあります。そこにあるのが皆さんが直接使うOSSです。そこに書かれているOSSがさらに何を使っているかを対策していかないと、完全なセキュリティ対策ができているとは言えないのです」と指摘する。

推移的依存関係
推移的依存関係

SBOMで抑えるべきポイント3つを詳しく解説

 こうしたソフトウェアのサプライチェーンに潜む脅威にどう対策するか。ひとつの答えが「SBOMを作る」こと。もちろん、これだけで全て解決するわけではないが、重要な柱となるのは確かだ。

 あらためてSBOMとは「Software Bill Of Materials」の略であり「ソフトウェア部品表」と訳されることもある。食品なら食品成分表をイメージするといいだろう。ソフトウェアを構成するコンポーネントとメタデータの一覧となる。脆弱性やライセンスの観点で安全性を確認する、あるいは保証するのに使われる。

 アメリカでは政府と関わる重要なソフトウェアではSBOMが義務化されるほど、ソフトウェア開発ではメジャーなものとなりつつある。日本では自動車業界や医療業界でも徐々に浸透してきている。

 SBOMに記載するコンポーネントは、ソフトウェアが依存または使用するOSSやサードパーティーのライブラリ、ソフトウェアが使うアドオン、プラグイン、拡張機能、プロプライエタリなコード、SaaSの場合はAPIやサードパーティーのサービスに関する情報を含んでもよい。プログラムで使うものは全て網羅すると考えていいだろう。SBOMで抑えるべきポイントは次の3つ。

(1)Data Fields

 SBOMに記録する情報で、大きく分けてSBOMそのものの情報とソフトウェアの情報となる。前者はこのSBOMが用いているフォーマット、作成者、作成時のタイムスタンプで、後者はコンポーネント(パッケージ)の名前、識別用のキー、バージョン、サプライヤ、そして大事な依存関係だ。依存するものを記載していく。

SBOMに記載するもの
SBOMに記載するもの

(2)Automation Support

 SBOMの生成や利用を自動化しやすくするための配慮。SBOMのフォーマットは標準的なものに則り生成すること。最近SPDX(Software Package Data Exchange)が国際標準となったが、他にもSWID(Software Identification)やCycloneDXも有名だ。できれば一貫して同じフォーマットで管理したほうがいいだろう。なおSPDXはコロンでタグと値を区切るタグバリュー(tag:value)形式で、他にもJSON、YAML、XMLなどにも対応している。

 SBOMに関するツールは大きく分けて生成のためのツール、使用(消費:consume)のためのツール、変換のためのツールがある。生成のツールは自動または手動でSBOMを生成する。自動ならビルド時に生成するといいだろう。使用のためのツールは人間が分かりやすい形で表示するためのもので、SBOMとSBOMを比較するなどSBOMを読み込んで活用する。変換のツールは別のフォーマットに変換したり、複数のSBOMを統合したりする。横田氏によると多くが発展途上でデファクトスタンダードと呼べるツールはまだないとのこと。

(3)Practices and Processes

 SBOMは作るだけではなく、活用方法や運用方法も定義しておく必要がある。例えばSBOMを作成する頻度やタイミングならビルドやリリース時にSBOMを新規作成するとか、SBOMを修正するタイミングなど。また推移的依存関係をどれだけ深く含めるかも大事なポイントとなる。横田氏は「悪意あるパッケージが“ない”ことを証明するには完全な網羅性が必要となります。なるべく深いところまで完全に書ききれるようなツールを使うのが大事なポイントです」と強調する。依存関係で不明なところがあれば、不明な箇所を「既知の未知」として明記しておく。

 他にも必要とする人が適切なタイミングで使用できるようにする、要件に応じたアクセス制御を定めておく(ライセンスや契約などで定めておく)なども念頭においておこう。なおサプライチェーンのリスク管理は発展途上なので課題や変化には寛容でいるといいだろう。大事なのは「成熟を待つより、今日から始めること」と横田氏は言う。

次のページ
SBOMを始めるならSCAも知り、DevSecOpsへと歩みを進めよう

関連リンク

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
Developers Summit 2022 Summer レポート連載記事一覧

もっと読む

この記事の著者

加山 恵美(カヤマ エミ)

フリーランスライター。茨城大学理学部卒。金融機関のシステム子会社でシステムエンジニアを経験した後にIT系のライターとして独立。エンジニア視点で記事を提供していきたい。EnterpriseZine/DB Onlineの取材・記事や、EnterpriseZine/Security Onlineキュレーターも担当しています。Webサイト:http://emiekayama.net

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/16306 2022/09/16 12:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング