以下はThe Hacker Newsの記事、Last Years Open Source - Tomorrow's Vulnerabilitiesの紹介です。
The Hacker NewsとHacker Newsのちがいはなんなんだろ？
Last Years Open Source - Tomorrow's Vulnerabilities
LinuxとGitの生みの親であるLinus Torvaldsは、ソフトウェア開発において独自の見識を持っています。
「十分な目玉さえあれば、どんなバグも深刻なものではない。」
このフレーズはオープンソースの神髄を言い当てているでしょう。
もし、誰でもコードを簡単に利用できて、誰でもバグの修正をできるなら、それは安全だと。
しかし、それは本当でしょうか？
全てのバグは底の浅いものであるというのは、底の浅いバグにのみ当てはまるものであり、底の深いバグには当てはまらないのではないでしょうか？
オープンソースにおけるセキュリティ上の欠陥は、思ったより見付け辛いものであることがわかりました。
Debrickedの研究開発長であるEmil Wåreusは、コミュニティのパフォーマンスを調査することにしました。
データサイエンティストでもあった彼は、もちろんデータに尋ねました。
オープンソースコミュニティの、脆弱性を発見する能力はどんなものだい？
The thrill of the (vulnerability) hunt
メンテナ、ユーザ、監査人、そして外部のセキュリティ研究者などが常日頃からオープンソースの脆弱性を探しています。
しかし、多くの目玉が世界の安全を守ろうとしているのにもかかわらず、コミュニティはセキュリティ上の欠陥を見つけ出すことに苦労し続けています。
オープンソースプロジェクトにおいて、脆弱性が発見されるのにかかった時間は、平均して800日以上です。
たとえば悪名高いLog4shell(CVE-2021-44228)に至っては、なんと2649日も隠れ続けていました。
分析によると、脆弱性の74%は、少なくとも1年間は発見されません。
JavaとRubyは、脆弱性の発見に1000日以上かかっており、大きな課題があるようです。
PHP/Composerは他のコミュニティより良好なレスポンスであり、これには我々も脱帽です。
The needle in a techstack
その他の興味深い要素として、脆弱性の種類によっては発見が困難なタイプもあるようです。
そしてこれは、実はLinusの法則に反しています。
共通脆弱性タイプCWE-400適切でないリソース消費制限やCWE-502信頼できないデータのデシリアライゼーションなどは、脆弱性の範囲が単一の関数に収まるとは限らず、またロジックとして意図されたものである可能性もあります。
すなわち、底の浅いバグとは言い切れないということです。
また、開発者コミュニティはCWE-20適切でない入力確認を見付けるのは得意なようですが、これはだいたいの場合単一関数内の数行のコードに過ぎません。
Solve vulnerabilities with powerful remediation
オープンソースの消費者、すなわち世界中のほぼすべての企業にとって、オープンソースの脆弱性の問題は重要な問題です。
オープンソースが他のソフトウェアより安全ではないからではなく、全てのバグが浅いわけではないからです。
データが告げていることは、Linusの法則は完全に信用できるものではないということです。
幸いなことに、多くのオープンソースプロジェクトを一気に分析する強力なツールも存在します。
それらの手法を用いて一度に1000件もの脆弱性を発見した白馬の騎士ハッカーも登場しました。
心無い組織や個人が同じことをしでかさないと思うのは甘い考えです。
ソフトウェアを中心とした世界の礎となるエコシステムになるために、コミュニティはオープンソースの脆弱性を発見、開示、修正する能力をもっと向上させなければなりません。
昨年Googleは、オープンソースの安全性を確保するため、セキュリティ対策に取り込むオープンソースファンドに100億ドルを出資しました。
またDebrickedは、オープンソースソフトウェアを提供する企業について、全てのbranch、全てのpush、全てのcommitについて脆弱性をスキャンすることを支援します。
さらにDebrickedは、最新のインテリジェンスを提供するために、新しい脆弱性が発見されるたびに全ての古いcommitについても調査を行います。
Debrickedは、脆弱性対応が依存関係の連鎖を引き起こさないようにプルリクエストを自動修正することでも支援します。
The truth lies in the data
さて、これらのことを知ったうえで、あなたのプロジェクトや組織をオープンソースの脆弱性から守るためにできる最良の方法は何でしょうか？
Log4jやSpring4shellの例を見てもわかるように、コミュニティが全ての問題を速やかに発見して修正してくれるとは限りません。
あなたのコードには、現在発見されていない、現在公表されていない、脆弱性が潜んでいる可能性があり、そしてそれに対してあなたができることはあまりありません。
Debrickedによると、これを軽減する最もよい方法は、ソフトウェア開発ライフサイクルに継続的な脆弱性スキャンを組み込むことです。
機械学習も利用した脆弱性データベースと組み合わせ、コードをpushするたびに自動スキャンすることで、脆弱性を発見できる可能性が高まります。
脆弱性データベースがリアルタイムで更新されることにより、新しい脆弱性を誰よりも早く知ることができます。
問題があればすぐに修正されたpull requestを自動生成するほか、手動で生成することも可能です。
現在、DebrickはJavaScriptとGoについてこの機能を提供しており、他の多くの言語についても近日中に提供する予定です。
感想
途中まで読んで参考になりそうだなあと思って訳し始めたら後半見事にDebrickedの宣伝だった。
非記名記事なので誰が書いたかわかりませんが、やはり中の人なんですかね。
まあ宣伝はともかく、実際に謳い文句どおりの性能なのであれば、けっこう有用な脆弱性発見ツールなのではないでしょうか。
また分析対象について、なぜPHPだけPHP本体ではなくComposerなんだろう。
と思ってよく見てみたら他言語も実はJavaやRubyではなく、mavenやgemが調査対象でした。
JavaはともかくPHPやRubyは言語もOSSなんだから、言語本体も調べてみてほしいところです。
しかしそれにしても、脆弱性が見つかるまでに平均2年以上もかかっているというのはびっくりですね。
ゼロデイどころの話ではないですよ。