PR
連載 [第17回] :
  月刊Linux Foundationウォッチ

Open SSFがOSSのセキュリティ体制を改善する「Alpha-Omega Project」を発表。マイクロソフトとグーグルが主体的に参画、ほか

2022年2月28日(月)
吉田 行男

こんにちは、吉田です。今回は、まず昨年12月から懸案事項になっている「Log4Shell」以降、オープンソースソフトウェア(OSS)のセキュリティ対策についての議論が進められている中、OpenSSF(Open Security Software Foundation)が発表した「Alpha-Omega Project」から紹介します。

OpenSSFがAlpha-Omega Projectを開始

OpenSSFは、ホワイトハウスでの政府および業界リーダーとの会合に続き、ソフトウェアセキュリティ専門家の直接関与と自動セキュリティテストを通じて、OSSのセキュリティ体制を改善する「Alpha-Omega Project」を発表しました。なお、マイクロソフトとグーグルは、このプロジェクトへの初期投資として500万ドルを拠出するとともに、専門家を派遣するなど、このプロジェクトに主体的に参画することになります。

【参照リリース】OpenSSF Announces The Alpha-Omega Project to Improve Software Supply Chain Security for 10,000 OSS Projects
https://openssf.org/press-release/2022/02/01/openssf-announces-the-alpha-omega-project-to-improve-software-supply-chain-security-for-10000-oss-projects/

この「Alpha-Omega Project」は、プロジェクトメンテナとともに、オープンソースコードに内在する未だ発見されていない新たな脆弱性を体系的に探し出し、修正することでグローバルなOSSサプライチェーンのセキュリティを向上させることを目的としています。「Alpha」は、最も重要なオープンソースプロジェクトのメンテナと協力して、セキュリティ脆弱性の特定と修正を支援し、セキュリティ態勢を改善することを目的としています。「Omega」は、広く展開されている少なくとも1万件のOSSプロジェクトを特定し、そのオープンソースメンテナコミュニティに対して、自動セキュリティ分析、スコアリング、修正指導を適用できるようにすることを目的としています。

Alpha Project:最も重要なOSSに焦点をあてる

最も重要なオープンソースプロジェクトをターゲットとして評価し、セキュリティ態勢の改善を支援します。プロジェクトは、OpenSSF Securing Critical Projectsワーキンググループ、OpenSSF Criticality Scoreやハーバード大学の「Census」分析、専門家の意見を基に選択されます。

支援内容は、脅威のモデル化、自動セキュリティテスト、ソースコード監査、発見された脆弱性の修正サポートなどがあります。また、OpenSSF ScorecardやBest Practices Badgeプロジェクトで概説されている基準から導き出されたベストプラクティスの実装も行うことができます。

ステークホルダーに主要なメトリックスを示すことで、依存するオープンソースプロジェクトのセキュリティについてより理解を促進します。プロジェクトのセキュリティ姿勢とセキュリティベストプラクティスへの準拠状況について、透明性のある標準化されたレポートを公開する予定です。

Omega Project:OSSプロジェクトのロングテールにフォーカス

Omega Projectは、少なくとも1万以上のオープンソースプロジェクトを対象にセキュリティ対策を支援します。

支援内容は、自動化された手法とツールを用いた、技術(クラウド規模の分析)、人(セキュリティアナリストによる発見内容のトリアージ)、プロセス(適切なOSSプロジェクトの関係者に重要な脆弱性を秘密裏に報告)を組み合わせていくことです。Omegaはソフトウェアエンジニアの専門チームにより、分析パイプラインを継続的にチューニングして誤検出率を低減し、新しい脆弱性を特定します。

この「Alpha-Omega Project」が成功することで、脆弱性が早期に発見されたり、セキュリティ対策が有効に機能することを期待したいと思います。

SBMOとサイバーセキュリティの現状の調査結果を発表

次に、SBOM(Software Bill of Materials)の現状について紹介したいと思います。こちらも「Log4Shell」問題で残っている大きな課題の1つです。Linux Foundationは、2月1日に「The State of Software Bill of Materials(SBOM) and Cybersecurity Readiness」(*2)を発表しました。

【参照リリース】The State of Software Bill of Materials (SBOM) and Cybersecurity Readiness
https://www.linuxfoundation.org/tools/the-state-of-software-bill-of-materials-sbom-and-cybersecurity-readiness/

まず、ほぼすべての組織がOSSを選択するにあたり最も懸念するポイントは「セキュリティ」で、「ライセンスコンプライアンス」が2番目であると回答しています(表1)。しかも、「セキュリティ」は「ライセンスコンプライアンス」のほぼ3倍ということで、とても重要視されていることがわかります。

表1:ソフトウェアの選択に影響を与えるポイント

