10年以上にわたり、業界はソフトウェアのセキュリティ向上を開発者により近づけて強化しようとしてきました。スキャナーをCIに移行し、プルリクエストにセキュリティチェックを追加し、増え続ける脆弱性の連鎖に対してチームにより迅速に対応するよう求めました。しかし、根本的な問題は消えていません。
問題は開発者がセキュリティにあまり関心がないことではありません。問題は、私たちが基盤を直すのではなく、周辺のセキュリティを修正し続けていることです。ハード化されたコンテナイメージは 、攻撃面を減らし、開発チームに届く前に低信号のセキュリティノイズを多く排除することで、その動態を変えます。
セキュリティはノイズになると失敗します
私の知るほとんどの開発者は安全なソフトウェアの開発に深く関心を持っています。彼らが気にしないのはセキュリティの芝居です。
今日のセキュリティ問題、特にCVEの扱い方は、開発チームに低信号の仕事を継続的に生み出しています。警報は常に発動します。多くは技術的には有効ですが、実際には無関係です。また、開発者に自分で選んでおらず、実質的にコントロールできないコンポーネントのパッチを当てるよう求めるものもあります。時間が経つにつれて、セキュリティは背景音に変わります。
その時、システムはすでに失敗したことになります。開発者は文脈を切り替えざるを得ず、チームは深刻度スコアの議論に時間を費やし、重要でない問題と共に本当のリスクが埋もれてしまいます。これは動機付けの問題ではありません。これはシステム設計の問題です。
業界はこれに対し、「左にシフト」し、開発サイクルの早い段階でセキュリティを推進しようとしました。実際には、開発者により良いデフォルトや基盤を与えずに、より多くの作業を押し付けることが多かったのです。その結果、さらなる労力、さらなる警報、そしてすべてを無視する理由が増えた。
左にシフトするのは正しい本能だったが、実行は間違っていた。目標は開発者により多くのセキュリティ作業をさせることではありません。安全な選択を痛みのない明白なデフォルトにし、開発者がセキュリティ作業を減らしながらより良い結果を得られるようにすべきです。
なぜ大きな画像がデフォルトだったのか
どうしてここに至ったのかを理解するには、多くのチームが大きく汎用的なベース画像から始める理由を正直に理解することが役立ちます。
Dockerが2013年にリリースされたとき、コンテナは馴染みがありませんでした。開発者たちは自分たちが知っているもの、すなわち完全なLinuxディストリビューションと、頼りにしているデバッグツールを備えた馴染みのあるDebianやUbuntu環境を手に入れました。
すべてが入っている大きな画像は合理的なデフォルトでした。この方法は簡単さと柔軟性に最適化されています。必要なものがすべて揃っていると、開発の摩擦は減少します。ビルドの失敗は少なくなります。デバッグはより簡単です。未知の依存関係は最悪のタイミングで驚かされる可能性が低くなります。
長い間、より安全なことをするには本当の投資が必要でした。Teamsはカスタムベースイメージを設計し、強化し、継続的に維持できるプラットフォームグループを必要としていました。その作業は製品の特徴やインフラの優先順位と競合しなければなりませんでした。ほとんどの組織はそのようなトレードオフをしなかったため、その決定は理解できます。
そのため業界は馴染み深いパターンに収束しました。まずは大きなイメージから始めましょう。短期的には発送を速くしましょう。結果は後で対処しましょう。
その結果はさらに重なっていきます。大きな画像は攻撃対象を劇的に拡大させます。彼らは古びた依存関係を蓄積します。彼らは開発者が元の選択をした後もトリアージを求められる無限の CVE を生成します。利便性として始まったものが、徐々に持続的なセキュリティと運用上の重荷となり、開発速度やソフトウェア出荷を遅らせています。
安全な基盤は開発者体験を向上させることができます
より良いセキュリティには開発者の体験が劣化するという考えが広く信じられています。しかし実際には、その逆がしばしば当てはまります。
Docker Hardened Imagesのような安全で目的別の基盤から始めることは、複雑さを増やすのではなく、むしろ軽減します。小さな画像はパッケージ数が少ないため、脆弱性やアラートも少なくなります。開発者は低影響のCVEを追いかける時間を減らし、実際の製品開発により多くの時間を割きます。
重要なのは、セキュリティが財団自体に組み込まれているということです。画像の内容は明示的かつ再現可能です。署名、SBOM、出所などのサプライチェーンメタデータは画像の一部であり、開発者自身が追加で配線する必要はない。同時に、これらの基礎は安全にカスタマイズしやすいです。チームは予測可能なレイヤーとサポートされたカスタマイズパターンのおかげで、硬化を解除せずに画像を拡張・調整できます。これにより、個別のチームにかかる隠れた依存関係やセキュリティの手間が丸ごと排除されます。
また、具体的なパフォーマンス向上もあります。小さい画像ほど、より速く引き込み、速く構築し、より速く展開できます。大規模な環境では、これらの利点はすぐに積み重なります。
重要なのは、柔軟性を犠牲にする必要がないということです。開発者はリッチビルド環境や馴染みのあるツールを使いながら、最小限のハード化されたランタイムイメージを本番環境に提供できます。
これはセキュリティの向上が開発者体験を直接向上させる稀なケースの一つです。私たちが長年受け入れてきたトレードオフは避けられないものではありません。
安全な基盤がデフォルトである場合に何が変わるか
安全な基盤と強化イメージがデフォルトのスタート地点になると、システムの挙動は変わります。開発者は既に知っている同じDockerワークフローを使い続けています。違いは、彼らがどの基地から始めるかにあります。
セキュリティ強化、パッチ適用、サプライチェーン衛生は、すべてのサービスで繰り返されるのではなく、基盤で一度だけ行われます。セキュアファウンデーションはオペレーティングシステムのイメージに限定されません。同じ原則は、実際にデータベース、ランタイム、共通サービスなど、ソフトウェアチームの上に構築する場合にも当てはまります。強化されたMySQLやアプリケーションイメージから始めると、アプリケーションコード一行も書かれる前に、セキュリティや保守作業のクラス全体が削除されます。
これが Dockerのハードンドイメージが 解決するために設計された問題です。同じハードニング原則は、広く使われているオープンソースコンテナイメージ全体でも一貫して適用されており、OS層だけでなく、チームはアプリケーションが実際に始まるどこからでも安全なデフォルトから始めることができます。目的は、別のセキュリティワークフローやツールを導入することではありません。それは開発者に初日からより良い構成要素を提供することです。
基礎が専門家によって維持されているため、チームは中断が少なくなります。緊急の再建も減ります。広く悪用されている脆弱性が現れても、組織全体の混乱が減ります。セキュリティチームは、同じ問題を何十人ものチームに独立して解決させるのではなく、採用や体制に集中できます。
その結果、セキュリティの手間が減り、製品作業により多くの時間を費やすことになります。これは開発者、セキュリティチーム、そしてビジネスにとっての勝利です。
より良いデフォルトの上に構築
長年にわたり、開発者により多くの対応を求めてセキュリティ向上を目指してきました。パッチを早くしてください。もっとアラートに応答してください。さらに多くのツールを学びましょう。しかし、そのアプローチはスケールしません。
デフォルトが強いとセキュリティが拡大します。基礎は長期的に安全かつ維持されるよう設計されている場合。開発者が自分のコードよりはるかに低い決定に対して常に補償を強いられる必要がないのです。
チームの遅延を抑えつつ、より良いセキュリティ成果を望むなら、ソフトウェアが実際に始まるところから始めるべきです。それには、デフォルトで安全な堅牢な基盤、例えば硬化画像が必要です。基盤が整えば、セキュリティは静かになり、開発はスムーズになり、システム全体が本来あるべきように機能します。
それが私たちが目指すべき基準です。
