グローバルデータに基づくDevSecOpsの“7つの考察”

9割のJavaサービスにサードパーティ由来の脆弱性 ― Datadogレポート

2024年06月10日 16時30分更新

文● 福澤陽介／TECH.ASCII.jp

　Datadog Japanは、2024年6月4日、DevSecOpsの現状を明らかにする調査レポート「State of DevSecOps 2024」を発表した。

　本レポートでは、2024年2月から4月までに収集されたグローバルのデータに基づき「7つの考察」を示している。

　Datadog Japanのシニアデベロッパーアドボケイトである萩野たいじ氏は、「昨今、データ侵害や重大な脆弱性に関するニュースが続いており、安全なコードを迅速かつ大規模に配布することは、ソフトウェア業界全体の課題になっている。これに対応すべく加速しているのが、DevSecOpsの採用だ。Datadogは、独自の調査と仮説に基づいて、DevSecOpsの課題ついて分析した」と説明する。

Datadog Japan シニアデベロッパーアドボケイト萩野たいじ氏

その1：サードパーティの脆弱性の影響を最も受けるのはJavaサービス

　考察のひとつ目は、開発言語別の脆弱性が含まれるサービスの割合だ。言語別に、サードパーティ製ライブラリによってもたらされた重大な脆弱性が含まれるサービスの割合を分析。その結果、Javaベースのサービスが90%と、群を抜いてサードパーティの脆弱性の影響を受けていることが分かった。他言語の平均値は47%だった。

　萩野氏は「Javaサービスは、攻撃者が過去に悪用した脆弱性の影響を受けやすい」と説明する。実際に米国のCISA（サイバーセキュリティー・インフラセキュリティー庁）の脆弱性のカタログにおいても、Javaサービスの55%が脆弱性の影響を受けており、他言語のサービスは7%だという。

クリティカル・高リスクの脆弱性が含まれるサービスの割合（言語別）

　Javaサービスに脆弱性の多い理由は、TomcatやSpring Framework、Apache Struts、Log4j、ActiveMQなど、一般的なJavaライブラリに脆弱性が存在することによるとDatadogは分析する。

　これは、Javaサービスにおける脆弱性の発生源のうち63%が「間接的な依存関係」、つまりアプリケーションに組み込まれたサードパーティライブラリであることからもみてとれる。

　萩野氏は、「間接的な依存関係においては、脆弱性を含むライブラリが気づかない内に追加されることが多い。アプリケーションの脆弱性をスキャンする際には、依存関係のツリー全体を考慮することが重要。また、依存関係を適切に管理するためには、OpenSSF Scorecardといったフレームワークが役に立つ」と強調した。

Javaサービスにおけるサードパーティの脆弱性のソース

その2：セキュリティスキャナーからの攻撃試行は、大半が対応不要なノイズ

　続いては「セキュリティスキャナー」からの攻撃試行についてだ。各言語で開発されたアプリケーションに対するエクスプロイトの試行について分析した結果、セキュリティスキャナーからによるものが多数を占めていたという。セキュリティスキャナーとは、インターネット全体をスキャンして、脆弱なシステムを特定するために用いられるオープンソースツールで、NucleiやZGrab、SQLmapなどが挙げられる。

　一方で、セキュリティスキャナーにより自動化されたセキュリティスキャンから、実際に悪用された脆弱性はわずか0.0065％だったという。「生のWebサーバーのログやWAFのアラートを効率的に監視するためには、順位付けのための強力なフレームワークが不可欠なことを示している」（萩野氏）。

セキュリティスキャナーからのリクエストで悪用された脆弱性の割合

その3：優先すべき脆弱性はごく一部

　そもそも、脆弱性が特定された場合にどこまで対応すべきか。ある学術研究によると、攻撃者によって実際に悪用される脆弱性は「全体の約5%」に過ぎないという。

　Datadogは、エクスプロイトが成功する可能性やその影響を評価するために、脆弱性を分析し、かつ対象サービスがインターネットに公開されているかなどの追加要因に基づいてスコアを算出。EPSSという脆弱性対応の優先度を示す指標も考慮して、脆弱性の重大性を評価した。このスコアリングに基づくと、重大な脆弱性を抱える6割の企業は、脆弱性を優先的に対処する必要がないという結果が得られたという。

