OSPOのセキュリティ進化：オープンソースのキューブラー＝ロスモデル

OSPOとは何でしょうか？ Open Source Program Officeが各地で設立されています。これは、オープンソースソフトウェア（そしてオープン標準も同様だと私は考えます）が、地球をますます動かすソフトウェアの構築と保守において、大きな役割を担っているという現実を反映したものです。Linux FoundationのレポートOpen Source Program Office（OSPO）の進化では、OSPOの発展を5つの段階に分けています。

• ステージ0：場当たり的にオープンソースを採用する

• ステージ1：OSSコンプライアンス、インベントリ、開発者教育を提供する

• ステージ2：OSSの活用とエコシステムへの参加を推進する

• ステージ3：OSSプロジェクトをホストし、コミュニティを成長させる

• ステージ4：戦略的な意思決定のパートナーとなる

ただし、セキュリティに関しては、異なる5つの段階（キューブラー＝ロスモデルになぞらえて）で考えると、より理解しやすいかもしれません。

• 否認：組織は、オープンソースにどれほど依存しているかを認めようとしません。自分たちは把握していると思っていても、実際に考え始めると、さまざまなオープンソースコードやツール、特にビルドパイプラインでどれほど大きく活用しているかに気づきます。同じことは2022 Snyk Open Source Security Reportでも確認できます。

• 怒り：これまで注意を払ってこなかったため、組織は自分たちがどれほどのオープンソースコードを使っているのかさえ把握していません。この怒りが（願わくば）学習やオープンソースプロジェクトの把握に向けた取り組みを促し、OSSが組織の中核を担っていることへの理解を深めます。

• 取引：この段階では、組織が対話を始め、OSSコミュニティに働きかけます。多くの場合、場当たり的な参加を通じて培われた知識を活用し、その参加を一貫した戦略へと発展させていきます。

• 抑うつ：この段階では、組織の他部門もOSPOの価値に気づき始め、現実味を帯びてきます。それは素晴らしいことですよね？ 残念ながら、OSSの依存関係が組織全体にリスクをもたらすという認識が生まれるのも、またこの段階です。特に、セキュリティ脆弱性を考慮すると、そのリスクは無視できません。

• 受容：オープンソースのエコシステムの中で生きていることを完全に受け入れるには、そのエコシステムでリーダーシップを発揮する方法を学ぶ必要があります。また、OSPOはオープンなエコシステムの優れた取り組みを推進するだけでなく、セキュリティの優れた取り組みを推進する役割も担うと受け入れることが必要です。

さて、ここまでの話は少し無理があるかもしれません。言いたいのは、オープンソースは今後もなくならないということです。オープンソースは、ソフトウェアの大半、特に私たちが日常的に使うソフトウェアの構築と保守において、非常に重要な役割を果たしています。オープンソースを利用することは、品質の向上と運用コストの削減と引き換えに、コミュニティへ一定の主導権を委ねることを意味します。この事実を受け入れ、コミュニティでリーダーシップを発揮し始める組織が、市場をリードする存在になるでしょう。そして、その重要な要素の一つがセキュリティです。

では、OSPOはオープン性の推進役であるだけでなく、セキュリティの推進役としての役割も効果的に果たすには、どうすればよいでしょうか？ まず、セキュリティの専門知識をOSPOチームに取り入れることです。ソフトウェアサプライチェーンの課題に詳しいセキュリティ専門家をチームに加えましょう。Open Source Security Foundationの「End User」ワーキンググループに参加すれば、同様の組織と安全な場で情報を共有できます。

Open Source Security Foundation（OpenSSF）が公開したばかりの資料が、取り組みを始めるうえで最適です。

• より安全なソフトウェアを開発するための簡潔なガイド

• オープンソースソフトウェアを評価するための簡潔なガイド

• NPMのベストプラクティスガイド

これらのOpenSSFのリソースは、オープンソースセキュリティに関する難しい課題について考え始める助けになります。組織の規模を問わず、OSPOやOSPOに相当する機能を構築している方なら、これらのガイドで取り上げている課題にすぐ心当たりがあるでしょう。組織ではおそらくnpmを利用し、GitHubなどのソースコード管理システムにコードを置き、さまざまな提供元から、ライセンスや由来の異なるオープンソースソフトウェアを利用しているはずです。これらの課題はすべてガイドで扱われており、さらに詳しい情報へのリンクも掲載されています。

次に、OSPOはこれらの課題に先手を打つため、セキュリティ人材を採用するか、セキュリティの専門家を招く必要があります。開発、ビルド、デプロイのプロセスで、ソフトウェア部品表（SBOM）について考え始めましょう。Liran TalのSBOMに関する優れたブログ記事が、取り組みの参考になります。

余談ですが、政府機関にOSPOの設置を求める、政府サービスの開発・運用で使われるオープンソースソフトウェアのセキュリティ確保を目的とした米国の法律が成立したことは、興味深く、喜ばしいことです。

安全でオープンな2023年に乾杯