ソフトウェアサプライチェーンについて、コミュニティが開発した、この問題を総合的に考えるためのフレームワークと、特にソフトウェアサプライチェーンの下流のセキュリティを向上させるためのGitHubの使い方について学びましょう。
ソフトウェアサプライチェーンのセキュリティは、2020年後半に米国連邦政府に対する大規模なサイバーセキュリティ攻撃が公表された際に世間の注目を集めました。本ブログでは、この攻撃への対応の歴史、米国政府だけでなくソフトウェアを生産するすべての人にどのような影響を与えたか、この問題を総合的に考える方法についてコミュニティが開発したフレームワーク、ソフトウェアサプライチェーンの下流のセキュリティを向上させるために特にGitHubをどのように使うかについて説明します。
略史
2020年後半、米国連邦政府に対する大規模なサイバー攻撃の詳細が公表されました。多くのサイバー攻撃と同様、マルウェアを利用したものでしたが、この攻撃で斬新だったのは、マルウェアが広く使われているセキュリティ製品のビルドプロセス中に含まれていたことでした。そのため、マルウェアは製品のコードベースにアクセスする従業員には見えず、標的はすでに製品を定期的にインストールし、アップデートしていました。
この攻撃は非常に強力かつ効果的であったため、2021年5月にホワイトハウスが「国家のサイバーセキュリティの改善に関する大統領令」を発表したのを皮切りに、米国政府および民間産業界に対応の波が押し寄せました。この大統領令では第4節で、（「a」から「x」までのアルファベットを使い切るほど！）ソフトウェアのサプライチェーンのセキュリティを強化するための措置が詳述されていたのです。
ここでは米国連邦政府の対応全体の詳細は省きますが、2024年現在も、ソフトウェアサプライチェーンのセキュリティは継続的な懸念事項となっています。2024年5月、ホワイトハウスは国家戦略実施計画v2を発表し、イニシアチブ5.5.4で「重要インフラ部門全体および部門内でサイバーセキュリティ・サプライチェーン・リスク管理（CSCRM）の重要な慣行を普及・強化する」ことを呼びかけました。2024年8月、国家サイバー長官室は、オープンソースコミュニティと民間セクターから受け取ったフィードバックを、「（5）ソフトウェアサプライチェーンの強化 」を含む、来年取り組むべき12の活動にまとめました。
これらの提言は、米連邦政府機関だけのためのものではなく、米国政府向けにクラウドサービスを販売する企業は、FedRAMPのようなフレームワークに準拠する必要があります。FedRAMPはNIST 800-53管理システムを使用しており、「PM-30：サプライチェーン・リスク管理戦略 」を含んでいます。しかし、米国政府向けに販売していない企業であっても、ソフトウェアサプライチェーンのセキュリティ管理に関する社内ポリシーを持つことは良いアイデアであり、SOC2やISO 27001の監査でコンプライアンスの証拠を提供することができます。
ソフトウェアサプライチェーンとは何か？
ここまでで、ソフトウェアのサプライチェーンを保護するための計画を持つことが良いアイデアであることを理解していただけたと思います。しかし、実際にはどのようなものなのか？どのように始めればよいのでしょうか？
オープン・ソース・セキュリティ財団（OpenSSF）は、それ自体がLinux財団の一部であり、セキュリティの実践を改善するために、オープンソースコードを作成し使用する人々が集います。ソフトウェアのサプライチェーンのセキュリティについて考えるためのフレームワークはいくつかありますが、私が最も使いやすいと感じたのは、OpenSSFが提供している「Supply-chain Levels for Software Artifacts (SLSA)」です。もしあなたが2020年以降にソフトウェア・セキュリティのカンファレンスに参加したことがあるなら、おそらくこのプロジェクトが描くソフトウェアのサプライチェーンを見たことがあるでしょう：
ご存知の通り、ソフトウェアの製造は複雑なプロセスであり、その過程で多くの問題が発生します。GitHubでは、サプライ チェーンのコードをセキュリティで保護するためのベスト プラクティスを提供しています。
米国サイバーセキュリティ・インフラストラクチャ・セキュリティ局（U.S. Cybersecurity and Infrastructure Security Agency）が発行している「ソフトウェアサプライチェーン攻撃に対する防御（Defending Against Software Supply Chain Attacks）」から的を射た表現であるため引用します：
ソフトウェア・リリースの完全性（特にコード署名証明書の保護）を検証するメカニズムを提供することで、顧客が入手したソフトウェアが改ざんされていないことを確認できるようにする。
GitHubの利用
コード署名は目新しいものではありませんが、多くの実装には落とし穴や使い勝手の悪さがあります。秘密鍵の安全な管理は厄介で、多くのシステムでは秘密鍵が誤って公開された場合に回復する方法がありません。GitHubは、GitHub Actionsでビルドしたソフトウェアに署名できるよう、アーティファクト認証を構築しました。Actions OIDC トークンで利用できるワークロード ID を使って、コード署名証明書を安全に取得します。長期間の秘密鍵を管理する必要はなく、キーローテーションもサービスに組み込まれています。使用するには、署名を行うワークフロー・ステップを追加するだけでよく、オフライン検証のサポートを含め、gh CLIを使用して署名を検証することができます。
署名とビルドの検証を簡単に始める方法を探しているだけなら、ここまでで十分かもしれませんが、アーティファクト認証にはさらに高度な機能がありますので知っておいて良いかもしれません。
詳しく説明するためには、SLSA フレームワーク、特にビルドトラックに戻りましょう。アーティファクト証明書を使用することで、レベル 0（何も持っていない状態）からレベル 2（署名された証明書）に到達することができます。証明性とは、ビルドのバイト数に対する署名以上のものです。コード署名証明書は、ビルドのワークロードIDとともに取得されるため、その証明書には、ビルドの正確なリポジトリ、ビルド指示へのパス、ソースコードとビルド指示の正確なSHA、ビルドがどのブランチから来たか、ビルドがどのようにトリガーされたかといった、さらに多くの有用な情報が含まれています。gh CLI を使ってビルド署名を検証する場合、提供できる最小限の情報は、ビルドがどのオーナーやリポジトリから来たかということです。しかし、ルールセットで保護されたブランチからのビルドを要求するなど、これらのフィールドにポリシーを適用することができます。
実際、SLSA のビルドトラックでは、ビルドが制御された入力で隔離された環境で行われるレベル 3 を定義しています。GitHub プラットフォームでは、これは、ビルドが再利用可能なワークフローで行われ、ビルド手順が組織内で吟味され、アーティファクト認証の際にどのワークフローからのビルドを許可するかを指定することに相当します。そのために、再利用可能なワークフローでアーティファクト認証を使用するためのドキュメントを作成しました。
結論
ソフトウェアサプライチェーンセキュリティは、新しくも大規模なトピックです。一度にすべてに取り組もうとするのではなく、まず、ビルドを実行する前に、アーティファクト認証でビルドに署名し、その署名を検証することから始めることをお勧めします。あなたの組織が今日それを必要としていなくても、それは良い習慣であり、近い将来、より多くの消費者が関心を持ち質問してくるようになるでしょう。私たちは常にソフトウェア開発者とともにセキュリティ課題に取り組み、セキュリティのニーズが高まる中で、より高度な機能に対応できるようサポートしていきます。
The post The second half of software supply chain security on GitHub appeared first on GitHub Blog.
