ニュース
シノプシス、オープンソースのセキュリティ／リスク分析レポート 2022年版を公開
OSSの脆弱性に関する傾向や大きな話題などを解説
2022年5月20日 06:00
日本シノプシス合同会社は19日、「2022 オープンソース・セキュリティ＆リスク分析（OSSRA：Open Source Security and Risk Analysis）レポート」を公表した。米Synopsysが4月に公表したレポートの日本版にあたる。
OSSRAレポートは、SynopsysのBlack Duck監査サービス部門がM&A取引におけるソフトウェアの監査を担当した調査結果を、Synopsys Cybersecurity Research Center（CyRC）が分析し所見をまとめたものだ。
レポートでは、OSSを含むコードベースがほとんどであることや、脆弱性の割合は増加していたが2021年には少し改善されたこと、ライセンス競合も減少したこと、ライセンス設定されていないOSSの問題などが報告されている。
同日、OSSRAレポートの内容を紹介する記者発表会が開催され、日本シノプシス合同会社の吉井雅人氏（ソフトウェア・インテグリティ・グループ シニア・セキュリティ・エンジニア）が解説した。
OSSを含むコードベースが97％
前述のとおり、OSSRAレポートはBlack Duckが監査した内容が元になっている。吉井氏はまず、2021年はテクノロジー／テレコム業界で買収が活発で、2020年と比較しても倍増していることを紹介した。
Black Duckが2021年に監査したコードベースの数は2409で、買収件数と同様に増えている。このうち、リスク診断を受けたコードベースは87％にあたる。
全体の概要としては、オープンソースソフトウェア（OSS）を含むコードベースの割合は97％と、ほぼすべてだった。また、全コードベースに占めるOSSの割合は78％だった。
OSSRAレポートは、こうした中のオープンソースのリスクについて分析している。レポートではリスクとして、1つでも脆弱性が含まれるリスクの「脆弱性のリスク」、ライセンス違反の「ライセンスのリスク」、コードが更新されない「メンテナンスのリスク」の3つを挙げている。
リスク診断を受けたコードベースのうち、脆弱性のリスクがあったものが81％、ライセンスのリスクがあったものが53％、メンテナンスのリスクがあったものが85％だったと、吉井氏は報告した。
脆弱性の割合は2021年には改善
まずは脆弱性のリスクだ。脆弱性を含むコードベースの割合は、2018年から2020年まで増加していたが、2021年は若干だが改善されて81％となった。高リスク脆弱性を含むコードベースの割合も、同様に増加から改善されて49％となった。
2021年に改善した原因について吉井氏は、2020年にはコロナ禍でセキュリティ予算にしわ寄せが来たことと、2021年には米バイデン大統領による国家のサイバーセキュリティ改善に関する大統領令において、SBOM（Software Bill of Materials：ソフトウェア部品表）を整備しようという方針が示されたことによるのではないか、と推測した。
コードベース1つあたりのコンポーネント数の平均と、コードベース1つあたりの脆弱性の数の平均も、急増していたのが2021年には減少している。吉井氏は、コンポーネント数については1つのアプリケーションのサイズに上限があるので頭打ちになったのではないかと推測。脆弱性についてはコンポーネント数より減った割合が大きく、やはり前述の大米統領令の影響ではないかと語った。
OSS作者による破壊行為やLog4jの脆弱性のリスク
ただし2021年には、OSSの脆弱性で大きな話題が2つあった。1つめは、JavaScriptの人気OSSライブラリであるcolor.jsとfaker.jsの作者自身が、自らのコードを破壊した事件だ。主に金銭的な還元が得られないことへの不満とされており、「オープンソースのエコシステムについてあらためて考えさせられる出来事だった」と吉井氏はコメントした。
もう1つは、JavaのロギングソフトであるLog4jの脆弱性であるLog4Shellの問題だ。Log4Shellは、旧バージョン（Log4j1）から作り直されたバージョン（Log4j2）の開発当初からあった脆弱性で、Log4j1には影響しない。ただし、Log4j1はEOL（End of Life、サポート終了）となっているため、別の脆弱性が残っていて危険だと吉井氏は指摘した。
Log4jについては、Black Duckのデータベースへのアクセス数のデータ（2021年12月～2022年2月）も吉井氏は紹介した。Log4Shell脆弱性は2021年12月に公表され、その月のうちに対策したLog4j 2.16と2.17がリリースされた。アクセス数を見ると、特に2.17.1が急激に増えており、安全なバージョンに切り替えていっていることが分かる。
その一方でLog4j1が大きく残っていることを吉井氏は指摘。互換性がないため移行がなかなか進んでいないのだろうと推測して、これも脆弱性のリスクの1つだと語った。
ライセンス競合は減少しているが、Stack Overflow問題も
続いて、ライセンスのリスクだ。ライセンス条件の競合（違反）が見付かったコードベースの割合は減少傾向にあり、2021年はさらに大きく減少して53％だった。これについても米大統領令の影響ではないかと吉井氏は語った。
また、ライセンスがない、またはカスタムライセンスを使用したオープンソースを含むコードベースの割合は毎年上下しており、2021年は30％だった。ライセンスの記載がないOSSについて吉井氏は「何ができるかすべて著作権者に確認しないといけないので、事実上、著作権を違反せずに使えない」とそのリスクを説明した。
ライセンス条件の競合で最も多かったのが、Creative CommonsのAttribution Share Alike（CC BY-SA）3.0の17％だった。これはつまり、開発者向けQ＆AサイトStack Overflowからの一部コピーで、コードによってはコメントに参考URLが記載されていることもある。Stack Overflowに投稿されたコードにはCC BY-SAのライセンスが設定されており、ライセンス条件が継承されるため、オープンソースのライセンスとしては厳しいものだと吉井氏はコメントした。
メンテされていないOSSコンポーネントも多いが若干の改善
3つめはメンテナンスのリスクだ。過去2年間に新たな開発活動実績のなかったコンポーネントを含むコードベースの割合は88％で、4年以上前の旧バージョンのオープンソースを使用しているコードベースの割合も85％となる。いずれも高い数値だが、2021年に若干の改善傾向にあり、これも大統領令の影響ではないかと吉井氏は推測した。
とはいえ、メンテナンスは今後も注意が必要だ。color.js作者のケースで問題が表面化したように、支援を受けられずに開発しているケースが多いと吉井氏は指摘する。コード行数の90％超を10人未満の開発者が担当しているプロジェクトが94％で、コード行数の80％を1人の開発者が担当しているプロジェクトが23％という数字を氏は紹介し、「そういうところに企業も支援やフィードバックをしていかなければいけない」と語った。
また、サポートが終了してEOLとなったプロジェクトも、利用側がそれに気付かずに問題になることも多いという。例として、requestというプロジェクトでは、EOL告知時点で5万2446件だった依存プロジェクトが、6カ月後には5万3583件と逆に増えていたこと、約2年後にようやく気付いたプロジェクトもあったことを吉井氏は紹介。EOLに気付くことも難しいと吉井氏は語った。
成熟したOSS利用の形態
最後に吉井氏は、これらの分析をふまえて「OSSは不可欠だがリスクもある」として、その対策について述べた。
一番単純なOSS利用形態は、公開リポジトリからダウンロードして直接使うというものだ。それに対して、有償のソフトウェアを利用するときには、調達時にチェックしたうえで社内のリポジトリに入れて使う。吉井氏は「OSSではなぜそれをやっていないのか」として、セキュリティやライセンスのリスクを考えたうえで、ポリシーに一致したものを社内リポジトリに入れて使う形態を、成熟したOSSの利用として説明した。
以上のまとめとして吉井氏は、「ソフトウェアに利用しているすべてのコードを把握する」こと、サプライヤーのコードにもOSSが含まれていることがあるので「開発ワークフローに対して脅威モデリングを実施する」こと、大量のOSSコンポーネントの管理を自動化しSBOMを常に最新の状態に維持するために「OSSの管理を開発プロセスにインテグレート」することを推奨した。
さらに、OSSがEOLになってしまうと不利益を被りビジネスリスクとなるため、還元や投資など「ビジネスを支えているオープンソースプロジェクトを支援する」ことを提案した。
