Datadogの調査レポートから見る、DevSecOpsの適用に向けた実態

Datadog Japanは6月4日、オンラインでDevSecOpsの現状調査に関する記者説明会を開催した。DevSecOpsとは、運用サイクルを迅速かつ継続的に行うDevOpsに、セキュリティを組み込んだソフトウェア開発手法だ。

調査は2024年2月～4月にかけて収集されたデータにもとづいており、数万のアプリケーションとコンテナイメージ、数千のクラウド環境を分析して、アプリケーションのセキュリティポスチャを評価。

DevSecOpsのベストプラクティスとして、IaC(Infrastructure as Code：コードとしてのインフラストラクチャ)、自動化されたクラウドデプロイメント、セキュアなアプリケーション開発プラクティス、CI/CD(継続的インテグレーション/継続的デリバリー)パイプラインでの有効期間が短い認証情報の採用を評価し、7つのポイントをまとめている。

Datadog Japan シニアデベロッパーアドボケイト萩野たいじ氏は「安全なコードを迅速かつ大規模に配布することは、ソフトウェア業界全体の課題となっている。昨今、注目を集めるデータ侵害や重大な脆弱性に関するニュースが続いていることからも明らか。こうした課題に対処するために、すべての組織がDevSecOpsを採用する傾向がある。これはアプリケーション開発者が開発ライフサイクル全体を通して、運用チーム、セキュリティチームと緊密に連携する手法でもある」と述べた。

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

Javaのサービスがサードパーティのライブラリによる脆弱性の影響を最も受けやすい

調査結果によると、クラウド展開のセキュリティ確保に関して、多くの企業が自動化を採用していないことが判明した。1つ目は、さまざまなプログラミング言語で書かれたアプリケーションのセキュリティポスチャを分析し、Javaのサービスがサードパーティのライブラリによる脆弱性に対して最も影響を受けやすいことが明らかになったという。

他の技術の平均が47%であるのに対して、Javaベースのサービスの90%がサードパーティのライブラリによってもたらされた1件以上のクリティカルまたは高重大度の脆弱性に対して影響を受けている。

クリティカルな脆弱性や高リスクの脆弱性が含まれるサービスの割合を示したグラフ

Javaのサービスは、攻撃者による実際の悪用が文書化された脆弱性に対しても、特に脆弱であることが多いとのこと。米CISA(Cybersecurity and Infrastructure Security Agency)がKEV(Known Exploited Vulnerabilities)カタログに記載されている脆弱性からJavaのサービスのうち55%が影響を受けていることが分かり、他言語を使用したサービス7%比較して高い割合になっている。

特定のカテゴリの脆弱性に焦点を当てても、Javaのサービスの23%がRCE(リモートコード実行)に対して脆弱で42%の組織に影響を与えており、Tomcat、Spring Framework、Apache Struts、Log4j、ActiveMQといった一般的なJavaライブラリに影響を及ぼす脆弱性が蔓延していることが数値が高くなっている一因だとしている。

こうした仮説は、これらの脆弱性がどこから発生しているのかを調べることで確実性を高められることから、Javaでは重大な脆弱性の63%が間接的な依存関係から生じているという。これは、アプリケーションとともに間接的にパッケージ化されたサードパーティのライブラリに由来し、出現する追加のライブラリが多くの場合、開発者の知らない間にアプリケーションに導入されているため、通常は特定が困難とのことだ。

萩野氏は「アプリケーションの脆弱性をスキャンする際は、直接的な依存関係だけでなく、依存関係ツリー全体を考慮することが重要。また、アプリケーションに追加した依存関係を適切に管理し、その依存関係が頻繁にアップグレードされているか否かを知ることも必要だ。OpenSSF Scorecardなどのフレームワークは、オープンソースライブラリの健全性を迅速に評価することに役立つ」と話す。

実務担当者は脆弱性の多さに圧倒されている

2つ目は、さまざまな言語で開発されたアプリケーションに対する多くの悪用の試みを分析した結果、自動セキュリティスキャナーからの攻撃が悪用の試みの大半を占めていることが明らかになった。

これらのスキャナーは、オープンソースで一般的なツールであるNuclei、ZGrab、SQLmapなどとなり、攻撃者がインターネット全体をスキャンし、脆弱なシステムを特定するために大規模に実行しようとするという。

自動セキュリティスキャナーによって実行される攻撃の大部分は無害であり、防御側にとっては単なるノイズを生成するだけであることが判明し、これらのスキャナーからの何千万もの悪意のあるリクエストの中で、脆弱性をトリガーしたのは0.0065%に過ぎないという。

そのため、防御者が生のWebサーバログや境界のWebアプリケーションファイアウォール(WAF)のアラートを効果的に監視するために、アラートの優先順位を定めるためのフレームワークが重要であり、脅威インテリジェンスとアプリケーションのランタイムコンテキストをセキュリティ検出に統合することで、企業は最も重要な脅威をフィルタリングしやすくなるとの見解だ。

3つ目は優先する脆弱性への対応について。2023年のCVE(Common Vulnerabilities and Exposures)プロジェクトでは、4000超の高度な脆弱性と1000超のクリティカルな脆弱性が特定され、インベントリ化された。

