DevSecOps の現況

様々なプログラミング言語で書かれたアプリケーションのセキュリティポスチャを分析することで、Java のサービスがサードパーティのライブラリによる脆弱性に対して最も影響を受けやすいことが明らかになりました。具体的には、他の技術の平均が 47% であるのに対して、Java ベースのサービスの 90% がサードパーティのライブラリによってもたらされた 1 件以上のクリティカルまたは高重大度の脆弱性に対して影響を受けています。

また、Java のサービスは攻撃者による実際の悪用が文書化された脆弱性に対しても特に脆弱であることが多いです。米国サイバーセキュリティ・インフラストラクチャー・セキュリティ局 (CISA) が更新を続けている Known Exploited Vulnerabilities (KEV) カタログには、脅威行為者によって実際に悪用されている脆弱性がリストアップされています。この継続的に更新されるリストは、システムを侵害するために積極的に悪用されている最も影響力のある脆弱性を特定するのに役立ちます。リストに記載されている脆弱性から、Java のサービスのうち 55% が影響を受けていることがわかりました。これは、他の言語を使用して構築されたサービスの 7% と比較して非常に高い割合です。

特定のカテゴリの脆弱性に焦点を当てても、この傾向は変わらないことが確認されています。例えば、Java のサービスの 23% がリモートコード実行 (RCE) に対して脆弱であり、それが 42% の組織に影響を与えています。Tomcat、Spring Framework、Apache Struts、Log4j、ActiveMQ などの人気 Java ライブラリに存在する影響力のある脆弱性がこれらの高い数値の一因と考えられます。最も一般的な脆弱性の例として、以下が挙げられます。

• Spring4Shell (CVE-2022-22965)
• Log4Shell (CVE-2021-45046 and CVE-2021-44228)
• Apache ActiveMQ における RCE (CVE-2023-46604)

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

したがって、アプリケーションの脆弱性をスキャンする際には、直接の依存関係だけでなく、依存関係ツリー全体を考慮することが不可欠です。また、アプリケーションに追加された新しい依存関係が適切に保守され、それ自身の依存関係を頻繁にアップグレードしているかどうかを把握することも重要です。OpenSSF Scorecard のようなフレームワークは、オープンソースライブラリの健全性を迅速に評価するのに役立ちます。

様々な言語で開発されたアプリケーションに対する多くの悪用の試みを分析した結果、自動セキュリティスキャナーからの攻撃が悪用の試みの大半を占めていることが明らかになりました。これらのスキャナーは通常、オープンソースツールで、攻撃者がインターネット全体をスキャンし、脆弱なシステムを特定するために大規模に実行しようとします。一般的なツールの例としては、Nuclei、ZGrab、SQLmap などがあります。

自動セキュリティスキャナーによって実行される攻撃の大部分は無害であり、防御側にとっては単なるノイズを生成するだけであることが判明しました。このようなスキャナーからの何千万もの悪意のあるリクエストの中で、脆弱性をトリガーしたのはわずか 0.0065% に過ぎませんでした。これは、防御者が生の Web サーバーログや境界の Web アプリケーションファイアウォール (WAF) のアラートを効果的に監視するために、アラートの優先順位を定めるための強固なフレームワークが非常に重要であることを示しています。脅威インテリジェンスとアプリケーションのランタイムコンテキストをセキュリティ検出に統合することで、企業は最も重要な脅威をフィルタリングしやすくなります。

2023 年、Common Vulnerabilities and Exposures (CVE) プロジェクトでは、4,000 を超える高度な脆弱性と 1,000 を超えるクリティカルな脆弱性が特定され、インベントリ化されました。私たちの調査により、平均的なサービスはこれらの脆弱性に対して 19 の脆弱性があることがわかりました。しかし、過去の学術研究によると、攻撃者によって実際に悪用される脆弱性は全体の約 5% に過ぎません。

この数字を見ると、実務担当者が直面する脆弱性の多さに圧倒されている理由、そして彼らが何に焦点を当てるべきかを判断するために優先順位付けのフレームワークが必要な理由がよくわかります。私たちは多くの脆弱性を分析し、成功した悪用の可能性と影響を評価するために、以下のいくつかの追加的な要因に基づいた「調整済みスコア」を計算しました。

• 脆弱なサービスはインターネットに公開されているか？
• それは本番環境で稼働しているのか、それとも開発環境やテスト環境なのか？
• 悪用コードがオンラインで公開されているか、脆弱性を悪用する方法についての指示はあるか？

また、Exploit Prediction Scoring System (EPSS) のスコアも考慮に入れ、このメトリクスで高いスコアを得た脆弱性に重点を置きました。この方法をすべての脆弱性に適用し、調整後のスコアに基づいてどれだけの脆弱性が引き続きクリティカルであるかを評価しました。調整後のスコアリングを適用した結果、重大度がクリティカルな脆弱性を持つ組織の 63% が、もはやクリティカルな脆弱性を持たないことが確認されました。一方で、30% の組織は、クリティカルな脆弱性の数が半分以上減少しました。

優先すべき脆弱性を決定する際には、組織は問題の重大度を一貫して評価できるフレームワークを採用すべきです。一般に、以下の条件を満たす場合、脆弱性はより深刻です。

