- 目次
1.昨今のソフトウェアサプライチェーンセキュリティガイドライン策定の動向
昨今のサプライチェーン攻撃の増大を受けて、2021年には米国大統領令にてサイバーセキュリティ強化が発出され、米国、欧州をはじめ日本でも各種ガイドラインの策定が進められています。
最近では、2023年7月に経済作業省にて「ソフトウェア管理に向けたSBOM(Software Bill of Materials)の導入に関する手引」が策定され、ソフトウェアサプライチェーンセキュリティおよびSBOMへの注目度は、益々上がっております。
本稿では2024年におけるNTT DATAの取り組み状況をご紹介したうえで、これら取り組みを実際に開発・運用サイクルに適用するノウハウについてご紹介します。
2.SSDFとは
先にご紹介した米国大統領令を受けて、サプライチェーンセキュリティの対策のために、NIST SSDF(SP800-218)の手法を実装することが求められています。
SSDFには、大きく以下の4つの分類があります。
表1:SSDFの分類
分類 |
---|
1.組織の準備(PO):組織は、組織レベルで安全なソフトウェア開発を行うために、人材、プロセス、技術を準備する必要がある。多くの組織は、個々の開発グループやプロジェクトなど、ソフトウェア開発のサブセットにも適用可能なPOプラクティスがあると考える。 |
2.ソフトウェアの保護(PS):組織は、ソフトウェアのすべてのコンポーネントを、改ざんや不正アクセスから保護する。 |
3.安全なソフトウェアの作成(PW):組織は、リリースされるソフトウェアのセキュリティ脆弱性を最小限に抑え、十分なセキュリティを備えたソフトウェアを製造すべきである。 |
4.脆弱性への対応(RV):組織は、リリースするソフトウェアに残存する脆弱性を特定し、適切に対応する。 |
SBOMの活用はこのうちの主に4.脆弱性への対応(RV)に該当する対策となりますが、このほかにも組織の準備(PO)、ソフトウェアの保護(PS)、安全なソフトウェアの作成(PW)があります。特にPWは後述するIAST,SAST等のツールの適用や自動化を推進することで対応が期待できる領域であり、DevSecOpsとも深い関係があります。
3.NTT DATAのソフトウェアサプライチェーンリスク低減に向けての取り組みと難しさ
NTT DATAでは、「作る」「集める」「使う」の3観点で、SBOM統合管理のToBe像を策定し、実際の社内のシステム開発・運用の状況と照らし合わせてAs/Isのギャップを課題として抽出しています。各課題の解決に向け、社内PoCを通じてブラッシュアップすることで、実際のシステムの開発・運用と親和性の高いSBOM統合管理のソリューションの策定を進めています。
図1:社内でのSBOM統合管理の実現に向けて
また、海外グループ会社と連携し、お客様のサプライチェーンセキュリティを包括的に保護するマネージドサービスを開発しています。サービスメニューの1つとして、お客様アプリケーションのSBOMを生成し、生成したSBOMを管理し、SBOMから脆弱性を検出し、その対応状況を管理するサービスを今後海外から順次提供開始の予定です。
図2:サプライチェーンセキュリティ保護サービスの概要
脆弱性の報告件数、サプライチェーン攻撃の件数は急激な増加を見せており、安全性に関する社会的要求は高度になる一方です。
SBOMを使う段階では、脆弱性の管理とその対策を行う必要があります。脆弱性管理は一度実施したら完了というものではなく、日々世界で更新される脆弱性をキャッチし、それらの脆弱性に対応をしなければなりません。ソフトウェアサプライチェーンセキュリティ対策を実施する際に効率的なツールの運用ができない場合、開発のアジリティを落としてしまう、または形骸化してしまうといった懸念があります。前述のツール群を「うまく使う」ために、開発サイクルの中でシームレス且つ継続的なSBOM管理・脆弱性対処が可能な仕組みが必要です。
4.セキュリティも自動化しよう - DevSecOpsで“継続的”なセキュリティ対策
従来、多くの開発プロジェクトにおいてセキュリティテストは、後工程の結合テストからシステムテストのフェーズで実施されるケースが殆どでした。リリースにできるだけ近いタイミングでセキュリティテストするという考えは正しいのですが、後工程になればなるほど問題が見つかった時の手戻りは大きくなり、コストも時間も費やすことになります。
また意識しなければならない点として、セキュリティは「生もの」であることです。セキュリティテストで今日は問題なかったとしても、明日も問題ないとは言えません。脆弱性は日々発見されており、また新しい攻撃手法も次から次へと出てきます。対処するにはセキュリティテストを継続的に実施するしかないですが、従来の手法で毎日診断を実施するのはあまりにコストが掛かり過ぎます。それならば自動化してしまえば良いのです。
DevSecOpsではCI/CDのパイプラインに自動化された各種セキュリティテストを組み込むことで、継続的なセキュリティテストを実現します。昨今、さまざまなセキュリティテストのツールがあり、プログラムソースコードをスキャンして脆弱性を検知する「SAST」、動いているアプリケーションに対して、実際に攻撃を実行することでアプリケーションに内在するセキュリティ脆弱性を検出する「DAST」、アプリケーションにエージェントを導入した状態で、通常の機能テストの裏で自動的にセキュリティ観点のテストを実行する「IAST」、ソフトウェアに含まれるOSSやライブラリを明らかにし、脆弱性またはライセンス違反などのリスクを管理する「SCA」といったツールがあります。
図3:セキュリティテスト手法とシフトレフトによる効果
加えて、DevSecOpsによって、アプリケーション開発の初期段階からセキュリティテストを実行できるようになり、早い段階で脆弱性に気づき対処する「Shift-Left」を実現できます。それにより問題発生時の手戻りを最小化し、コストや時間の節約にもつながります。
5.まとめ
NTT DATAでは数多くのプロジェクトが存在しており、それぞれのプロジェクトで個別にDevSecOpsを導入していくことは非常に労力がかかります。そのため、ベースとなるテンプレートを整備することによって導入時のハードルを下げ、DevSecOps、Shift-Leftを推進します。さらに、組織の文化として定着させることで、より安全なシステムを提供していきます。
セキュリティ・トランスペアレンシー・コンソーシアムについて:
https://group.ntt/jp/newsrelease/2023/10/11/231011a.html
ソフトウェアサプライチェーンにおけるセキュリティの要:SBOMの詳細はこちら:
https://journal.ntt.co.jp/article/23466
あわせて読みたい: