ソフトウェア・サプライ・チェーンの安全性：三本柱の実践で改善できるはず

Three Ways To Supercharge Your Software Supply Chain Security

2024/01/04 TheHackerNews — “Executive Order on Improving the Nation’s Cybersecurity” の第４節で紹介されているのは、技術業界の人々のための、ソフトウェア・サプライ・チェーンと安全性確保の概念である。もし、あなたがソフトウェアを作り、それを連邦政府機関に売りたいと考えているのであれば、ソフトウェア・サプライ・チェーンについて注意を払う必要がある。もし、政府機関に販売する計画がないとしても、ソフトウェア・サプライ・チェーンを理解し、その安全性を確保する方法を学ぶことで、より強固なセキュリティの足場とメリットという配当が得られる。この記事では、ソフトウェア・サプライチェーンのセキュリティを強化するための、３つの方法について説明していく。

ソフトウェア・サプライチェーンとは何か？　この言葉は、開発者がコードを書く IDE から、サードパーティの依存関係、ビルド・システムやスクリプト、実行するハードウェアやオペレーティング・システムにいたるまでの、ソフトウェア・ピースを構築するために必要な、すべてのものを指す。そして、不安定性や脆弱性については、悪意があろうがなかろうが、開発のスタートからデプロイまでの各ステップにおいて、また、それ以降においても、忍び込んでくる可能性がある。

１：シークレットを守る

サイバー・セキュリティにおける 2023年の大事件のいくつかは、プレーン・テキストで保持されるシークレットを、脅威アクターたｈしが見つけたことで発生している。ここでいうシークレットとは、ユーザー名とパスワードの組み合わせや、API／署名 キーなどのことだ。つまり、企業の核心部への鍵が、あるはずのない場所に転がっていたのだ。

Sourcegraph は、ハードコードされたアクセストークンを含むコードを、パブリックなインスタンスに公開したときに侵害された。そのトークンは、他のアカウントを作成し、Sourcegraph API に自由にアクセスするために使用された。また、あるハッカー・グループは、Microsoft 社内のデバッグ環境にアクセスし、電子メール認証情報を作成するための署名キーを、クラッシュ・ダンプの中から発見した。

GitGuardian のようなツールを使えば、レガシーなコードから最先端のコードまで、誤って公開されたシークレットをチェックするだけではなく、公開しようとする試みにブレーキを掛けてくれる。どのシークレットが公開された可能性があるのかを知り、それを修正することが重要だ。また、自動化ツールやコードレビューの形で安全策を講じ、他のキーが流出しないようにすることも重要だ。

２：BOM の作成に Source Composition Analysis を活用

製造業で用いられる BOM (Bill of Materials) は、製品やサービスの構築／製造／修理に必要な、すべての原材料／部品／ガイドラインを含む包括的なインベントリである。サイバー・セキュリティの規制とベストプラクティスの双方において、Software BOM のアイデアが受け入れられ、ソフトウェアを構築するために必要な、すべての部品の透明性と証明性を提供しようとしている。

しかし、宣言された依存関係のリストから BOM を構築することはできない。

npm や PyPI のようなパッケージ・リポジトリーや、オープンソースのフレームワークやライブラリの統合は、車輪の再発明を不要にするものであり、ソフトウェア開発を効率化するものとして歓迎されている。開発者は、再発明の代わりに、必要な機能を実装した無料のパッケージを見つけ出し、簡単にソフトウェアに組み込むことが可能である。

その一方で開発者は、依存関係の網の目にさらされることになる。依存関係の先に依存関係があり、その先にも依存関係がある。また、同じパッケージの４種類のリリースにサブ依存関係があり、そのすべてに異なる脆弱性があるかもしれない。

SCA (Source Composition Analysis) ツールは、プロジェクトのコードベースを自動的にスキャンし、使用している全ての外部コンポーネントを特定する。続いて、それらのコンポーネントが最新かつ安全であり、さらには、ライセンス要件に準拠していることを確認するためのチェックが行われる。

それにより、既知のエクスプロイトが存在する依存関係の特定が効率化される。さらに、問題のあるパッケージの更新／交換が可能になるだけではなく、顧客や規制当局による検査のために、クリーンな BOM の作成が要求される場合にも大きな助けとなる。

３：自分自身をハックする

エシカル・ハッキングは、かなり昔からあるものだ。最近の、倫理的ハッキングに関するウェビナーで述べられているように、倫理的ハッキングとは、”責任を伴う合法的な方法で、コンピューター・システムやネットワークの脆弱性を特定／悪用すること” である。”責任”と”合法的” が強調されていることに注意してほしい。

基本的に、倫理的ハッカーは “ブラックハット・ ハッカー”とほとんど同じテクニックを使って、システム内の脆弱性を見つけて悪用する。その違いは、許可を得て行うことにある。彼らは、ハッキングの許可を得たシステムに攻撃し、そこで発見された結果を、チームやクライアントが再現／分析できるように文書化する。

この試みは重要であり、開発プロセスの後期に行われることが多い。もし、彼らが、あなたの依存関係を特定し、脆弱な依存関係を特定する独自の SCA に到達すれば、ゲームオーバーである。彼らが、無防備な侵入口を見つけることができれば、その時もゲームオーバーである。彼らが、Web アプリをテストし、コンソールに機密出力を出力するデバッグコードを見つけたら、ゲームオーバーだ。脆弱性の中には、深刻な問題を引き起こすものもあれば、デバッグコードの１行の削除で済むものもある。

エシカル・ハッキングをリリース・プロセスの一部として、バグ報奨金プログラムに参加するという方式もある。それにより、顧客に謝罪し、規制当局に報告し、後始末に汗をかく前に、脆弱性を確実に修正できる。

まとめ

規制当局を喜ばせるためであれ、顧客を喜ばせるためであれ、ソフトウェア・サプライチェーン・セキュリティを強化することで、ソフトウェアに費やす時間を増やし、謝罪する時間を減らすことが可能になる。前述の３つのヒントを参考にすることで、十分な基礎を築くことができるが、SLSA のセキュリティ・フレームワークには、さらに多くのヒントが含まれている。SLSA サイトの言葉を借りれば、このフレームワークを活用して、サプライチェーンのセキュリティを確保することで、あらゆるチェーン・リンクにおいても、”十分な安全性” から “可能な限りの回復力” が得られるのである。

短く簡潔に、新たな切り口からまとめられている、とても良い記事ですね。つい先日の 2024/01/02 には、「Enterprise Browser Buyer’s Guide：企業にとって重要な視点を提供する」という記事がありましたが、こちらも良事でした。年の変わり目には、あらたな視点からの記事が増えるので、翻訳作業も楽しくなります。