OSS のセキュリティ神話を検証:解かれるべき誤解とエンタープライズでの採用について

Debunking myths about open-source security

2024/11/20 HelpNetSecurity — Canonical の CISO である Stephanie Domas へのインタビューは、オープンソースのセキュリティに関する一般的な誤解と、それを払拭するためのコミュニティの取り組みについて説明するものだ。彼女の主張は、神話に反してオープンソース・ソリューションが、エンタープライズ・グレードの成熟度/信頼性/透明性を提供しているというものだ。さらに Stephanie Domas は、セキュリティの強化と、革新と安定のバランスを得るために、ユーザー組織がオープンソースを採​​用する際の、優先すべき重要な要素についても説明している。

OSS に関する最大の誤解とは? コミュニティと専門家たちの協力による神話の払拭とは?

オープンソース・セキュリティに関して、私の印象に残っている、3つの主たる誤解がある。それは、オープンソース・ソフトウェア (OSS) セキュリティにおけるソフトウェアとテクノロジーは、”エンタープライズ・グレードと比較して成熟していない”、”信頼性が低い”、そして、”オープンすぎて安全ではない” というものだ。

このような論調は、多くの OSS において、真実と乖離している。成熟した OSS には、プロプライエタリと同レベルと言って良いほどの、堅牢な品質プロセスがある。それを構成するのは、タイムリーなパッチ・スケジュールや、10年〜12年にわたる堅牢な長期サポート、成熟したロードマップ、ソフトウェアのパフォーマンス、そして、機能を絶えず改善する大規模でアクティブなコミュニティなどである。

専門家たちにとって、この成熟に関する事実は、耳の痛い神話である。OSS が信頼できないとしたら、組織の 90% が OSS を使用し、ソフトウェア・コードベースの 99.9% に OSS が取り込まれることは無かっただろう。供給側と需要側にとって、OSS の価値は驚異的なものになっている。先日に読んだ論文では、OSS が存在しないと仮定すると、平均的な企業におけるソフトウェア開発コストは、3.5 倍に達すると推定されていた。

さらに言うと、ソースコードの透明性が、サイバー・セキュリティにとってマイナスであるという考え方は、明らかに誤りである。一般的に、不明瞭さによるセキュリティは、悪い戦略と見なされている。つまり、コードに目を向ける人が増えることでセキュリティが強化され、問題の発見に情熱を傾ける何千人もの人々に、コードベースを精査してもらうことで、より安全なコードへ向けた理想的な道筋がつけられる。

ソフトウェア・プロフェッショナル全般が、OSS の状況を理解し、エンタープライズ・グレードの成熟度を認識すべきである。また、セキュリティなどの領域をカバーする透明性という、独自の価値の提案を認識してもらうには、時間をかける必要があると思う。

すべての OSS が、同じように作られているわけではないが、プロプライエタリな製品と同レベルの回復力を持ち、テストが完了し、豊富な機能を持つ OSS が数多く存在している。その一方で、私たちが、エンタープライズ・レベルでの採用を増やしたいのであれば、OSS が生き続けてきた理由と、ビジネスに革命をもたらす方式について、より多くのストーリーを伝える必要がある。

セキュリティ強化で必要なことは? OSS 環境とパッケージ管理のソリューションが要求される品質は?

OSS 環境とパッケージ管理のソリューションにおいて、最も強力な品質の基準は、攻撃対象領域が最小限であること、相互運用性のレベル、セキュリティの維持と成熟の証拠だと考える。

攻撃対象領域を最小限に抑えることは、当然の要件である。セキュリティ・ツールが脅威アクターに与えてしまう攻撃ベクターとチャンスは、可能な限り少なくする必要がある。ただし、脅威アクターたちは常に進化しているため、それに対抗する新たなツールとテクノロジーを、CISO は常に模索している。特定のフレームワーク/スタック/ベンダーを選んだ結果として、長年にわたる契約や大規模な移行により、開発者の時間とリソースが消費されるという、不合理な決定には縛られたくない。

相互運用性も重要である。ツールと上手く連携させるだけではなく、また、大量かつ小型になりがちなパーツ/パッケージ/ライブラリを保護するだけではなく、スタック全体を、単一のエンティティとして保護したいからである。適切にコンフィグされていない Connector/API/Operator は、すべてを結びつける接着剤になれないだけではなく、悪意の人物が突破していく隙間にもなり得る。

