米CISA「既知の悪用された脆弱性のカタログ」
米国土安全保障省のサイバーセキュリティ・インフラセキュリティ庁（Cybersecurity & Infrastructure Security Agency、以降CISA）は、2021年11月に「既知の悪用された脆弱性のカタログ（Known Exploited Vulnerabilities Catalog）」を公開しました。
・CISA Known Exploited Vulnerabilities Catalog
https://www.cisa.gov/known-exploited-vulnerabilities-catalog
これは実際に攻撃者が積極的に悪用していることが確認されており、対応が急がれる脆弱性を列挙したもので、掲載されている項目は以下の9つ、カタログ自体はCSV形式とJSON形式でも提供されています。
- CVE番号
- ベンダー／プロジェクト名
- 製品名
- 脆弱性の名前
- カタログに加えられた日
- 脆弱性の概要
- 取るべきアクション
- （連邦政府機関の）対応期限日
- 備考（CISAによる参考文献など）
登録されている脆弱性は以下のように適宜追加されています。
| 2021年11月3日（初版） | 287 |
| 2021年11月17日 | ＋4 |
| 2021年12月1日 | ＋5 |
| 2021年12月10日 | ＋13 |
| 2021年12月15日 | ＋2 |
| 2022年1月10日 | ＋15 |
| 2022年1月18日 | ＋13 |
| 2022年1月21日 | ＋4 |
ちなみに、2021年12月に公になった「Apache Log4j」の脆弱性、いわゆる「Log4Shell」（CVE-2021-44228）は、2021年12月10日にカタログに加えられ、対応期限は2021年12月24日とされていますが、その後、同年12月17日付でCISAは即時対応せよとの緊急指令を出しています。
2022年1月21日時点で登録されている343件の脆弱性を製品のベンダー（またはプロジェクト）ごとに分類すると、最も多いのは当然ながら圧倒的にMicrosoft（85件＋ベンダー／プロジェクト名：Windows 2件）で、他にはGoogle（24件＋ベンダー／プロジェクト名：Android 3件）、Apple（23件）、Apache（16件）、Cisco（11件）、VMware（10件）、Oracle（9件）といった日本でもメジャーなベンダーなどが多くを占めています。しかし、そもそも基本的には米国の連邦政府機関を対象としたカタログなので、日本ではメジャーでなくても、連邦政府機関では使われているとみられる製品ももちろん含まれています。
ところで、このカタログで最も注目すべきは登録されている脆弱性が最近のものばかりではないという点です。CVE番号が振られた年ごとにまとめると以下のようになります。
| 2006年 | 1件 |
| 2010年 | 2件 |
| 2012年 | 3件 |
| 2013年 | 1件 |
| 2014年 | 1件 |
| 2015年 | 3件 |
| 2016年 | 10件 |
| 2017年 | 15件 |
| 2018年 | 21件 |
| 2019年 | 52件 |
| 2020年 | 101件 |
| 2021年 | 133件 |
全体から見ればごくわずかですが、10年以上前の脆弱性も登録されています。古い脆弱性が更新されないまま長く放置されていることが珍しくない実態を表していると言えるでしょう。
このカタログは基本的に米国の連邦政府機関を対象としたものなので、この内容そのままで日本の企業や組織における脆弱性対応の何らかの基準として使えるものではありません。それでも、CVSS基本値のような脆弱性そのものの技術的な深刻度ではなく、実際に悪用が確認されている脆弱性という観点で収集されている点は重要で、日本の企業や組織においても何らかの参考資料としては十分に使えるはずです。うまく活用してください。
Apache Software Foundationによる脆弱性対応のポジションペーパー
2021年12月に公になったApache Log4jの一連の脆弱性問題に絡み、米ホワイトハウスは2022年1月13日にオープンソースソフトウェア（以降OSS）のセキュリティについて議論する会合を開き、Apache Software Foundation、Google、Apple、Amazonなど、IT系の主要な企業や組織から関係者が参加しました。この会合での議論を踏まえ、参加者からは官民の連携や重要なオープンソース資産の特定などが呼び掛けられています。この呼び掛けの詳細については以下の記事を参照してください。
この会合に先立ち、Apache Software Foundation（以降ASF）は2022年1月10日にポジションペーパー（立場表明書）を公開し、ASFとしての脆弱性対応の考え方や体制などを説明しました。今回はこの文書を紹介します。
まず、「Executive Summary/Key Take-Aways」として挙げられているのは以下の3点。
1.オープンソースのサプライチェーンの問題は上流製造者だけに焦点を当てても解決しない
・完璧なリリースであっても、下流のプロバイダーが採用し、展開するまでに何年もかかることがある
2.コミュニティは姿を現して仕事をする人たちによって定義される
・オープンソースを製品に組み込んでいる企業は、その継続的なメンテナンスに参加することはほとんどない
・ASFは共同メンテナンスと開発のための中立的なフォーラムを提供することで、作業を行う個人（多くの場合、雇用主によって支援されている）に力を与えており、20年以上にわたってソフトウェアプロジェクトを効果的に維持することが示されている
・しかしながら、（自社製品内で同じコードを再利用している）下流の企業の中で参加を選択しているのはごく一部である
・セキュリティ指令（directive）は、既に作業をしている少数のメンテナーに財源付与のない負担をさらにかけることを避けなければならない（MUST）
3.脆弱性が単一のコンポーネントに限定されることはほとんどない
・最近のApache Log4jの脆弱性は、Javaプラットフォーム内で独自に設計された機能が不幸にも組み合わさってしまったものある
・少なくともデフォルトの設定で、時代遅れで不要な機能を無効にしていれば、脆弱性を防げたはずである
・安全でないオペレーションの間接的な起動を防ぐためにプラットフォームのセキュリティを改善することは、非常に大きな勝利につながる可能性がある
ASFによるプロジェクトセキュリティへの取り組みについては以下のように説明しています。
1.ASFの各プロジェクトは、プロジェクトに取り組むことで功績をあげた個人たちで構成されるプロジェクト管理委員会（Project Management Committee、以降PMC）によって運営されている
・PMCのメンバーは技術開発やリリースに関する自分たちのコミュニティの意思決定を一括して管理する
・プロジェクトは商標、リリースの作成、報告されたセキュリティ脆弱性の処理など、財団全体の様々なポリシーを遵守する
・ASFのポリシーでは新しいリリースに対して必要とされる最低限のレベルの投票を伴うPMCによるレビューを必要とする
・プロジェクトのソースコードに対する変更はトラッキングされ、全ての関係者が見ることができる
2.ASFにはセキュリティチームと役員（board）の権限で活動するセキュリティ担当VP（Vice-President）が存在する
・ASFのセキュリティチームは、共通のポリシーを設定し、PMCのセキュリティ連絡先を維持し、セキュリティ問題に対応するプロジェクトを支援する
・全てのプロジェクトにわたって全ての脆弱性についてのメタデータを一貫性のある機械可読な方法で公開する
3.重要な脆弱性に直面した場合、公開前に脅威を軽減することを目指している
・最初の報告は責任ある開示のためのルールに基づいて非公開で処理される
・問題が公表されると、注目を集めることでさらなる問題が発見されることがよくある
・たとえ複数回のリリースが必要であっても、迅速にリリースし、迅速に修正することを目指している
ASFとしての25年以上にわたる脆弱性対応の経験を踏まえ、推奨事項として以下の4点を挙げています。
1.オープンソースを利用する企業はどのようなコンポーネントが利用されているかを理解し、脆弱性が発見された場合に迅速に対応できるように準備しておく必要がある
2.オープンソースを利用するビジネスができる最も価値のあることの1つは貢献し返すことである
3.オープンソースプロジェクトは重大なセキュリティ問題が公開された後には機械可読なセキュリティメタデータを迅速に公開することを優先すべきである
4.重要なコンポーネントを特定するとの考えを支持する
Log4jの一連の脆弱性問題をきっかけに、セキュリティの観点からOSSの使用を見直す動きもあるようで、それ自体は仕方ないと思える部分もある一方、そもそもOSSは「無保証であり、自己責任で使うもの」との大前提が完全に忘れられているように思えてなりません。
今回のASFの文書は「ASFは脆弱性対応としてやれることはやっている」「OSSを使うなら、何をどこで使っているのかを把握すべきである」「OSSに（タダ乗りするのではなく）何らかの形で貢献してほしい」と訴えるものになっています。もちろん「ASFとして他にもやることはあるだろう」との意見もあるでしょうし、そう言いたくなる気持ちは十分に理解できるのですが、「あれをやるべき」「これをやるべき」などと言い出せばキリがなく、世の中に数あるOSSのプロジェクトの中では、ASFは「頑張っている」方であることは確かです。また、「何をどこで使っているのかを把握すべき」なのはOSSに限らず、当たり前のことであり、さらに「貢献してほしい」との訴えもOSSとしては当然のこと。しかし、そのような当たり前のことを改めて丁寧に文字にして説明しなければならないほど、世の中の多くの人々が「知らない」もしくは「忘れてしまっている」ということなのでしょう。
とにかく、OSSを単なる「タダで使えるもの」と考えて安易に使うのではなく、使うのであれば、無保証のソフトウェアをどのように運用・保守していくのかをあらかじめ十分に検討しておく必要があるのはもちろん、開発元への何らかの形での貢献、フィードバックも忘れてはなりません。この「貢献」こそがOSSのセキュリティ向上につながるのですから。
