2022 年 10 月、Google Cloud は「ソフトウェア デリバリー シールド」というソリューションを公開しました。しかし私がそうだったんですが、もしかすると多くの方にとっても
- 解きたい課題、製品の背景がわからない
- 耳慣れない単語が多くてよくわからない
- 結局どう使えばいいのかわかりくい
かもしれないと思い。今日はこれをご紹介します。
背景
ソフトウェア サプライチェーン
開発者がソフトウェアを作り、それをユーザーさんが使うまでの一連の流れを「ソフトウェア サプライチェーン」と呼びます。物理的な製品や商品の「サプライチェーン」同様、あなたも無意識に、ソフトウェアを作るために必要な OSS や他社製品を "調達" し、リリースという形でソフトウェアを "配布・販売" し、その結果としてユーザーさんはあなたのソフトウェアを利用できていますよね！
ソフトウェア サプライチェーン
ここで大切なことは
このプロセスのどこかに問題があると、みなさんのソフトウェアが影響を受ける ということです。
- みなさんの書くソースコードはもちろん重要ですが
- 依存するソフトウェアも
- ビルドし、成果物を管理するツールも
- デプロイし、リリースするためのツールも
- もしくはそれらを任せている外部サービスも
どこに問題があってもダメです。
・・言われてみれば当たり前なんですが、少しハッとしないでしょうか？
実は今、ソフトウェア サプライチェーンが狙われています
そんな折、こんなレポートが公表されています。
- 650 % 2021 年、OSS サプライチェーン攻撃が急増しました Sonatype
- 84 % もの商用コードベースが OSS 脆弱性を含んでいます Synopsys
- 45 % の組織は 2025 までサプライチェーン攻撃を受けると予測されています Gartner
冷静にもう一度 ↑ 読んでください。鳥肌ものです。
ということで対策すべく、まずはその攻撃についてみてみましょう。
サプライチェーン攻撃
サプライチェーン攻撃とは、依存する “ソフトウェア” や “外部サービス” に対して攻撃し、なんらかの目的を達成するものを言います。具体的な脅威を考えるために先程の絵を利用してみると、実はすべての項目が攻撃対象になり得ます。依存に対する攻撃であり、セキュリティのシフトレフトといったプラクティスだけで守るものではありません。
ソフトウェア サプライチェーンの脅威
自社だけでできる対応には限界がありそうですよね？これらにどう対処すべきか・・
実際、サプライチェーン攻撃は対策が難しい攻撃の一つと言われています。
実例 1: SolarWinds 事件
2020 年、SolarWinds 社ネットワーク監視製品の正規アップデートにバックドアが仕込まれ、ものすごい数の組織が情報窃取等の被害にあいました。近年最大規模のサプライチェーン攻撃であるとされ、アメリカにおいて この大統領令 が発令されるきっかけになったとも言われています。
ビルドシステムに対する攻撃から始まりました
実例 2: Codecov 事件
2021 年には Codecov 社の提供するコード カバレッジツールが狙われます。カバレッジ ファイルをアップロードするスクリプトが CI 環境の環境変数に設定された情報をすべて攻撃者のサーバへ転送するように改ざんされ、プライベート リポジトリにあったソフトウェアも被害にあうなど、こちらもその被害は甚大でした。
実例 3: Log4Shell
2021 年には、Log4j でリモートから任意のコードが実行できてしまう脆弱性がありました。これは前述の事例と異なり直接的な攻撃ではありませんが、悪用されるわけにはいかない脆弱性ですよね。
ここまでのまとめ
ということでソフトウェア サプライチェーンに対する攻撃やその被害が急増しており
- 多様な攻撃ベクトル
- OSS 利用の増加
など、この攻撃ならではの特徴と昨今のトレンドがあいまってとても難しい状況です。
実は先の大統領令を読むと「政府に納品するシステムにはこれこれを添付せよ」といった具体的な指示が書かれていたりはするのですが、個別にではなく、業界として対策をまとめていこう！というのがここ最近の動向です。
オープンな対策
SLSA
SLSA (Supply-chain Levels for Software Artifacts) というものがあります。これは サプライチェーン攻撃からの保護に役立つオープンなフレームワークであり、2021 年 6 月に公開されました。
SLSA は 4 つのレベルでサプライチェーン攻撃への対策が構成されており
レベル 4 まで対策できると、ソフトウェアの利用者がソフトウェアが改ざんされておらず、ソースまで安全に追跡できる状態が得られるとされています。
ちなみに対策の対象は、さきほどの絵にでてきた A ~ H です。かなり幅広く守れますね！
https://slsa.dev/spec/v0.1/index
Google Cloud の DevOps 研究チーム DORA の 2022 年の調査 によれば、すでに多くの企業が SLSA の推奨するセキュリティ プラクティスを実践中であることが確認されています。
SBOM
SBOM とはソフトウェア部品表、つまりライブラリやモジュールといったソフトウェア構成要素のライセンス、バージョン、パッチ状況まで、詳細を記した目録のことです。
サプライチェーン同様、部品表そのものは従来からある概念、製造業で広く使われる Bill of Materials、BOM です。BOM は様々な用途に利用されていますが、サプライチェーン起因の事故対策という意味で、製造業の業務をそのまま比喩としても使えます。つまり
- A, B という製品（ソフトウェア）が X という部品（OSS）を使っているとき
- X に不具合（や脆弱性）があるとわかったら
- A, B に影響があると逆引きでき
- リコール、修正版（パッチ）のリリースといった対策を講じることができます
先の大統領令では連邦政府が使用するソフトウェアの安全性と整合性を確保するために SBOM が要件として挙げられるなど、昨今とても重要な文書となっています。米商務省国家電気通信情報局定義の “最小要素” を満たすデータ形式としては
などがあるのですが、例えば SPDX のサンプル をみるとこんな感じです。
GUAC
GUAC (Graph for Understanding Artifact Composition) はここまで紹介してきた SLSA や SBOM 由来のセキュリティ メタデータをデータベースに集約して、監査や開発者をサポートするために情報を検索・分析するための仕組みです。
例えばこんな疑問に応える想定のようです。
- プロアクティブ: 全体的なセキュリティ体制の弱点はどこですか？
- オペレーショナル: このデプロイは組織のポリシーを満たしていますか？
- リアクティブ: 新しい脆弱性 X の影響を受ける領域はありますか？
たしかに、今後はこんな仕組みが必要になりそうな流れはありそうですよね！
ソフトウェア デリバリー シールド
ということで。
ここまでソフトウェア サプライチェーン攻撃や周辺の業界動向をお伝えしましたが。
Google Cloud の提供する解決策がこちら、ソフトウェア デリバリー シールドです。
ソフトウェア サプライチェーンの保護
ソフトウェア デリバリー シールドは冒頭にでてきた ↓ の絵でいう A ~ H は SLSA に準拠した対策の実装、X ~ Z は独自で脅威を定義し、対策を講じています。
対策するにあたっては以下のように
開発、サプライ、CI / CD、実行環境、ポリシー制御、5 つの分野で検討し
以下のようなマネージドサービスの組み合わせでそれらを実装しようとしています。
つまりこのソリューション、単一のサービスではありません。
これまで見てきたように、ソフトウェア サプライチェーン全体を保護する必要があることから、それぞれのフェーズを担うサービスが担当エリアのセキュリティを実装し、全体としてシームレスに繋がるような設計です。全体を一挙に使う必要はありませんので、気になるところからぜひ使ってみてください！
例 1: Cloud Workstations
現在 Preview ですが、Google Cloud のフルマネージドな開発環境です。
11 月 28 日の App Modernization OnAir ではデモ付きで @Gossy さんが解説しています。
ぜひご覧ください！
例 2: Cloud Code
同じく現在 Preview ですが、IDE のプラグイン、Cloud Code ではコーディング中に脆弱性を検知し、警告が表示されるようになりました。遷移的依存関係のスキャンやライセンスに関する警告もサポートしており、なかなかに優秀な機能です！
例 3: Container Analysis
こちらもまだ Preview ですが、
Maven と Go の依存関係に対して脆弱性スキャンをかけたり、
ソフトウェア部品表 (SBOM) が生成できるようにもなりました。
例 4: Cloud Build
SLSA Level 3 のビルドをサポートし、その過程でコンテナ、Maven、Python パッケージに関するビルド来歴が生成されるようになりました。SLSA レベル・脆弱性・来歴などはセキュリティに関する分析情報として画面にも表示されます！ Preview です・・
例 5: Binary Authorization
信頼ベースでコンテナイメージのデプロイを制御できる機能です。
- ホスト名が前方一致したイメージのみ、環境へのデプロイを許可したり
- 電子署名したイメージのみを許可したりできます
例 6: GKE & Cloud Run
GKE においては継続的に実行時脆弱性・設定スキャンがなされたり、Cloud Run においてはセキュリティ分析情報が表示されたりするなど、ソフトウェア デリバリー シールドの発表に伴い実行環境の改善も行われています。まあ、こちらもまだ Preview ですが・・
最後に
いかがでしたでしょうか？
- ソフトウェア サプライチェーンとは？
- それを狙う攻撃とは？
- 業界ではいまどんな対策が考えられ
- 具体的にどんな実装が進んでいるか
少しでもその理解に本投稿が貢献できていれば幸いです。
Google Cloud では引き続き、ソフトウェア デリバリー シールド を通して、みなさんがお客様へソフトウェアを安全に届け、安心して使ってもらう仕組みを強化します。
SLSA や GUAC など、オープンな議論や実装にも注目いただけると幸いです！
Discussion