Google CloudでSBOMをセキュアにする

著者:

March 28, 2024

0 分で読めます

近年、ソフトウェアサプライチェーンのセキュリティは、政府や企業にとって最優先事項となっています。2021年末のLog4Shellの後、バイデン政権の国家サイバーセキュリティ戦略は、オープンソースのサプライチェーンセキュリティに焦点を当て始めました。

国家安全保障局（NSA）は最近、オープンソースソフトウェアのサプライチェーンを確保するための新しいガイダンスを発表しました。この新しい文書では、オープンソースソフトウェア（OSS）の管理とソフトウェア部品表（SBOM）の維持に関する推奨事項が掲載されています。

ソフトウェアサプライチェーンのセキュリティが注目されるのには理由があります。サプライチェーン攻撃の影響を受けるソフトウェアパッケージの数は、2019年に約700だったのが、2022年には185,000を超えるまで増加しました。

開発チームがNSAの新しいガイダンス、特にGoogle Cloudなどのクラウド環境にどのように対応するかを検討する際には、これらのベストプラクティスを継続的なDevSecOpsモデルに落とし込む必要があります。

NSAの推奨事項の概要

この新しい推奨文書は、「ソフトウェアサプライチェーンのセキュリティ確保:オープンソースソフトウェアおよびソフトウェア部品表の管理に関する推奨事項」と題され、セキュリティの4つの主要なトピックを中心にしています：

オープンソースソフトウェアの管理
安全なオープンソースリポジトリの作成と維持
オープンソースのメンテナンスと危機管理
SBOMの作成と検証

この文書で言及されている、開発者向けの推奨事項について見ていきましょう。

オープンソースソフトウェアの管理

この文書は、オープンソースソフトウェアの管理に関する大部分の責任を開発者に割り当てています。開発者は、最適なOSSを選択し、ライセンスや脆弱性をチェックし、それを開発ライフサイクルに追加し、SBOMを作成する必要があります。

開発プロセスでオープンソースソフトウェアを使用する際に、NSAはいくつかの実践を推奨しています。これには以下が含まれます：

選択：OSSを適切に評価し、最も安全なOSSを選択する
リスク評価：選択された各OSSに関連するリスクを完全に理解する
ライセンス：任意のライセンスが要求する義務と制約に従う
エクスポートコントロール：適用されるエクスポートコントロールに従う
メンテナンス：内部の安全なリポジトリを維持する
脆弱性対応：新たな脆弱性を発見し修正するためのプロセスを設定する
安全なソフトウェアデリバリー：リリース前にバイナリ構成分析で最終的な納品物の内容を再確認する

安全なオープンソースリポジトリの作成と維持

NSAは最近の報告書の一部を、内部で安全なリポジトリを作り上げるための推奨策に特化して紹介しています。

このリポジトリを維持するための2つの推奨事項には以下が含まれます：

あなたの組織の規模と利用可能なリソースに合わせたOSS導入プロセスを確立する。
導入前後に脆弱性とリスク評価を行い、これらの評価結果を使用して、どのコンポーネントを使用するか、またはより安全なバージョンに戻すか更新する必要があるかを決定する。

オープンソースのメンテナンスと危機管理

以前は安全と思われていたオープンソースソフトウェアや内部で承認されていたレポジトリでも、ゼロデイ脆弱性に対して脆弱である可能性があります。企業は、採用したOSS内でこれらの新しいリスクを検知して対処する方法を検討するべきです。

企業は、以下の推奨される実践を用いて、新しいオープンソースの脆弱性や脅威を見つけて修正するための継続計画を作成できます：

新たに出現する脅威について知るために信頼できる情報源を活用する。
SBOMを使用して、ライブラリ全体の脆弱なコンポーネントを特定する。
修正されたバージョンへの更新や影響を受けないバージョンへ戻すなど、脆弱性を修正するためのプロセスに従う。
重大なソフトウェア問題に対応し、関係者にタイムリーな情報を提供するための事前の危機管理計画を立てる。

SBOMの作成と検証

この文書では、SBOM（ソフトウェア部品表）の重要性も強調されています。SBOMを作成し、更新し、適切な人々やツールがアクセスできるようにすることが重要です。

NSAは成功するSBOMのいくつかの特徴を強調しています：

コンポーネント、バージョン、ライセンス、依存関係の詳細
ソフトウェア構成分析（SCA）のようなセキュリティ技術を使用してパイプラインに統合
SDLC全体でコンポーネントを簡単に発見し更新するための自動抽出ツール
開発者がツールや自動化に統合できる正しいフォーマットであることを保証するための品質保証と検証

Google CloudユーザーがSnykを使ってこれらの推奨事項を守る方法

これらのプロセスは、開発チームにとって負担のように思えるかもしれませんが、そうである必要はありません。Snykのオープンソースセキュリティ管理により、既存のオープンソースコンポーネントの脆弱性を簡単に見つけて修正したり、マージ前にプルリクエストをスキャンして安全でないコンポーネントを検出したり、豊富な情報を含むSBOMを作成することがシームレスに行えます。Snyk Open Source、当社のSCAツールを活用することで、Log4Jに影響を受けたSnykの顧客の99%がLog4Shell脆弱性を3日以内に修正しました。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 Cloud Marketplaceから直接Snykのソフトウェアを購入することが可能です。

KrogerのチームがどのようにしてサプライチェーンをセキュアにしたかについてのSnykの事例を読んで、さらに詳しく知ることができます。