# 項目 比率
1 セキュリティ 45.0%
2 ライセンスコンプライアンス 14.3%
3 低コスト 8.1%
4 法規制遵守と監査 6.5%
5 市場投入までの時間短縮 6.5%
6 信頼性 5.4%
7 パフォーマンス 4.6%
8 生産性の向上 3.8%
9 スケーラビリティ 3.5%
10 保守性 2.4%

今回の調査では、90%の組織が何らかの形でSBOMとの関りを持っていることがわかります。10%の組織はSBOMのための計画を開始しておらず、14%は計画または開発段階にあり、52%は事業のいくつかのまたは多くの領域でSBOMに取り組んでおり、23%は事業のほぼすべての領域でSBOMに取り組んでいるか、SBOMの使用を含む標準的なプロセスを制定しています。つまり、全体として75%の組織がSBOMへの具体的な準備態勢を整えていることになります(表2)。

表2:現在のSBOMへの対応状況は? (n=369)

# 項目 比率
1 SBOMへの対応は始まっていない 10.0%
2 SBOMにどう対応するかは計画中 6.5%
3 SBOMへの対応は始まったばかり 7.0%
4 ビジネスのいくつかのセグメントにおいてSBOMに取り組んでいる 14.4%
5 ビジネスの一部のセグメントでSBOMに取り組んでいる 20.9%
6 ビジネスの多くのセグメントでSBOMに取り組んでいる 14.4%
7 ビジネスのほぼすべてのセグメントでSBOMに取り組んでいる 13.3%
8 SBOMは、すでに標準的な業務の一環として使用している 8.7%

SBOMを作成することのメリットとして、51%の組織がSBOM によって開発者がより広範で複雑なプロジェクト間の依存関係を容易に理解できるようになると回答しています。マイクロサービスアプリケーションに多くのコンポーネントがある現在では、各コンポーネントはある程度の数の依存関係を持っています。SBOMは、その依存関係を明示的に特定できるため、アプリケーションの複雑さとコンポーネントの数が増えるにつれて、その有用性が増していきます。他にも、コンポーネントの脆弱性を監視しやすくなる(49%)、ライセンスのコンプライアンスを管理しやすくなる(44%)といったメリットも挙げられています(表3)。

表1:ソフトウェアの選択に影響を与えるポイント

# 項目 比率
1 より広範で複雑なプロジェクトにおける依存関係を開発者が理解しやすくする 51.6%
2 コンポーネントの脆弱性を容易に監視可能 50.4%
3 組織がライセンス義務を把握し、遵守することが可能になる 45.8%
4 end -of-lifeを迎えた部品の代替品を積極的に特定することが可能になる 40.6%
5 コンポーネントの使用状況を追跡することで、禁止コンポーネントの「拒否リスト」や優先コンポーネントの「許可リスト」をサポートすることが可能 38.0%
6 コンポーネントの使用状況を容易に把握できるようになり、コードの肥大化が抑制される 37.8%
7 顧客の法的やセキュリティ上のニーズを満たす高品質な製品の提供を支援する 36.9%
8 コードベースの可視性を向上させ、予定外の作業を削減 32.3%
9 コンポーネントを追跡することで、コードのレビューが容易に 27.7%
10 監査が行われた場合の大きなビジネスの混乱を回避 14.1%
11 わからない・よくわからない 7.5%
12 SBOMの作成は予定していない 6.9%
 

とはいえ、表4のように、業界として義務付けることやコンセンサスの状況、顧客への提供価値など、まだまだなSBOMの作成に関する懸念もあります。

表4:SBOMを作成上で、どのような懸念がありますか? (n=341)

# 項目 比率
1 業界としてSBOMを義務付けることを確約しているのか、それとも任意なのか不明 40.2%
2 SBOMが何を含むべきかについて、業界のコンセンサスが得られているかどうか不明 38.7%
3 SBOMを提供することで、顧客にどのような価値を提供できるのかがわからない 36.7%
4 SBOMの作成を自動化するツールがあるかどうか不明 33.7%
5 自分たちが作ったソフトウエア内のコンポーネントを他人に知られたくない 27.9%
6 SBOMが意図せず不正確または不完全な場合、何が起こるかわからない 21.4%
7 わからない・よくわからない 21.4%
8 SBOMの作成は予定していない/td> 8.8%

このように、懸念事項もありますが、セキュリティに対する世界的な取り組みとしてのSBOMへの動きを今後ともウォッチしておく必要があるように思います。

2000年頃からメーカー系SIerにて、Linux/OSSのビジネス推進、技術検証を実施、OSS全般の活用を目指したビジネスの立ち上げに従事。また、社内のみならず、講演執筆活動を社外でも積極的にOSSの普及活動を実施してきた。2019年より独立し、オープンソースの活用支援やコンプライアンス管理の社内フローの構築支援を実施している。

連載バックナンバー

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています