ソフトウェアサプライチェーンのセキュリティリスクとベストプラクティス

現代の開発チームは、すべてを自社開発のコードで作るのではなく、独自のコード（その企業ならではの「秘伝のソース」）と、多数のサードパーティ製コンポーネントを組み合わせています。その多くはオープンソースで、開発者の時間を節約し、より優れたイノベーションを実現するために欠かせないものです。しかし、オープンソースソフトウェアがもたらす無限の可能性には、新たなリスクも伴います。それがソフトウェアサプライチェーンのセキュリティです。 

サプライチェーンにおけるセキュリティリスクとは？

では、なぜ現代の組織はソフトウェアサプライチェーンを注意深く監視する必要があるのでしょうか？ソフトウェア開発の世界は絶えず変化しています。組織の開発者は、車輪の再発明を避けるため、日々、アプリケーションで多数のコンポーネントを活用しています。それぞれのコンポーネントには依存関係があり、その依存関係にもまた依存関係があります。連鎖のどこかに既知の重大な脆弱性が含まれていれば、ビジネスが危険にさらされます。

サプライチェーンに起因するサイバーリスクが長期にわたる影響を及ぼした例として、SolarWinds Orionのセキュリティ侵害が挙げられます。

よくあるサプライチェーンの脅威をいくつか紹介します。

• 脆弱なオープンソースパッケージ／コンテナ。たとえば、平均的なnpmパッケージは、79個のサードパーティ製パッケージと39人のメンテナーをソフトウェアサプライチェーンに取り込みます。この単一のコンポーネントをダウンロードするだけで、攻撃対象領域全体を持ち込むことになります。 

• タイポスクワッティング／ブランドジャッキング。これは、悪意ある攻撃者が正規のパッケージに似た名前を使って、悪意のあるパッケージをレジストリに公開する攻撃手法です。オープンソースパッケージのセキュリティを確認しないユーザーは、こうした悪意のあるリソースを誤ってダウンロードする危険があります。 

• データ管理。多くの組織は、ソフトウェアサプライチェーンに何が含まれているのかを把握できていません。開発者が新しい、または更新されたオープンソースパッケージやコンテナを追加しても更新しないため、ソフトウェア部品表（SBOM）はすぐに古くなってしまいます。 

• アクセス権。組織がサードパーティベンダーやコンポーネントに過剰なアクセス権を付与すると、侵害された場合に、そのサードパーティがサプライチェーンの最も弱い部分になりかねません。 

• ヒューマンエラーや不注意。チームがソフトウェアサプライチェーンのセキュリティに関するベストプラクティスを意識していないと、ミスが起こります。開発者が悪意のあるパッケージをダウンロードしたり、サードパーティベンダーに機密情報へのアクセスを許可したりする可能性があります。ヒューマンエラーによってSDLC全体が危険にさらされる可能性は数多くあります。 

最新のサプライチェーンホワイトペーパーで、サプライチェーンセキュリティについて詳しくご覧いただけます。

SBOMを作成するだけでは不十分な理由

多くの組織はサードパーティ製コンポーネントを利用するリスクを理解していますが、サプライチェーンのセキュリティ対策が不完全なことが多く、攻撃につながる可能性があります。SBOMを作成すればソフトウェアサプライチェーンを保護できると考えるのはよくあることです。そう考えるのも無理はありません。SBOMは今、多くのセキュリティに関する議論の中心にあり（最近の大統領令でも取り上げられています）。

しかし実際には、SBOMは、いわば「原材料の一覧」にすぎません。加工食品と同じように、「ポリソルベート80」のような、分かりにくく見慣れない項目が含まれていることもよくあります。その原材料を知っていたとしても、それが良いものか悪いものかは分かるでしょうか？