同社の調査では、平均的なサービスはこれらの脆弱性に対して19の脆弱性があることが分かったが、過去の学術研究では攻撃者が実際に悪用している脆弱性は全体の約5%に過ぎないという。

実務担当者は脆弱性の多さに圧倒され、優先順位付けのフレームワークが必要とのこと。同社では多くの脆弱性を分析し、成功した悪用の可能性と影響を評価するために「脆弱なサービスはインターネットに公開されているか？」「それは本番、開発、テスト環境のどれなのか？」「悪用コードがオンラインで公開されているか、脆弱性を悪用する方法についての指示はあるか？」などの追加的な要因にもとづいた調整済みスコアを計算。

加えて、EPSS(Exploit Prediction Scoring System)のスコアも考慮に入れ、メトリクスで高いスコアを得た脆弱性に重点を置き、これらの方法をすべての脆弱性に適用し、調整後のスコアにもとづいて、どれだけの脆弱性が引き続きクリティカルであるかを評価した。

調整後のスコアリングを適用した結果、重大度がクリティカルな脆弱性を持つ組織の63%がクリティカルな脆弱性を持たないことが確認された一方で、30%の組織はクリティカルな脆弱性の数が半分以上減少した。

スコア調整後にクリティカルな脆弱性が残っている組織の割合

優先すべき脆弱性を決定する際には、組織は問題の重大度を一貫して評価できるフレームワークを採用するべきだという。萩野氏は「ランタイムコンテキストを調整さえすれば、多くのクリティカルな脆弱性を解決できる」との認識だ。

AWS環境のIaCツールとしてTerraformが最も使用されている

4つ目はコンテナイメージに関してだ。ソフトウェア開発とセキュリティの両方において「少ないほど良い」ということがあり、これはコンテナベースイメージなどのサードパーティ依存関係に特に当てはまるという。

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

何千ものコンテナイメージを分析した結果、コンテナイメージが小さいほど脆弱性が少ないことがわかり、含まれているサードパーティのライブラリが少ないためと考えられるという。

平均して、100MB未満のコンテナイメージには4.4個の高度な脆弱性またはクリティカルな脆弱性があり、250MBから500MBのイメージには42.2個、それより大きいイメージには約80個の脆弱性がある。コンテナ化された環境において軽量なイメージを使用することが、攻撃対象領域を最小限に抑えるための重要な手法であることを示しているとのことだ。

コンテナイメージが小規模なほど含まれる脆弱性は少ないという

5つ目はIaCの採用について。1990年代にCFEngine、Puppet、Chefなどのプロジェクトで導入されたIaCは、クラウド環境をプロビジョニングするための標準として急速に広まっている。

AWS(Amazon Web Services)は、Terraform、CloudFormation、Pulumiなど、少なくとも1つの一般的なIaC技術を通じて、71%以上の組織がIaCを使用しているが、Google Cloudでは 55%と低くなっており、Azureに関してはアクティビティログがHTTPユーザーエージェントを記録しない。

AWS環境で採用されているIaCツールはTerraformがトップ

AWSとGoogle Cloud全体では、Terraformが最も人気のあるテクノロジーで、クラウド固有のIaCツールであるCloudFormationやGoogle Deployment Managerよりも一般的となっている。

DevSecOpsを適用していくには？

6つ目はクラウドデプロイにまつわるものだ。クラウドの本番環境では、通常はCI/CDパイプラインがインフラストラクチャとアプリケーションへの変更をデプロイする責任を持ち、パイプラインで行われる自動化はIaCツールやクラウドプロバイダ固有のツールを使用したスクリプトによって行われる。

自動化により、エンジニアは本番環境に常に特権アクセスする必要がなくなり、デプロイが適切に追跡され、ピアレビューされるようになるが、クラウドコンソールから手動でアクションを実行するクリック運用(ClickOps)は、AWSの少なくとも38%の組織がすべてのAWSアカウントでClickOpsを使用していたことを確認した。

AWS Management Consoleを介してワークロードをデプロイしたり、センシティブなアクションを手動で実行したりしたことを意味し、これには本番環境での操作も含まれる。

最後はCI/CDパイプラインにおける資格情報に関するもの。通常、CI/CDパイプラインは高い権限を持ち、過剰なロギング、ソフトウェア依存関係の侵害、ビルド成果物を通じて資格情報が漏えいする可能性があるため、攻撃対象を増加させるという。

これはcodecovの侵害と類似しているため、CI/CDパイプラインで有効期間が短い資格情報を使用することは、クラウド環境を保護するうえで最も重要な側面の1つとなっている。しかし、AWS環境で有効期間が短い資格情報が実用的で安全である場合でも、多くの組織が依然として有効期間が長い資格情報に依存していることが確認された。

GitHubが提供するCI/CDサービス「GitHub Actions」を使用している組織全体(AWSで稼働している組織の31%以上に相当)で、有効期間が短い認証情報とOpenID Connect(OIDC)にもとづく、キーレス認証を専門的に使用しているのは37%となっている。

一方で、63%の組織がGitHub Actionsパイプラインの認証にIAMユーザー(有効期間が長い資格情報の一形態)を少なくとも一度は使用しており、42%がIAMユーザーのみを使用しているという結果になった。