独自のスコア調整した後に重大な脆弱性が残っている組織の割合

その4：コンテナイメージは小さいほど脆弱性が少ない

　続いては、軽量なコンテナイメージは脆弱性を減らすという見解だ。「ソフトウェア開発とセキュリティ、どちらにおいても対象となるリソースは少ない方が良いとされており、これはコンテナベースイメージなどのサードパーティの依存関係にも当てはまる」と萩野氏。

　通常、コンテナのベースイメージには、Ubuntuなどの古典的なLinuxディストリビューションをベースにした大きなイメージ、Alpine LinuxやBusyBoxなどの軽量ディストリビューションをベースにしたスリムなイメージ、もしくはアプリケーションの実行に必要な最小限のランタイムのみを含むdistroless imageといった選択肢がある。

　何千ものコンテナイメージを分析した結果、コンテナイメージが小さいほどサードパーティライブラリが少なく、その分脆弱性も少なくなることが分かったという。具体的には、100MB未満のコンテナイメージでは重大リスクの脆弱性は平均4.4件にとどまる一方で、500MB以上だと平均80件近くに増大する。コンテナ化された環境においては、軽量なイメージを使用することが攻撃対象領域を最小限に抑える手法であることを示している。

コンテナイメージサイズ別の脆弱性の数

その5：IaCの実践率はGoogle CloudよりAWSが高い

　続いては、コードとしてのインフラストラクチャー (IaC) についてだ。IaCという考え方は、1990年代にCFEngine、Puppet、Chefなどのプロジェクトによって導入されたといわれ、パブリッククラウドが普及するにつれ、クラウド環境をプロビジョニングするためのデファクトスタンダードとして広まった。

　レポートによると、AWSではTerraformやCloudFormation、PulumiなどのツールでIaCを実践している企業が71%以上だったのに対して、Google CloudではIaCツールを用いた実践率は55%にとどまる。なお、Azureに関しては「アクティビティログが HTTPユーザーエージェントを記録しないため、分析できていない」（萩野氏）。

　なお、最も人気のあるIaCツールはTerraformで、AWSが独自のCloudFormation、Google Cloud独自のGoogle Deployment Managerよりも多く採用されていた。

AWSでのIaCの実践率

Google CloudでのIaCの実践率

その6：手作業によるクラウドのデプロイ“ClickOps”はまだまだ続く

　続いては、手作業でのクラウドデプロイについてだ。クラウドの本番環境では、通常、CI/CDパイプラインがインフラやアプリの変更におけるデプロイを担当しており、IaCツールやクラウドプロバイダ固有のツールを使用したスクリプトで自動化される。

　「自動化により、本番環境に常に特権アクセスする必要がなくなり、デプロイは適切に追跡され、ピアレビューされるようになる。その反対の、クラウドコンソールから手動でアクションを実行することは、クリック操作から『ClickOps』と呼ばれる」（萩野氏）

　AWS CloudTrailのログを分析すると、調査を実施した2週間において、AWSでは少なくとも38%の組織がClickOpsを行っていたという。これは、AWS Management Consoleを介してワークロードをデプロイしたり、機密性の高いアクションを手動で実行したりしていることを意味するといい、かつ本番環境での操作も含まれるという。

AWSアカウントでClickOpsを行なった組織の割合

その7：CI/CDパイプラインでの有効期間が短い認証はまだまだ浸透せず

　最後は、CI/CDパイプラインにおけるショートタイムクレデンシャルの利用率の低さだ。クラウド環境では、長期間有効な認証情報の漏えいが、データ漏洩の最も一般的な原因のひとつだという。加えてCI/CDパイプラインは、高い権限を持っており、過剰なロギング、ソフトウェア依存関係の侵害、またはビルド成果物を通じて、認証情報が漏れてしまう可能性がある。

　しかし、AWS環境において、CI/CDサービスのGitHub Actionsを使用している組織（AWSで稼働する31%に相当）の内、有効期間が短いOpenID Connect（OIDC）に基づく「キーレス認証」のみを使用しているのは37%に過ぎなかったという。63%の組織が、有効期間が長い認証情報である「IAMユーザー」を使用しており、さらに42%は「IAMユーザーのみ」を使用しているという。