構成管理（SBOMとかソフトウェアサプライチェーンとかその辺）の話
構成管理とは
システムやソフトウェアの構成情報を管理すること
（筆者の造語です）
背景
米国の話
サイバー攻撃が激化している
ソフトウェアがどういうコンポーネントから構成されているかを把握することが重要
サイバー攻撃≒脆弱性であり、脆弱性とはソフトウェアコンポーネントの不具合を突くもの
サイバー攻撃に備える≒脆弱性を把握して未然に潰す
脆弱性を把握する≒ソフトウェアコンポーネントを把握する
歴史的にはまだまだ始まったばかり
2021年に米国政府が取り上げたことで活発化
日本国内でもキャッチアップする動きがある
まだ業界レベルでルールが定まったり、デファクトスタンダードのツールが出たりしているわけではない
が、既に各社各組織各業界が製品つくったり規格考えたりガイドライン整備したりとかしている
従来のセキュリティ企業や大手ベンダー達も一枚噛もうとしている
いわゆるブルーオーシャン状態
SBOMとかソフトウェアサプライチェーンとか
ソフトウェアはnのコンポーネントから構成されている、と考える
たとえばXというソフトウェアがPython 3.8とrequsts 2.21を使っている場合、XのコンポーネントはPython3.8とrequests2.21
これを表現する方式の一つがSBOM
Software Bill Of Materials
直訳すると「ソフトウェア部品表」
部品表としてこれこれの情報を含めるべきだ的なことを記したガイドライン
SBOMはただのガイドラインであり、具体的な実装はいくつかある
SPDX
CycloneDX
関連する概念として、ソフトウェア開発の各フェーズでコンポーネント一覧をちゃんとつくりましょう、管理しましょう、準拠しましょうというものがある
ソフトウェアサプライチェーンと呼ばれる
サプライチェーンの考え方をソフトウェアにも当てはめた
サプライチェーンは製品の原材料調達から販売までの全プロセス全フローを追いかけて管理するものだが、これをソフトウェアでもやる
≒各フェーズで構成物（コンポーネント）を把握しろ
≒次のフェーズではそのとおりにつくれ
たとえば設計フェーズで「これこれを使います」を確定させた後、実装フェーズではそのとおりに使う（ちゃんと使われてるか検査するのもアリ）
そのためには以下が必要
コンポーネントを記述するフォーマットやファイル形式
SBOMはここで役に立つ
それを読み書きする処理
それに基づいて検査を行うプログラム
これらがあれば、たとえばCI/CDに差し込んで自動で生成＆検証といったこともできるようになる
既にunittestやformatterやlinterといった処理は当たり前に使われているが、ここに「構成情報の生成」「生成した構成情報を用いた検証」も追加されるイメージ
コンポーネントと脆弱性
コンポーネントとは、あるソフトウェアのあるバージョンを示す単位
つまり名前とバージョンの組
ただし文脈によっては名前だけを指すこともある
脆弱性とは、コンポーネントが持つセキュリティ上の不備
脆弱性は特定の組織が収集・管理・共有している
基本的にはCVEに集まる
個別製品中の脆弱性を対象として、米国政府の支援を受けた非営利団体のMITRE社(*2)が採番している識別子です。脆弱性検査ツールや脆弱性対策情報提供サービスの多くがCVEを利用しています。
Black Duck(Sysnopsis社)はCVE以上に豊富なデータベースを持っている
自社製品の脆弱性を内密に管理している組織もあるだろう
階層関係で示す
ソフトウェア
コンポーネント
脆弱性
脆弱性各々に対してどう対処するかは腕の見せ所
数が多いので全部潰すのは非現実的
CriticalやHighなどヤバいものを優先的に潰すとか
影響が限定的だったり、今回の使い方なら攻撃にはつながらないなーとかいった場合はあえて放置するとか
上手く対処すればよろし
構成管理の対象はソフトウェアだけなのか
米国発で盛り上がっている概念は「ソフトウェア」のみが対象になっているきらいがある
一方で、現実にはソフトウェアの他に「システム」もある
ソフトウェアとは開発成果物であり、運用はしていない
システムとはプラットフォーム、ソフトウェア、その他デバイスを用いたものであり、運用されている
例
1 Xというビジネスチャットソフトウェア
2 Xのfrontend
3 Xのbackend
4 Xを動かしている自社のAWS
5 Xを動かしている顧客CのAzure
「ソフトウェア」は1のこと
さらに2や3に分かれていたりする
「システム」は4や5のこと
他にも、
オンプレで動かしてるY、ローカルのDockerで動かしてるコンテナZなど色々ありえる
2台で冗長化している場合は2台とも構成管理の対象になりえる etc
要するに実際に動かしているものは何でもシステム
SBOMやソフトウェアサプライチェーンは「ソフトウェア」を扱ったもの
「システム」を扱った概念や規格は無い
あったら教えてほしいです……sta.icon
大手SIerなどは既に自社で独自に取り組んでいると思いますが
以下は技術的な話
構成情報を取得する方法
ディレクトリをスキャンする
package.json や requirements.txt などのパッケージ管理用ファイル
node_modules/ や site-packages/ などのパッケージ保存先ディレクトリ
dockerfile など仮想環境用の設定ファイル
ファイルをスキャンする
ファイル名
ソースコードの中身
OSのパッケージ管理をスキャンする
Windowsだとappwiz.cpl（内部的にはレジストリ）、UNIX系だとrpm、apk、pacmanなど
以下はまだ見たことがない or sta.iconが考える「こういうのもありえるんじゃない？」
環境変数をスキャンする
ネットワーク機器をスキャンする（LDAPなどのプロトコルを使う？）
バイナリの中身をスキャンする（リバースエンジニアリング？）
READMEなどドキュメントをスキャンする
取得した構成情報を集める方法
エージェント（をインストールさせてバックグラウンドでアップロード）
リポジトリに配置（したのを収集したい側が拝借）
webhookなどでイベントドリブンに連携するのもありえる
取得した者が手作業でアップロード
コンポーネントの種類
1 OSSコンポーネント
2 有償製品（非OSS）コンポーネント
3 自社製品コンポーネント
---
Black Duckが扱うのは1のみ
CVEの脆弱性には2も含んでいることがある
3については各社内部で独自に扱っているだろう
（3は厳密には1か2に属するためここで同列に扱うのは違うのだが、自社製品だけ扱うというシチュはよくあるのであえて同列にしてみている）
表記ゆれ問題
構成管理は「≒ソフトウェア名の管理」とも言える
ここで問題となるのが「名前の表記が微妙に違うと、管理上同じものとして扱えない」問題
表記ゆれと呼ぶことにしたい
例1
自社の構成管理システム上ではPython 3.9が正しい書き方
でも利用者が「Python3.9」とスペース無しで登録してしまったとする
システムには「Python 3.9」と「Python3.9」が両方登録されてしまう
例2
自社の構成管理システム上でPython3.9を登録している
これの脆弱性情報を引っ張ってきたい
CVEのデータベースから引っ張ってこよう
このとき、CVEで記述された名前でないと引っ張ってこれない
プロジェクトやシステムという概念
構成管理を行う際、おそらくプロジェクトなる上位概念（あるいは「組織」かもしれない）が必要になる
プロジェクト
ソフトウェア
コンポーネント
前述したが、構成管理の対象としては「システム」もあった
プロジェクト
ソフトウェアorシステム
コンポーネント
システムの場合、もう一段階ほど概念が必要と思われる（オンプレ用語でいういわゆる「サーバー」的なもの）
プロジェクト
システム
インスタンス
コンポーネント
「構成管理」と「構成管理情報から行える管理」の棲み分け
構成管理とは、純粋に構成情報を管理すること
一方で、構成管理の情報を用いて行える管理が色々ある
例
脆弱性
ライセンス（ライセンス違反など）
運用リスク（長らく更新されてないOSSを使ってますねとか）
署名（たとえば出力したSBOMデータにデジタル署名つけるとか、改ざんできないようPDF+電子サインの人間用フォーマットで出すとか）
構成管理を行うシステムやツールをつくる場合、この棲み分けをどこまでやるかを考える必要がある
全部いっしょくたにしてしまうのか
「構成管理層」と「サービス層」みたいにレイヤーを分けて、脆弱性などは後者（前者をAPIサーバーにしてやりとりする等）でやるのか
リンク集
SBOM（のベースライン属性）
SPDX
CycloneDX
パッケージ管理系
winget:
VEX
SBOMと脆弱性を関連付けるフォーマット的なもの
具体的な実装は別途ある（例: CSAF）