ソフトウェアをインストールする際、そのコードが信頼できるものであると確信していますか？ 自問すべき質問はたくさんあります。例えば、そのアプリケーションがどのようにしてあなたの元に届いたのか、どのように構築されたのか、そして裏でどのようなサードパーティ製ソフトウェアが動作しているのか、といった点です。
参照: Google Workspace vs. Microsoft 365: チェックリスト付き比較分析(TechRepublic Premium)
今日のアプリケーションは、オープンソースコミュニティから大規模な継続的インテグレーション／継続的開発プラットフォームにまで及ぶソフトウェアサプライチェーンの一部です。この問題は、最近の一連の事件によって鮮明に浮かび上がっています。例えば、Solar Windsの管理プラットフォームにバックドアを仕掛け、顧客のシステムを攻撃するために、不正なビルドプロセスが利用されたことや、様々なオープンソースライブラリが乗っ取られ、仮想通貨マイナーが組み込まれてユーザーの電力やCPUが盗まれるといった攻撃が挙げられます。
エンドユーザーは、侵害されたソフトウェアを使用していることに全く気づいていませんでした。彼らにとっては、これは正当なソースから提供された正当なコードであり、安全だと信頼していたのです。しかし、そのソフトウェアがどのように構築されているかを把握できなかったため、そのソフトウェアが信頼できないものであると判断する手段がありませんでした。私たちが使用するソフトウェアは、コンテナベースのイメージからビルドスクリプトまで、様々なコンポーネントから構築されています。
ソフトウェアサプライチェーンを理解して保護する
私たちは、物質的な製品を届けるサプライチェーンについて理解しており、それらを保護するための措置を講じています。工場間や国境を越えた製品の流れを規制する国際法や規則があり、証明書や通関書類によって製品の動きや基準への適合状況を追跡しています。しかし、私たちはソフトウェアのためにそうしているわけではありません。単にソフトウェアをインストールし、事業運営のために使用しているだけです。
1年前、米国政府は業界に対し、ソフトウェアサプライチェーンの保護に向けた取り組みを促す大統領令を発令し、米国連邦政府に提供されるすべてのアプリケーションにソフトウェア部品表（SBOM）の記載を義務付けました。これは包括的な命令であり、ソフトウェアサプライチェーンの改善とセキュリティ確保のためのガイドラインを示すことを目的としています。その目的は、ソフトウェアエンジニアリングを他のエンジニアリング分野と同等の立場に置くプロセスを導入することです。
Microsoftは長年にわたり社内でソフトウェアマニフェストを使用しており、ソフトウェアの構築に使用される様々なコンポーネントやモジュールを追跡しています。この取り組みがきっかけとなり、Microsoftは情報・ソフトウェア品質コンソーシアム（CISO）のTool-to-Tool SBOMワーキンググループを主導し、顧客やパートナーとこの情報を共有するための業界横断的な標準を構築することになりました。作業はかなり進んでいましたが、開発中のSBOMプラットフォームはこれだけではありませんでした。
米国政府の命令を受けて、Microsoftとコンソーシアムの他のメンバーは、Linux Foundationの同様のプロジェクトと連携して作業を進めています。これは、オープンソースライセンスコンプライアンスに関するISO標準の一部であり、アプリケーションにバンドルされているすべてのライセンスをエンドユーザーと共有することを目的としています。SBOMにライセンス情報を添付することは非常に理にかなっています。ソフトウェアパッケージデータ交換（SPDX）を使用して作成された機械可読なマニフェストを使用して、どのコンポーネントにどのライセンスが適用されているかを確認できるからです。
SPDXと協力してSBOMを構築する
SPDXは、米国政府の電気通信情報局（NTI）が想定していたツールと完全に同じではありませんが、非常に近いものであり、初期要件のほとんどに対応でき、残りの要件にも容易に適応できるはずです。さらに、SPDXは現在最も広く使用されているSBOMツールであり、適切なオープンソースツールスイートを使用することで、ほとんどのソフトウェア開発環境に簡単に組み込むことができます。SPDXの開発はライセンスコンプライアンスが推進したかもしれませんが、使用しているソフトウェアの種類とその入手元を把握する必要があるため、デジタル署名やハッシュなどの他の検証機能を容易に追加できるように拡張できる必要があります。これにより、バイナリやその他のソフトウェア成果物、そしてソースコードもカバーするSBOMを構築できます。
参照:採用キット: バックエンド開発者(TechRepublic Premium)
Microsoftは、NTIAの要件と大統領令に準拠するため、社内マニフェストツールを自社形式からSPDXに移行してきました。その結果、ビルドごとにJSON形式のSBOMファイルを生成するツールが誕生しました。これは政府機関の顧客向けだけでなく、すべてのソフトウェアで採用されています。SPDX実装の中核は、主要なNTIA SOMフィールドをSPDXにマッピングすることです。例えば、NTIAがコンポーネント名を要求した場合、MicrosoftのSPDX実装ではSPDXパッケージ名フィールドを使用します。また、サプライヤー名、パッケージバージョン、パッケージチェックサム、関係性といったフィールドをSPDXではオプションとして扱うところを必須にすることで、Microsoftは可能な限り詳細なSBOMを提供できるようになりました。
これを実装することは、Microsoftにとって大きな仕事です。Windows、Mac、Linux、Android、iOSなど、様々なプラットフォームで、1日に約50万件のビルドを生成しています。そのため、すべての公式ビルド（開発ラボから出ないテストビルドや開発ビルドにはSBOMは必要ありません）に対して、SBOMの生成を自動化する必要があります。SBOMはCI/CDビルドパイプラインの一部となり、他のビルド成果物と共に配信される必要があります。
その結果、商用ソフトウェア コンポーネントを識別するだけでなく、独自の NuGet や人気の JavaScript NPM リポジトリなどの最も一般的なソフトウェア リポジトリからオープンソース コンポーネントを検出して識別し、Go や Rust などの言語や、独自の Git リポジトリを持つアプリケーションでも動作するクロスプラットフォーム ツールが誕生しました。
生成されたSBOMは、NTIA仕様をはるかに超えるSHA256とSHA1の両方のハッシュをコードに持ち、さらにセキュリティ強化のため、生成されたファイルには独自のデジタル署名が付与されます。また、ビルド実行をエンコードする署名により、使用されたビルドシステムも追跡されます。最後に、ビルドの出力はSBOMと照合され、不一致があった場合、生成されたソフトウェアはリリースされません。これにより、Azureなどのサービスで侵害されたコードが実行されることを防ぎます。
安全なソフトウェア以上のものを実現する独自の SBOM の構築
ソフトウェアサプライチェーンを理解することは大きな価値があり、それは単なるセキュリティ問題にとどまりません。ビジネス関係の構築と維持における問題を解決できる可能性を秘めています。Wordのような広く普及しているソフトウェアに公開SBOMを導入することは、サプライヤーと顧客の関係改善に役立ちます。ソフトウェアの出所証明を求めることは、近い将来、あらゆる契約交渉の一部となり、企業がより効果的にリスクを管理できるようになるでしょう。ソフトウェアにSBOMを導入しておけば、必要な他の文書と共にSBOMを渡すことができるようになります。
Visual StudioでMicrosoftと同じツールを使用して、独自のカスタムソフトウェア用のSBOMを生成できるようになります。MicrosoftはSPDXツールをオープンソース化すると発表しており、これによりあらゆるCI/CDツールやIDEで使用できるようになります。Visual Studio for .NETで提供されているツールは、Androidの場合はAndroid Studio、iOSの場合はXCodeでも利用可能になります。これは業界全体にとって大きな勝利です。企業がSPDXプラットフォームを拡張し、ますます複雑化するソフトウェアサプライチェーンの世界を理解するための、クロスプラットフォームかつ業界標準の手段を提供してくれるからです。
