ソフトウェア開発はコードだけではありません。より重要なのは、より優れた安全なソフトウェアを開発するために役立つ一連のベストプラクティスとガイドラインに基づいて行われることです。他の大手ソフトウェア企業と同様に、Microsoft も独自のポリシーと手順を策定し、セキュアソフトウェア開発ライフサイクルなどのアプローチを実装しています。
参照: Google Workspace vs. Microsoft 365: チェックリスト付き比較分析 (TechRepublic Premium)
今日のソフトウェア開発が直面する最大の課題の一つは、ソフトウェアサプライチェーンの拡大です。クローズドソースとオープンソースのコンポーネントが融合し、使い慣れたアプリケーションが構築されています。しかし、最近の問題が示すように、信頼されたコンポーネントが侵害されると、コードにセキュリティ上の問題が誤って含まれてしまう可能性が高くなります。現代のソフトウェアはDocker Hub、NuGet、npmといったソースに依存しており、大規模なエンタープライズソフトウェアチームからコードを取得する場合もあれば、限られた空き時間を利用して自分のニーズを満たし、完成したコードを世界中の人々と共有する開発者からコードを取得する場合もあります。
ジャンプ先:
- ソフトウェアサプライチェーンのセキュリティ確保
- マイクロソフトのサプライチェーン透明性への取り組み
- SC2C2F とは何ですか? また、どのように使用されますか?
- コードを安全に保つための8つの方法
- 安全な組織成熟度の4つのレベル
- S2C2Fのオープンソース化
ソフトウェアサプライチェーンのセキュリティ確保
現代のコードはモジュール化されているため、様々なコンポーネントをすべて追跡するのは困難です。特に、長く複雑な依存関係の連鎖を分析する場合はなおさらです。Linuxマシンに新しいパッケージをインストールするだけで、単純なソフトウェアに付随する依存関係の連鎖を確認できます。目に見える依存関係は全体像の一部に過ぎません。他のライブラリやコンポーネントも、それぞれの依存関係と共に、使用しているコードにコンパイルされ、その連鎖の先へと続いていきます。
拡大するソフトウェアサプライチェーンを管理するには、一連のベストプラクティスが必要であることは明らかです。特に、使用しているコードの完全な出所がわからない場合はなおさらです。ソフトウェア部品表（BOM）などのツールは重要ですが、それらは使用しているソフトウェアに関する情報を示すツールに過ぎず、サプライチェーン全体を示すものではありません。悪意のある攻撃者は、ソフトウェアがコンポーネントリポジトリに配布される前に侵害を狙うため、使用するコードすべてを信頼するのではなく、積極的に懐疑的な姿勢を取り、信頼できるネットワークにコードが渡される前にテストと再テストを実施する必要があります。
マイクロソフトのサプライチェーン透明性への取り組み
ホワイトハウスが「国家のサイバーセキュリティ強化」大統領令を発令して以来、業界全体でSBOMとソフトウェアサプライチェーンへの注目が高まっています。マイクロソフトは、米国政府の政策への対応の一環として、Software Package Data Exchange（SDP）ベースのSBOMツールをはじめとする社内ツールをオープンソース化し、外部に公開してきました。そして今、より具体的な形ではないものの、同様に重要なものが、セキュアサプライチェーン消費フレームワーク（S2C2F）に続いて登場しました。
2019年から社内プロセスの一部となっているS2C2Fは、オープンソースソフトウェアサプライチェーンフレームワークとして誕生し、マイクロソフトがオープンソースプロジェクトをどのように利用し、貢献しているかを管理する上で役立っています。数千人の開発者がオープンソースに取り組んでいるため、マイクロソフトの何百万ものユーザー、そしてマイクロソフトが開発・保守するオープンソースコンポーネントに依存する他の製品の何百万もの顧客やユーザーを保護するために、これらのやり取りを管理する手段が不可欠です。
SC2C2F とは何ですか? また、どのように使用されますか?
S2C2Fのようなプロセスの目的は、組織がオープンソースとどのように関わっているかを把握し、潜在的なリスク領域を特定し、脅威を最小限に抑えるための繰り返し可能な一連のアクションを提供することです。S2C2Fの最も興味深い点は、成熟度モデルと連携することで、開発プロセスに適切なレベルのコンプライアンスを実現できることです。
コードを安全に保つための8つの方法
S2C2F の中心となるのは、オープンソース コードとの特定のやり取りとそれに関連する脅威に焦点を当てた 8 つの異なるプラクティスです。
- 摂取
- 在庫
- アップデート
- 強制する
- 監査
- スキャン
- 再建
- 修正して上流へ
それぞれは、ソフトウェア開発ライフサイクルの中でオープンソース コード、ライブラリ、またはコンポーネントを扱い、脅威とリスクを考慮する必要があるポイントです。
これらのプラクティスだけで一冊の本を書くのは容易でしょう。オープンソースコードをソフトウェア開発プロセスに取り入れる方法、分析・テストの方法、そして目的への適合性を確認する方法などを網羅しているからです。コードコミュニティの一員となり、変更リクエストを提出し、さらには自らプロジェクトのメンテナーとなり、それに伴うあらゆる責任を負うことで、学んだ教訓を他の潜在的なユーザーに伝えることができます。これらのプラクティスをソフトウェア開発ライフサイクルに導入したら、プロセスの成熟度を検討する必要があります。
安全な組織成熟度の4つのレベル
成熟度には4つのレベルがあります。レベル1は、ほとんどの組織がオープンソースを扱う方法です。使用されているソフトウェアのインベントリを管理し、市販のセキュリティツールを使用して、導入するソフトウェアとライブラリの脆弱性をスキャンします。レベル1では、すべての依存関係が最新の状態であり、使用するソフトウェアと同じツールを使用してスキャンされていることを確認する必要があります。
レベル 2 ではレベル 1 のプロセスが高速化されるため、悪意のある攻撃者よりも早くリスクにパッチを適用し、ゼロデイが使用される前に修正プログラムをリリースできます。
レベル3に移行するには、より多くの作業が必要です。プロアクティブなセキュリティツールを使用し、テストとセキュリティが完了するまで、開発環境からソフトウェアを分離する必要があります。このレベルの目的は、侵害されたソフトウェアがネットワークに侵入するのを防ぐことです。
レベル4に到達するために必要なツールの多くは、コードをリアルタイムで保護するために大規模な作業が必要となるため、ほとんど存在しないか、ほとんど存在しません。したがって、ほとんどの企業はレベル3を目指すべきです。レベル4の企業は、徹底的なコードスキャンを行った後、自社のインフラストラクチャ上ですべてのコンポーネントを再構築し、各コンポーネントを自社のSBOMと照合した上で、再構築されたコードにデジタル署名を行います。
S2C2Fのオープンソース化
Microsoftは最近、Open Source Security Foundation（OSSF）のサプライチェーン・インテグリティ・ワーキンググループの活動の一環として、S2C2Fが採用されたことを発表しました。この取り組みの目的は、MicrosoftだけでなくOSSFメンバー全員の成果を基盤として構築できるプロセスの基盤としてS2C2Fを活用することであり、そのプロセスとプラクティスは、CISOやソフトウェア開発の責任を負うセキュリティ担当者を対象としています。
まだかなり発展途上の取り組みですが、注目する価値は十分にあります。OSSFの初期段階の作業には、S2C2Fを他のオープンソースのサプライチェーン管理仕様にマッピングした論文が含まれています。そのため、既に独自のプロセスや他のプロセスを使用している場合は、Microsoftが得た教訓を自社のビジネスに取り入れ始めることができます。
オープンソースによって、私たちは他の企業や個人の成果から恩恵を受けることができます。それは、彼らが何を生み出すかだけでなく、どのように物事を行うかにも当てはまります。SC2C2FはMicrosoft向けに設計されましたが、その原則はあらゆるソフトウェア開発プロセスに適しています。