1. 影響を受けるサービスがインターネットに公開されている場合
2. 脆弱性が本番環境で動作している場合
3. 悪用コードが公開されている場合

他の脆弱性もリスクを伴う可能性がありますが、これらの 3 つの基準を満たす問題に対処した後にのみ取り組むべきです。

ソフトウェア開発とセキュリティの両方において、「少ないほど良い」ということがしばしばあります。これは、コンテナベースイメージなどのサードパーティ依存関係に特に当てはまります。ベースイメージの選択肢には、通常、以下のようなものがあります。

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

何千ものコンテナイメージを分析した結果、コンテナイメージが小さいほど脆弱性が少ないことがわかりました。これは、含まれるサードパーティのライブラリが少ないためと考えられます。平均して、100 MB 未満のコンテナイメージには 4.4 個の高度な脆弱性またはクリティカルな脆弱性があり、250 MB から 500 MB のイメージには 42.2 個、それより大きいイメージには約 80 個の脆弱性があります。

この事実は、コンテナ化された環境において軽量なイメージを使用することが、攻撃対象領域を最小限に抑えるための重要な手法であることを示しています。軽量なイメージは、アプリケーションが依存するサードパーティのライブラリやオペレーティングシステムのパッケージ数を減少させるのに役立ちます。さらに、薄いイメージはストレージ使用量やネットワークトラフィックを減らし、デプロイの速度も向上させます。最終的に、軽量なコンテナイメージは、攻撃者が利用可能なツール (例えば curl や wget などのシステムユーティリティ) を最小限に抑えることで、多くの種類の脆弱性の悪用をより困難にします。

コードとしてのインフラストラクチャー (IaC) の概念は、1990 年代に CFEngine、Puppet、Chef などのプロジェクトによって導入されました。パブリッククラウドコンピューティングが普及した後、IaC はクラウド環境をプロビジョニングするための事実上の標準として急速に広まりました。IaC はバージョン管理、トレーサビリティ、環境間での再現性など、運用に大きなメリットをもたらします。その宣言的な性質が、DevOps チームが望ましい状態を理解するのを助けるため、終わりのない bash スクリプトを読む代わりに、目的の状態にどのように到達するかを把握することができます。

IaC は、クラウドの本番環境を保護する上での重要な手法とされており、次のような点を確保するのに役立ちます。

• すべての変更がピアレビューされる
• デプロイは CI/CD パイプラインによって処理されるため、本番環境における人間の操作の権限は限定される
• 組織は IaC コードの脆弱な構成をスキャンし、本番環境に到達する前に問題を特定することができる

AWS では、Terraform、CloudFormation、Pulumi などの少なくとも 1 つの一般的な IaC 技術を通じて、71% 以上の組織が IaC を使用していることを確認しました。この数字は Google Cloud では 55% と低くなっています。

Azure に関しては、Azure アクティビティログが HTTP ユーザーエージェントを記録しないため、報告することができません。

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

人間はありがたいことに機械ではないため、間違いを犯すことがあります。このため、品質管理やそれに伴うセキュリティの重要な要素として、人の手を離れる反復的なタスクを自動化することが必要です。

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

自動化により、エンジニアは本番環境に常に特権アクセスする必要がなくなり、デプロイが適切に追跡され、ピアレビューされるようになります。このベストプラクティスの反対である、クラウドコンソールから手動でアクションを実行することは、しばしばクリック運用 (ClickOps) と呼ばれます。

CloudTrail のログを分析することで、私たちは AWS の少なくとも 38% の組織が、この調査の執筆に先立つ 14 日間のウィンドウ内にすべての AWS アカウントで ClickOps を使用していたことを確認しました。私たちの定義によると、これはこれらの組織がこの期間中に AWS Management Console を介してワークロードをデプロイしたり、センシティブなアクションを手動で実行したりしたことを意味します。これには本番環境での操作も含まれます。

クラウド環境では、有効期間が長い資格情報の漏えいがデータ漏洩の最も一般的な原因の一つです。CI/CD パイプラインは通常、高い権限を持ち、過剰なロギング、ソフトウェア依存関係の侵害、またはビルド成果物を通じて資格情報が漏れる可能性があるため、攻撃対象を増加させます。これは codecov の侵害と類似しています。このため、CI/CD パイプラインで有効期間が短い資格情報を使用することは、クラウド環境を保護する上で最も重要な側面の一つです。

しかし、AWS 環境で有効期間が短い資格情報がより実用的で安全である場合でも、多くの組織が依然として有効期間が長い資格情報に依存していることが確認されました。GitHub Actions を使用している組織全体 (AWS で稼働している組織の 31% 以上に相当) で、有効期間が短い認証情報と OpenID Connect (OIDC) に基づく “キーレス” 認証 を専門的に使用しているのはわずか 37% です。一方で、63% の組織が GitHub Actions パイプラインの認証に IAM ユーザー (有効期間が長い資格情報の一形態) を少なくとも一度は使用しており、42% が IAM ユーザーのみを使用しています。

CI/CD パイプラインでキーレス認証を使用することは、設定が簡単で、より安全です。これは、良好な運用プラクティスがより優れたセキュリティ結果につながる傾向があることを再び示しています。