このたとえをさらに進めると、以前は無害と考えられていた原材料が、後になって避けるべきものになる場合があります（たとえば赤色5号）。SBOMも同じです。今日のSBOMに問題がなくても、明日も安全とは限りません。リスクを効果的に防ぐには、組織でほかのサプライチェーンセキュリティのベストプラクティスも継続的に実践する必要があります。

組織で実践すべきサプライチェーンセキュリティのベストプラクティス

開発チームが実践すべきサプライチェーンセキュリティのベストプラクティスは5つあります。オープンソースパッケージ／コンテナのスキャン、正しいパッケージの使用（悪意のあるものを避けること）、正確なSBOMの維持、RBACポリシーの導入、そしてチームの教育・トレーニングの優先です。 

それぞれのベストプラクティスを詳しく見ていきましょう。

1. オープンソースパッケージ／コンテナの脆弱性をスキャンし、ポリシーを策定する

すべてのオープンソースパッケージ／コンテナを手作業で追跡し、脆弱性を確認するのは現実的ではありません。その代わり、ソフトウェアサプライチェーンの脆弱性を継続的にチェックするツールを導入しましょう。開発者がSDLCの早い段階で、リスクのあるオープンソースソフトウェアをより安全な選択肢に置き換えられるようポリシーを設定し、脆弱なコンポーネントが下流へ持ち込まれるのを事前に防ぎます。

2. 正しいパッケージを使用していることを確認する

タイポスクワッティング／ブランドジャッキングは非常によく見られるサプライチェーンの脅威であるため、すべてのパッケージを念入りに確認することが重要です。SCAツールのSnyk Open Sourceなどを使い、ソフトウェア開発ライフサイクルの早い段階で、オープンソースパッケージのチェックポイントを設けましょう。開発チームがその指針を無理なく実践できるよう、CI/CDパイプラインツールのCLIなど、チームのワークフローにセキュリティスキャンを組み込みます。

3. アプリケーションに含まれるものを記録する（SBOM）

SBOMは、あらゆる企業のソフトウェアサプライチェーンのベストプラクティスに不可欠です。現代のSDLCは急速に変化するため、SBOM自動化ツールの利用を検討しましょう。 

さらに、チームは誰がSBOMにアクセスできるかを把握しておく必要があります。SBOMが広く公開されていて、ソフトウェアに新たに公表された重大な脆弱性が含まれていたとしましょう。すると、SBOM自体がサプライチェーンセキュリティの脅威になってしまいます。

4. 包括的なRBACポリシーを導入する

ロールベースアクセス制御は、最小権限の原則に基づき、各ユーザーが業務を遂行するために必要な最小限のアクセス権をデフォルトで付与する考え方です。RBACポリシーを確立するには、誰が何にアクセスでき、どのレベルの権限を持つかをチームが把握する必要があります。Policy as Code（PaC）を使えば、セキュリティチームは高水準の宣言型言語でコードとしてRBACポリシーを定義できます。ポリシー管理を一元化し、組織全体に一貫して適用できます。 

5. チームの教育とトレーニングを優先する

ヒューマンエラーや不注意による問題を防ぐため、サプライチェーンの潜在的な脅威についてスタッフを教育・トレーニングしましょう。ゲーミフィケーションは、開発者がサプライチェーンセキュリティのベストプラクティスを学ぶ意欲を高める効果的な方法です。組織のセキュリティ向上に貢献したチームメンバーを称えることも重要です。Snykは開発者向けの無料セキュリティレッスンを提供しています。こちらをご覧ください。

Snykでソフトウェアサプライチェーンを保護する

Snykのサプライチェーンセキュリティソリューションは、開発チームとセキュリティチームが連携してソフトウェアサプライチェーンを保護できるよう支援します。オープンソースライブラリ、開発者ツール、コンテナイメージ、クラウドインフラを保護するため、さまざまな組織を支援しています。既存の開発ツールやワークフローと直接連携する開発者ファーストのセキュリティプラットフォームにより、チームはサプライチェーンセキュリティのベストプラクティスをすばやく簡単に実践できます。