公開：
サイバー攻撃に対する“漠然とした不安”から解放されるために | 金融機関におけるSBOM活用の重要性
悪意のある第三者の攻撃から自社のシステムや顧客の財産を守るためには、自社プロダクトに脆弱性のあるコンポーネントが含まれていないかを常に把握しておくことが不可欠です。
しかし現実には、開発・運用をベンダーに委託しているため「自社システムの中身（詳細な構成）が正確にわからない」という金融機関も少なくないのではないでしょうか。
そこで注目されているのが、金融庁のガイドラインでも活用が推奨されているソフトウェア部品表「SBOM（Software Bill of Materials）」です。
本記事では、金融システムにおけるOSS利用のリスクを整理し、SBOMの導入が金融機関の信頼性向上にどのような効果をもたらすかを解説します。
目次
金融庁が活用を推進する「SBOM」とは
SBOM（Software Bill of Materials）とは、ソフトウェアに含まれるすべてのコンポーネント（構成部品）やそれらの依存関係、ライセンス情報などをリスト化した部品表のことです。多くの企業が備えているハードウェアやネットワークの資産台帳に対応する、「ソフトウェアの資産台帳」として機能します。
近年のソフトウェア開発では、第三者によって作られ、誰でも自由に利用できるプログラムであるOSS（オープンソースソフトウェア）の活用が一般的になりました。これにより、開発コストを抑えつつ高度な機能を実現できるようになった一方、OSSに脆弱性が発見された場合、それを組み込んでいる無数のシステムが一斉にサイバー攻撃のリスクにさらされることになります。
2021年に報道された、Javaアプリケーションで広く使われるOSS「Log4j」の脆弱性（通称「Log4Shell」）では、世界中のシステムが対応に追われました。
こうした事態を受け、日本でも金融庁が2024年10月に策定した「金融分野におけるサイバーセキュリティに関するガイドライン」において、自社ソフトや利用サービスにおけるSBOMの整備が望ましいと明記されています。
金融システムとOSS
OSSのリスクを耳にしても、「基幹システムが中心の自分たちには無関係ではないか」と考える方もいるかもしれません。
しかし、現在の金融システムとOSSは切っても切れない関係にあります。
金融システムで広がるOSS活用
かつて金融機関のメインフレーム領域は商用ソフトウェアが中心でしたが、近年のクラウド普及に伴いOSSの活用が急増しています。特にインターネットバンキングやモバイルアプリといった顧客向けサービスでは、OSSの利用が前提となっています。
例えば「PDFを出力する」といった単純な機能1つのために、有償のツールでコストが見合わずOSSライブラリを使うケースもあります。どのようなシステムでも、完全にOSSを使っていないと断言するのは難しいのが近年のソフトウェア運用の状況です。
受託開発ゆえの「ブラックボックス化」
金融機関ではシステムの開発・運用を外部ベンダーに委託することが多いため、自社システムの中身が詳細まで把握できていないケースが珍しくありません。
しかし、ひとたびインシデントが発生すれば、最終的な結果責任を負うのは金融機関自身です。サービス停止による顧客の信頼失墜は、ベンダーへの損害賠償だけでは補いきれません。実作業は委託するとしても、金融機関が主体となってベンダーと協業し、中身を可視化しておく責任があるのです。
SBOM導入で期待できる効果
OSSの利用が一般的になるなか、SBOMによるシステム構成の把握は「サイバー攻撃への有効な対抗手段」として注目されています。
具体的にどのような効果があるのか見ていきましょう。
影響調査にかかる労力を軽減できる
システム構成が可視化されていない場合、新たな脆弱性が発表されるたびに「そのOSSが自社システムのどこに使われているか」の調査から始めなければならず、膨大な時間と労力がかかります。
実際に、先に紹介した「Log4Shell」の事例では、自社システムへの影響を即座に判断できない企業が多く、混乱が生じました。また、金融系を含めて多くの企業は「リスクのあるコンポーネントを使っているかわからない」という曖昧な状態が続いたまま、調査に膨大なリソースを費やすことになりました。
SBOMを用いてシステムの全体像を可視化すれば、重大な脆弱性情報が確認された際にも、脆弱性情報と照合するだけで「自社への影響の有無」を即座に判定でき、迅速な対策が可能になります。
公表直後の「即日攻撃」を防止できる（ゼロデイ攻撃対策）
脆弱性が公表されると、攻撃者は即座に「エクスプロイト（脆弱性を悪用した攻撃プログラム）」を仕掛けてきます。影響調査に数日かけている間に攻撃を受ける可能性は低くありません。
実際に、Log4Shellの事例では、「フォームに特定の文字列を入力するだけで攻撃されうる」という状況のなか、多くの企業がその事実に気づかないまま情報を盗まれた可能性があったことから、深刻な被害が懸念されました。
このような「簡単に狙われて、致命的なインシデントを起こす脆弱性」がいつ発生するともわからない状況下で被害を最小限に抑えるには、発見から対策までのタイムラグを極限まで短縮できる体制が不可欠です。
当局や社会への「説明責任」を果たせる
万が一インシデントが発生した際、「ガイドラインに沿ってSBOMで管理していたが、不測の事態が起きた」場合と「システムの中身を把握していなかった」場合では、社会的な評価が大きく異なります。
前者であれば「次にどう対処するか」をスムーズに発表できるのに対し、後者の場合、対外的には「これから原因を調べます」と説明せざるを得ず、対応が後手に回ることで被害の拡大やサービス停止期間の長期化にもつながります。
日ごろから備えがあることで、攻撃を受けたときの被害を抑えられるだけでなく「セキュリティ対策のためにベストを尽くしている」という信頼性にもつながるのです。
SBOM運用を成功させる組織体制のポイント
SBOMの活用にあたっては、専用のツールの導入と合わせてセキュリティ対策の組織体制を整備する必要があります。
最後に、SBOMを用いて脆弱性に対応していくためのポイントを解説します。
脆弱性への対応フローを規定する
SBOMを用いて脆弱性に対応していくにあたっては、リスクが明らかになったときの対応フローを事前に定めておくことが欠かせません。
このプロセスは、災害発生時にシステムを復旧・継続させるための「ディザスターリカバリー」（DR）の取り組みと同じように考えられます。Log4Shellのような脅威度の高い脆弱性は、災害のように突然やってくるものであるため、有事の際に迷わず動けるための備えが、いざというときのシステムの継続性・安全性を左右するといえます。
具体的には、「CVSSスコアがXX以上の脆弱性が発見されたら、○時間以内にセキュリティ担当が影響調査を開始し、○時間以内に経営判断を行う」といったかたちで、具体的な行動に落とし込んだ運用フローをベンダーと合意しておくとよいでしょう。
必要なリスクにだけ対応する
システム内部のリスクが発覚した際に「とりあえずサービスを停止する」という選択肢が取れない金融システムでは、検出された脆弱性を取捨選択して対応する必要があります。
国際的に権威のある脆弱性データベースでは、日々数十件から数百件の脆弱性情報が更新されることもあり、SBOM管理ツールを導入すれば、日常的に大量のアラートが表示されるでしょう。しかし、実際には「アラートが表示されたものの、自分たちのシステムで緊急のリスクはない」といったケースも少なくありません。
優先度の低い脆弱性対応まですべてを会議にかけることは現実的ではないため、ベンダーと協力して対応すべき脆弱性を絞っていく必要があります。
運用の文脈を踏まえて対応策を考える
脆弱性の取捨選択に加え、具体的な「対応策の選定」も重要です。
例えばログイン機能に脆弱性が見つかった際、単にパッチを当てるだけでなく「修正完了まで機能を一時停止するのか」「ほかのセキュリティ製品の設定変更で当面をしのぐのか」といった判断が求められます。
こうした意思決定は、技術的な観点だけでなく、金融実務や顧客への影響といった「運用の文脈」を考慮して下さなければなりません。技術的な観点と運用状況の両面から最適な意思決定を下すためには、ベンダーだけでなく金融機関もセキュリティに対する理解を深め、有事の際の円滑な議論につなげていく必要があります。
脆弱性を“正しく恐れる”ために
顧客の財産を預かる金融機関のシステムでは、脆弱性に対する入念な対策が求められます。セキュリティ担当者は、日々いつ発生するかわからないインシデントのことを考えて漠然とした不安を抱えているかもしれません。
SBOMでソフトウェアの部品表を可視化すれば、重大な脆弱性が発見されたときに、システムへの影響を即座に把握できる状態が実現します。それによって被害の最小化につながるとともに、対応すべき脆弱性を取捨選択してリソースの浪費を回避できるようにもなります。
AGESTの提供するSBOM管理ツール「SBOM Archi」は、重大インシデントが発生した場合に、システムへの影響を継続的に追跡できる機能や、複数の指標を併用した自動トリアージを実装しています。国産ツールならではの日本語での充実したサポート体制を備え、初めてSBOMを導入する機関から本格的な運用体制の構築を目指す機関まで、幅広くご支援します。
SBOMの導入・運用に課題をお持ちの方は、ぜひ一度ご相談ください。
