31%はアプリケーションの依存関係を追跡せず、38%は直接依存関係のみを追跡
2020年1月28日
0 分で読めますDevOpsとDevSecOpsの導入状況について、最近調査を実施しました。この記事では、DevSecOps導入に向けた組織の準備状況、DevOpsの成熟度がセキュリティ統合に与える影響、そしてDevOpsを導入したチームのセキュリティ態勢から得られた教訓を紹介します。
DevSecOps Insights 2020のPDFをダウンロード
DevSecOps導入に向けた組織の準備状況
エンジニアがコードベースを監査する方法を調べたところ、Snyk State of Open Source Securityレポート2019によると、自動化されたセキュリティツールが広く導入されており、回答者の65%がそのことを確認しています。また、自動化されたセキュリティツールを使用している場合でも、回答者の79%がセキュリティコードレビューを実施している点も重要です。
チームは自動化されたセキュリティツールを導入する一方で、それをCIパイプラインに組み込むことでビルド時間が延び、開発者の体験やフィードバックのサイクルが悪化することも認識しています。
回答者の57%がオープンソース依存関係に既知のセキュリティ脆弱性がないかテストしている一方、静的アプリケーション・セキュリティ・テスト（SAST）を実施する割合は大幅に低いことがわかりました。
これは多くの場合、この種のセキュリティテストに長い実行時間がかかることに加え、誤検知が多く、その後に手作業で確認する必要があるためです。
回答者の半数強が、アプリケーションのオープンソース依存関係に既知の脆弱性がないかテストしていると回答しましたが、継続的インテグレーションのパイプラインでコンテナイメージに同様のテストを実施しているのはわずか14%でした。このギャップを埋めるセキュリティツールが利用可能であることを、回答者は知らないのでしょうか。あるいは、多くのセキュリティツールでは、コンテナイメージ内に存在する脆弱性のレポートが得られるだけで、実際の問題を修正するのは利用者自身に委ねられているためかもしれません。
比較例として、Snyk Containerは、脆弱性の数を減らし、全体的なセキュリティリスクを最小限に抑える代替コンテナイメージを、実行可能なアドバイスとして提供します。
Dockerコンテナのベースイメージの切り替えは簡単に実行でき、セキュリティ面で大きな投資対効果が得られます。実際、Snykユーザーが実施したスキャンに基づくSnyk State of Open Source Securityレポートによると、Dockerイメージのスキャンの44%で既知のセキュリティ脆弱性が見つかりましたが、そのうちには、より新しく安全なベースイメージが利用可能なものもありました。
コンテナセキュリティの対象は、Dockerコンテナイメージだけではありません。Kubernetesにも影響し、Helmチャートで見つかる脆弱性という現実的なセキュリティ課題もあります。Snykの2019年レポート未開拓の領域：Helm Chartセキュリティの知られざる実態では、この分野における次のようなリスクが明らかになりました。
安定版Helm Chartの68%に、重大度の高い脆弱性を含むイメージが含まれています。
公開された最新イメージに更新すると、安定版Helm Chartの64%で脆弱性の数が減少します。
全416イメージのうち、6つのイメージが脆弱性の半数を占めています。
アプリケーションそのもの、またはその実行基盤（たとえば、アプリケーションのデプロイに使用するコンテナイメージ）がセキュリティの対象となる場合、開発者がアプリケーションのセキュリティに対する責任を担う重要な役割を果たすことがわかりました。では、インフラストラクチャのセキュリティに対する責任についてはどうでしょうか。意外なことに、DevSecOps環境に貢献するすべての関係者が、インフラストラクチャセキュリティの責任をほぼ均等に担っています。
新しいレポート Open Source Security Report 2020 をご覧ください。このレポートでは、2020年のオープンソースセキュリティに関する懸念や、パッケージとコンテナイメージ全体における脆弱性の傾向を紹介しています。
DevSecOps Insights 2020の調査を続けて読む：