最後に、セキュリティの維持と成熟がある。それは、少し難しい問題である。注目すべき点が曖昧となり、また、プロジェクトの各部分の合計で評価すべきものだからだ。それらの要素を挙げるなら、調整された脆弱性開示プログラムや、アクティブなメンテナーによるアクティブなコードベース、バグ追跡システム、堅牢なドキュメント、セキュリティ・パッチに関する明確な約束などがあるだろう。

多くの CISO が表明するのは、OSS の脆弱性に対する懸念である。OSS テクノロジーを組み込む際に、セキュリティ・リーダーはイノベーションとセキュリティのバランスを、どのように取るべきなのだろうか?

バランスを取ることが、きわめて難しいことは、当たり前のことである。ここで、1つ指摘しておきたい本質は、プロプライエタリ・コードと比べて、OSS に脆弱性が多いとは言えないことである。 OSS を使ってみれば、それを理解できる。 情報は力であるという言葉を私は信じており、使用しているものが持つリスクを理解していれば、リスクに対する姿勢を適切に管理できると考えている。もちろん、OSS における脆弱性の公開については、誰もが懸念を持つだろう。 OSS の責任ある使用と保守の鍵は、採用の計画に対するリーダーの綿密な検討にあり、また、十分に調査された上での意思決定にある。

採用のプロセスにおいて、最初に考慮すべきことは、選択したライセンスの種類について、明確な意図を持って徹底的に検討することである。可能であれば、そのオプションについて、法務チームと協力しながら検討に検討を重ねてほしい。 ライセンスの種類について、明確なポリシーを定義することは、実施すべき最初のフィルタリングであり、オプションに圧倒されるという幻惑に対抗する基礎になるだろう。そのため、CISO たちに常に推奨するのは、明確でシンプルな OSS 内部戦略ドキュメントの作成である。そこに記されるのは、現時点で使用している OSS と、使用しているライセンスの形態、受け入れるべきユースケースおよび基準と、制限事項などの概説である。

次に検討すべきことは、使用するツールに対して必要なサポートのレベルを知り、そのツールに対して提供されるサポートのレベルを知ることである。具体的に言うと、以下のような設問が必要になる。”コミュニティによるベスト・エフォート・モデルで十分なのだろうか?”、”それとも、より正式なサポート体制が必要なのだろうか?”、”それをサポートするコミュニティの規模は十分なのだろうか?” つまり、誇大なハイプ・サイクルの犠牲になって放棄されるものを排除し、ライフサイクル全体にわたって成長を享受できる、適切なツールを採用するための、適切な基準を知るべきである。

先進性と安定性の間には、多くのケースでトレードオフが生じる。バグが残っている可能性があることを承知で、最先端のものを使用するケースもあれば、安定したリリースを使用するケースもある。それは、ユースケースにより異なるものになる。ただし、そうだとしても、強い意志を持って選定すべきことであり、状況に合わないタイプのソリューションを入手してはならない。

OSSプロジェクトにおける脆弱性の開示/報告のメカニズムの設定は? 組織に推奨したい事項は?

最もお勧めしたいのは、明確でわかりやすいポリシー・レポートを作成することである。コミュニティとユーザーに対して明確にすべきことは、現時点におけるソリューションのセキュリティ体制について質問する相手を明示し、また、セキュリティ上の懸念を報告する窓口を明確にすることだ。また、情報伝達に関する 5W1H ついては、事前に大まかな期限を設定し、責任者を決定することも重要である。

2025 年に専門家が注目すべきものは?オープンソース・セキュリティの最近の傾向は?

私の大きな興味は、セキュリティに大きな影響を与える、きわめて魅力的なテクノロジーとしての、Confidential コンピューティングにある。Confidential コンピューティングでは、使用中のデータを暗号化できる。それは、一般においても興味深いことであり、また、AI に対して大きな影響を与える可能性を持つ。

AI には大きな人気があり、高度なプロジェクトやツールを、AI で構築する人も増えるだろう。それにつれて、必然的に新たな検討事項になるのは、”AI モデルを展開して安全に保つ方法” と “プライバシーを維持しながら共有データで AI モデルをトレーニングする方法” になる。

AI の存在は、開発者にとって大きな前進となるが、脅威アクターにとっても大きな前進である。次世代のサイバー・セキュリティ対策で必要とされるのは、新たな時代における、脆弱性と露出への対応であり、Confidential コンピューティングは、そのニーズに対する強力な答えになると、私は考えている。