Docker Scout のポリシーガードレールを使用したセキュリティとコンプライアンスの目標の達成

DockerCon 2023 で、 Docker Scout の一般提供 (GA) を発表しました 。Docker Scout は、最新のアプリケーション チーム向けに構築され、開発者が実用的な分析情報を通じてソフトウェア サプライ チェーンの複雑さと課題をナビゲートできるようにしました。 

Scout GAリリースでは、開発者がインサイトに優先順位を付けて、組織の標準や業界のベストプラクティスに合わせるのに役立つポリシー駆動型評価メカニズム(別名ガードレール)など、いくつかの新機能が導入されました。 

この記事では、Docker Scoutのポリシーによって、チームが作成時点(開発者の内部ループ(つまり、ローカル開発、ビルド、テスト))でソフトウェア品質の問題を特定し、優先順位を付け、修正し、実行とイノベーションのスピードを損なうことなく、組織のセキュリティと信頼性の基準を満たすことができるようになる方法について説明します。 

黒い背景に盾とチェックマークが付いたDockerスカウトのロゴ

問題の優先順位付け

ソフトウェアサプライチェーンのツールやプロセスを導入する際、組織はソフトウェアに手ごわい問題の壁に直面することがよくあります。 これらの問題(コードの脆弱性から悪意のあるサードパーティの依存関係、侵害されたビルドシステムなど)の膨大な量により、開発チームは新機能のリリースと製品の改善のバランスをとることが困難になります。 このような状況では、ポリシーは、解決のための明確なガイドラインと基準を提供することで、開発者が最初に修正する問題の優先順位付けを支援する上で重要な役割を果たします。 

Docker Scoutの すぐに使えるポリシー は、ソフトウェアサプライチェーンのベストプラクティスに沿って、最新のベースイメージを維持し、リスクの高い脆弱性を排除し、望ましくないライセンスをチェックし、組織が構築または使用しているアーティファクトの品質を維持するのに役立つその他の問題を探します(図1)。 

Docker ポリシーの結果のスクリーンショットで、すべての重大な脆弱性、更新されていない基本イメージ、修正された重大および高の脆弱性、高プロファイルの CVE など、個別のカテゴリのボックスが表示されています。
図1: Docker Scout で使用可能なポリシーの概要。

これらのポリシーにより、開発者はコンテナー イメージに関する重要な分析情報を提供し、新しい問題が発生したときに優先順位を付け、注意が必要な既存の問題を特定することに集中できます。 実際、開発者はこれらのインサイトをローカルマシンから直接得ることができ、CIなどのサプライチェーンの後半や本番環境の後半よりも、はるかに高速で低コストで反復することができます(図2)。

分析された画像の詳細を示すスクリーンショットと、「ポリシー失敗」の結果。
図2: CLI でのポリシー評価結果。

物事をより良くする

また、Docker Scout は、ポリシーに関して、より実用的で柔軟なアプローチを採用しています。 従来の政策ソリューションは、通常、不合格が絶対である場合に「50未満の脆弱性」を義務付けるなど、厳格で画一的な目標を課す二者択一の評価モデルに従います。 このようなアプローチでは、微妙な状況や中間状態が見落とされ、開発者のワークフローとの摩擦を引き起こし、ポリシーの採用を成功させるための主な障害になる可能性があります。 

対照的に、Docker Scout の哲学は 、「物事をより良くする」という単純な前提を中心に展開しています。 この前提は、すべてのリリースの最初の ステップ は、開発者の問題をゼロにすることではなく、リグレッションを防ぐことであることを意味します。 私たちのアプローチは、複雑で広範なコードベースを持つプロジェクトには既存の品質ギャップがあるにもかかわらず、すべてを、どこでも、一度に修正するように開発者に過度のプレッシャーをかけることは逆効果であることを認識しています。

Docker Scoutを使用することで、開発者は( WebサイトCLICIパイプラインから)最新のビルドで何が悪化したかを簡単に追跡し、ポリシーに関連する問題のみを改善できます(図3および4)。

分析、比較、および変更列を含むテーブル内の改善された項目を示す Docker ポリシーのスクリーンショット。
図3: Docker Scout ポリシーによってもたらされる成果。
Docker ポリシーの結果のスクリーンショットで、改善が 2 件、悪化が 0 件、欠損データが 1 件ある変更が示されています。
図4: Scout GitHub Action からの Pull Request diff。

しかし、適切な問題を見つけて優先順位を付けることは、努力の半分にすぎません。 開発者が真に「物事をより良くする」ためには、これらの問題を解決するための 2番目のステップ を踏まなければなりません。 GitHubが500人の開発者を対象に実施した 最近の調査によると 、開発チームがほとんどの時間を費やす主な分野は、コードの記述(32%)とセキュリティの脆弱性の特定と対処(31%)です。 これは、開発者がイノベーションとユーザー価値の推進に費やす時間が少なくなることを意味するため、理想とはほど遠いものです。 

Docker Scoutでは、開発者が自動化されたコンテキスト内の修復ガイダンスにアクセスできるようにすることで、この課題に正面から取り組むことを目指しています(図5)。 Docker Scoutは、アップグレードと修復のパスを積極的に提案することで、チームのコンテナイメージをポリシーに合わせ、平均修復時間(MTTR)を短縮し、価値の創造により多くの時間を割くことができます。

OS のメジャー バージョンの更新などの推奨事項を示す Docker スカウト ポリシーのスクリーンショット。
図5: 「基本イメージが最新ではありません」ポリシーのシナリオ例。

Docker Scoutは、当初、チームが改善の方向性に優先順位を付けるのに役立ちますが、既存の重要なソフトウェアの問題がすべて効果的に対処されると、開発者はポリシーの採用に移行して完全なコンプライアンスを達成できます。 このプロセスにより、今後、すべてのコンテナー イメージに、組織のコード品質、コンプライアンス、およびセキュリティの目標に不可欠と見なされる特定の問題がなくなります。 

Docker Scoutチームは、ソフトウェアサプライチェーン内で急速に進化するエコシステムにおいて、最高水準の安全性、効率性、品質を満たすソフトウェアの構築をお客様に支援できることを嬉しく思います。 Docker Scoutを使い始めるには、今すぐ 製品ページ にアクセスしてください。

さらに詳しく