開発者の80%がDockerのセキュリティに対処していない
William Henry
2019年4月17日
0 分で読めますDockerセキュリティレポートへようこそ：Dockerセキュリティをシフトレフトする。本レポートは複数の記事で構成されています。
開発者の80%はDockerのセキュリティに取り組んでいない
この情報をさらに詳しくまとめた、手作りのPDFレポートもぜひダウンロードしてください。
コンテナセキュリティの責任
Dockerが自社のエコシステムに欠かせない存在であるなら、誰かがその責任を担う必要があります。多くの人が、責任は全員で分担するものだと考えています。コンテナセキュリティの責任者について複数回答可で尋ねたところ、回答者の大半が開発者が責任を担うべきだと考えており（68%）、次いで運用チーム（39%）が続きました。
DevOps、さらに言えばDevSecOpsでは、セキュリティの責任を共有する一方で、開発者が重要な役割を果たすと考える人が多いことが分かります。これは、アプリケーションコードのセキュリティ責任についても同様です。オープンソースセキュリティの現状レポートによると、回答者の81%が、アプリケーションのセキュリティは開発者が担うべきだと考えています。
組織は、CI/CDパイプラインを利用する際のセキュリティリスクの一部を管理するため、ベースイメージの信頼できるベンダーとの連携も検討するとよいでしょう。Red Hatなどのベンダーは、スキャン済みの署名付きイメージを提供しています。また、ベースイメージのCVEへの迅速な対応により、CI/CDパイプラインでアプリケーションイメージを再ビルドできます。これによってDevOpsライフサイクル全体でのスキャンが不要になるわけではありませんが、脆弱な本番イメージが安全な本番イメージに置き換わるまでの時間を短縮できます。サードパーティとリスクを分担することで、全体的なリスクの軽減につながります。
OSレイヤーのセキュリティテスト
残念ながら、開発中にDockerイメージのOSレイヤーの脆弱性をテストしていると答えた開発者はわずか19%です。つまり、80%を超える開発者が、開発中にイメージをテストしてセキュリティをシフトレフトしていません。脆弱性の発見が遅れるほど、対応コストは高くなります。
さらに、半数（50%）のユーザーは、DockerイメージのOSレイヤーをまったくスキャンしていません。イメージのOSレイヤーに何が含まれているかを把握することが重要です。Dockerイメージを無検証で使うのは非常に危険です。数多くの脆弱性を持ち込むことになりかねません。検討している各イメージをスキャンし、既知の脆弱性を事前に把握すれば、リスクを簡単に軽減できます。
Snykが提供するようなDockerイメージスキャンツールを使えば、開発サイクル全体を通じて脆弱なイメージを検出できます。開発者が特定のDockerイメージを選ぶローカル環境からスキャンを始めることで、脆弱なDockerイメージが環境に持ち込まれるのを防げます。CI/CDパイプラインの最後まで各段階で繰り返しスキャンし、既知の脆弱性を含むイメージが本番環境に入るのを防ぎましょう。
イメージの脆弱性は時間の経過とともに発見されるため、本番イメージを継続的に把握することが重要です。脆弱性が発見・報告されるまでの期間の中央値は2.5年です。現在、本番環境でイメージをスキャンしていると答えたユーザーは9%にとどまります。本番環境へのデプロイ時には安全だったイメージでも、その後、開発者の90%以上はイメージの最新のセキュリティ状況を把握できていない可能性があります。
脆弱性を見つける方法
実行中のコンテナに公表済みの脆弱性が含まれていることを、どのように把握しているかも尋ねました。45%はおそらく確認していません。回答者のうち、CVEデータベースなどの公開データベースを確認しているのは15%でした。ただし、CVEデータベースに掲載される情報は氷山の一角にすぎない点に注意してください。CVEの登録には数週間かかることがあり、CVEとして登録されない脆弱性も数多くあります。それでも、システムにとって重大なリスクとなる可能性があります。
続きを読む：
開発者の80%はDockerのセキュリティに取り組んでいない
