Google CloudでSBOMを保護する
2024年3月28日
0 分で読めますここ数年、ソフトウェアサプライチェーンのセキュリティは、政府機関や企業にとって重要な課題となっています。2021年末のLog4Shellを受け、バイデン政権の国家サイバーセキュリティ戦略は、オープンソースのサプライチェーンセキュリティに重点を置くようになりました。
米国家安全保障局(NSA)は最近、オープンソースソフトウェアのサプライチェーンを保護するための新しいガイダンスを公開しました。この文書では、オープンソースソフトウェア(OSS)の管理と、ソフトウェア部品表(SBOM)の維持に関する推奨事項が示されています。
ソフトウェアサプライチェーンの保護が注目されるのには、理由があります。サプライチェーン攻撃の影響を受けたソフトウェアパッケージの数は、2019年の約700件から、2022年には18万5,000件以上に増加しました。
開発チームがNSAの新しいガイダンスへの対応を検討する際、特にGoogle Cloudのようなクラウド環境では、取り組みを支援し、こうしたベストプラクティスを反復的なDevSecOpsモデルに結び付けられるパートナーを見つける必要があります。
NSAの推奨事項を詳しく見る
「ソフトウェアサプライチェーンの保護:オープンソースソフトウェアとソフトウェア部品表の管理に関する推奨プラクティス」と題されたこの新しい推奨文書は、次の4つのセキュリティ分野を中心に構成されています。
オープンソースソフトウェアの管理
安全なオープンソースリポジトリの作成と維持
オープンソースの保守と危機管理
SBOMの作成と検証
この文書で開発者向けに挙げられている推奨事項をいくつか見ていきましょう。
オープンソースソフトウェアの管理
この文書では、オープンソースソフトウェアの管理責任の大部分を開発者に割り当てています。最適なOSSを選び、ライセンスや脆弱性の問題を確認し、開発ライフサイクルに組み込み、SBOMを作成する必要があります。
開発プロセスでオープンソースソフトウェアを利用する際、NSAは次のような複数のプラクティスを推奨しています。
選定:OSSを適切に評価し、最も安全な選択肢を選ぶ
リスク評価:選択した各OSSに関連するリスクを十分に把握する
ライセンス:各ライセンスで定められた義務や制約を遵守する
輸出管理:適用される輸出規制を遵守する
保守:組織内に安全なリポジトリを維持する
脆弱性への対応:新たな脆弱性を発見し、修正するためのプロセスを確立する
安全なソフトウェアの提供:出荷前にバイナリ構成分析を行い、最終成果物の内容を再確認する
安全なオープンソースリポジトリの作成と維持
NSAは最近の刊行物で、組織内に安全なリポジトリを作成するための推奨事項に一章を割いています。
リポジトリの維持に関する2つの推奨事項は次のとおりです。
組織の規模や利用可能なリソースに合ったOSS導入プロセスを確立する。
導入の前後に脆弱性とリスクを評価する。その評価結果に基づいて、使用するコンポーネントや、元に戻すべきコンポーネント、より安全なバージョンに更新すべきコンポーネントを判断します。
オープンソースの保守と危機管理
安全であり、組織内リポジトリでの使用が承認されていたオープンソースソフトウェアでも、ゼロデイ脆弱性の影響を受ける可能性があります。組織は、選択したOSSに新たなリスクが見つかった場合に、それを発見して対処する方法も検討する必要があります。
企業は、次の推奨プラクティスを活用して、新たなオープンソースの脆弱性や脅威を発見し、修正するための継続計画を策定できます。
新たな脅威を把握するために、信頼できる脅威インテリジェンスを活用する。
ライブラリ全体から脆弱なコンポーネントを特定するために、SBOMを活用する。
脆弱性を修正するプロセスに従い、修正版への更新や、影響を受けないバージョンへの切り戻しを行う。
重大なソフトウェアの問題への対応と、関係者への迅速な情報提供に備え、事前に危機管理計画を策定する。
SBOMの作成と検証
この文書は、SBOMの重要性も強調しています。SBOMを作成・更新し、適切な人やツールが利用できるようにすることが重要です。
NSAは、適切なSBOMに必要な特性をいくつか挙げています。
コンポーネント、バージョン、ライセンス、依存関係に関する詳細情報
ソフトウェア構成分析(SCA)などのセキュリティ手法をパイプラインに組み込むこと
SDLC全体でコンポーネントを簡単に検出・更新できる自動抽出ツール
開発者がSBOMデータをツールや自動化に組み込めるよう、正しい形式であることを確認する品質保証と検証
Google CloudユーザーがSnykを活用して推奨事項に準拠する方法
こうしたプロセスは開発チームに余計な負担をかけるように思えるかもしれませんが、必ずしもそうではありません。Snykのオープンソースセキュリティ管理を活用すれば、既存のオープンソースコンポーネントの脆弱性を簡単に発見・修正し、マージ前にプルリクエスト内の安全でないコンポーネントをスキャンして、情報を拡充したSBOMを作成できます。SCAツールであるSnyk Open Sourceのおかげで、Log4Jの影響を受けたSnykのお客様の99%が、3日以内にLog4Shellの脆弱性を修正しました。開発者を第一に考えたSnykのセキュリティプラットフォームを活用することで、次のように連邦政府のセキュリティガイドラインに簡単に準拠できます。
コーディング中に、IDEやCLIで脆弱な依存関係を見つける。
マージ前にリポジトリからプロジェクトを直接テストし、新たな脆弱性がないか毎日監視する。
CI/CDパイプラインにSnykの自動テストを追加し、ビルドプロセスで新たな脆弱性が入り込むのを防ぐ。
本番環境をテストし、既知の脆弱性にさらされていないことを確認する。
各オープンソースパッケージについて、ライセンスの詳細、外部リンク、メンテナー情報などを含むSnykの拡充情報を含むSBOMを生成する。
さらにSnykはGoogle Cloudと連携し、ソフトウェアサプライチェーンのセキュリティを確保します。アプリの構築や実行に使用するGoogleサービスと統合でき、次のサービスに対応しています。
Google CloudBuild。 Snykがプロジェクト内のすべてのパッケージをスキャンし、自動修正のアドバイスを提供します。
Google Artifact Registry(GAR)。 Snykがコンテナの脆弱性をスキャンし、ベースイメージをテストします。
Google Kubernetes Engine(GKE)。 Snykを使うと、実行中のワークロードをインポートしてスキャンし、イメージや構成の脆弱性を特定できます。
これらのインテグレーションにより、Google Cloud上で最新のコンテナ化アプリを構築するチームは、既存の環境を離れることなく、SBOMを検証し、ソフトウェアサプライチェーンを保護できます。
お客様は、既存のGoogleの請求方法を利用して、Google Cloud MarketplaceからSnykソフトウェアを直接購入することもできます。
詳細については、SnykがKrogerのチームによるサプライチェーンの保護を支援した事例をご覧ください。
