セキュリティの脅威がますます 蔓延する中、セキュリティを最優先に考えたソフトウェアの構築が不可欠です。セキュリティは、特にコンテナのワークロード、それに見合ったコンテナの基本イメージの選択に関する懸念事項となっています。 安全なベースイメージの選択に関する多くの議論は CVEの数に焦点を当てていますが、セキュリティにはそれ以上のものが含まれます。
安全なソフトウェア開発をリードしてきた組織の 1 つが Debian プロジェクトです。 この投稿では、Debian が開発のための安全な基盤としてどのように、そしてなぜ動作するのかを概説します。
![紫色の背景に白いテキスト、Dockerのロゴと「docker公式イメージ」](https://www.docker.com/ja-jp/wp-content/uploads/2024/03/banner_docker-official-images-part2-1110x583.png "紫色の背景に白いテキスト、Dockerのロゴと"Dockerの公式イメージ"-バナーDockerの公式イメージパート2")
30 年以上にわたり、Debian の多様なボランティアグループは、フリーでオープンで、安定していて、安全な GNU/Linux ディストリビューションを提供してきました。Debian はエンジニアリングの卓越性とすっきりとしたデザインを重視しており、パッケージやサポートするアーキテクチャも豊富で、それ自体が広く使われているディストリビューションであるだけでなく、メタディストリビューションでもあります。Ubuntu、Linux Mint、Kali Linuxなど、他の多くのLinuxディストリビューションは、多くの Docker公式イメージ(DOI)と同様に、Debian上に構築されています。 実際、1以上の Docker Official Images の亜種000、DOI または Debian 由来ubuntuの DOI をベースイメージとして使用しdebianています。
なぜ Debian なのか?
ちょっとした免責事項として、私は長い間 Debian GNU/Linux を使ってきました。 1990で Debian をフロッピーディスクから PC にインストールし、後でプレリリース版netinstのネットワークインストーラをテストできるように再インストールしたことを覚えています。56-kbps モデムを使用してネットワーク経由でインストールするには、しばらく時間がかかりました。このようなネットワーク速度では、どのパッケージを選択する dselectかを非常に慎重に考える必要がありました。
Debian を試す前に他のディストリビューションをいくつか使ったことがありましたが、そのシステムがいかによく組織化され、設計されているかに驚いたことを今でも覚えています。 ぶら下がったり壊れた依存関係はありません。 ダウンロードの失敗はありません。 互換性のない共有ライブラリはありません。 パッケージの競合はありませんが、同様の機能を提供するパッケージを慎重に処理します。
ここ数年で多くのことが変わり、フロッピーはなくなり、dselect引退し、ネットワーク接続速度は数桁向上し、今では .docker pull debian変わらないのは、Debian とそのコミュニティに対する驚きの気持ちです。
オープンソースソフトウェアとセキュリティ
Debian プロジェクトや Debian プロジェクトが生み出した他の多くのプロジェクトの成果にも関わらず、中傷者がいないわけではありません。 他の多くのオープンソースプロジェクトと同様に、Debian はここ数年、オープンソースセキュリティの状態を嘆く日和見主義者から批判を受けてきました。 ソフトウェアのサプライチェーンについて書きながら、注目度の高いCVEを嘆き、PyPIやNPMなどのオープンソースパッケージエコシステムにアップロードされたマルウェアを指摘することは、あまりにも一般的になっています。
このような記事の有害な仮定は、オープンソースソフトウェアが問題であるというものです。 私たちは、そうではないことを知っています。 私たちは以前にもこのような経験をしました。 私が 56-kbps モデムで Debian をインストールしていた頃、様々なプロプライエタリなソフトウェアベンダによって、あらゆる種類の恐怖、不確実性、疑念 (FUD) が広まっていました。 その時、オープンソースはセキュリティの問題ではなく、セキュリティソリューションであることを学びました。
オープンソースだからといって、クローズドソースソフトウェアと比較してセキュリティステータスが自動的に向上するわけではありませんが、大きな利点があります。 David Wheeler は、彼の Secure Programming HOWTO の中で、オープンソースソフトウェアとセキュリティの関係についてバランスの取れた要約を提供しています。 クローズドソースソフトウェアがもたらす利点は、そのソースコードが開示されないことですが、 曖昧さによるセキュリティ はまったくセキュリティではないことを私たちは知っています。
オープンソースソフトウェアとオープンエコシステムの透明性により、セキュリティ体制をよりよく知ることができます。 オープン性により、脆弱性の迅速な特定と修復が可能になります。 オープン性により、開発者が日常的に使用するセキュリティおよびサプライチェーンツールの大部分が可能になります。 CVEを定期的に公開しているクローズドソースツールはいくつありますか? プロプライエタリなソフトウェアでは、多くの場合、手遅れになってから脆弱性に気づくことになります。
Debian の迅速な対応戦略
Debian はセキュリティ面での動きが遅すぎると批判されています。 しかし、このナラティブは、オープンソースとクローズドソースのナラティブと同様に、ニュアンスも現実も捉えていません。 いくつかのディストリビューションは、修正されたバージョンが利用可能になるまでCVEの公開を待ちますが、Debianはセキュリティ情報をユーザーに伝える際に完全な透明性と緊急性を選択しています。
さらに、Debian メンテナは、慌ててパッチを適用し、新しいパッケージバージョンをリリースする愚かな自動機械の群れではありません。 概して、Debian メンテナは専門家の中のエキスパートであり、ソフトウェアやデリバリエンジニアリング、オープンソース文化、そして彼らがパッケージするソフトウェアに深く染み込んでいます。
zlib 脆弱性の例
最近の zlib の脆弱性である CVE-2023-45853は、Debian プロジェクトのセキュリティに対する熱心で徹底したアプローチの洞察力に富んだ例を提供します。いくつかのディストリビューションがこの脆弱性に対する パッチ を入手し、適用し、再構築し、パッケージ化し、新しいzlibパッケージをリリースしました。 Debian セキュリティコミュニティは 詳しく調べました。
CVEの概要で述べたように、この脆弱性は、zlibソースコードのcontribディレクトリにあるユーティリティであるminizipにありました。 minizip ソースファイルは zlib ライブラリ libz にコンパイルされません。 そのため、この脆弱性は実際には zlib パッケージには影響しませんでした。
もし、話がそこで終わってしまったとしたら、唯一の害は、パッケージを不必要に更新することでしょう。 しかし、話はそこで終わりませんでした。 Debian バグスレッドで詳述されているように、問題のある minizip コードはコピー (つまり、ベンダー化) され、他の多くの広く使用されているソフトウェアで使用されました。 実際、ChromiumとNode.jsの両方でベンダー化されたミニジップコードは、zlib CVEが公開される約1か月前にパッチが適用されました。
残念なことに、他の一般的に使用されているソフトウェアパッケージにも、まだ脆弱なminizipのベンダーコピーがありました。 Debian プロジェクトの熱心さのおかげで、パッチがこれらのプロジェクトにも適用されたか、ベンダバージョンではなく、パッチを当てたシステムの minizip (zlib ではありません!) 開発パッケージに対してコンパイルされました。 他のディストリビューションでは、これらのバグのあるベンダーのコピーは、場合によってはまだソフトウェアパッケージにコンパイルされており、CVEでは言及されていません。
CVEの先を見据えて
過去 30 年間で、テクノロジー業界でオープンソース ソフトウェアが果たす役割は天文学的に増加しています。 ソフトウェアエンジニアは、利用可能な高品質のオープンソースソフトウェアを大量に活用することで生産性が向上しているにもかかわらず、オープンソースの黎明期に聞いたのと同じFUDを再び耳にしています。
次にオープンソースの依存関係に潜む危険性に関する記事を見かけたら、見出しを通り越して仮定に疑問を呈することを恐れないでください。 オープンなエコシステムは安全なソフトウェアにつながり、Debian プロジェクトは私たち全員が見習うべきモデルを提供します。 Debian の目標はセキュリティであり、それは CVE がゼロであることを示す報告以上のものを網羅しています。 オペレーティングシステムとコンテナイメージのコンシューマは、その違いを理解するのが賢明です。
ですから、DO Iの上にdebian構築してください。FROM debian は、Dockerfileを開始するのに決して悪い方法ではありません。
さらに詳しく
- Debian 公式イメージは Docker Hub にあります。
- 「From Misconceptions to Mastery: Enhancing Security and Transparency with Docker Official Images」を読んでください。
- Docker Hubにアクセスして、Docker公式イメージをご覧ください。
- Debian DOI は GitHub で見つけてください。
- Docker Hub の詳細については、こちらをご覧ください。
- Docker Scout でイメージを保護します。
- Docker Newsletter を購読してください。