今日、ソフトウェアは定期的にサードパーティのソースからのオープンソースコードをアプリケーションに統合しています。 このプラクティスにより、開発者はより短い時間枠でより高性能なソフトウェアを作成できますが、十分に精査されていないコードを導入するリスクが伴います。 オープンソースコードのセキュリティをどの程度認識していますか?
私たちのほとんどは、pipまたはnpmを使用してソフトウェアを自由にインストールし、機能とサポートに基づいて決定を下します。 効率は、達成すべき配信目標がある場合の目標です。 オープンソースソリューションを使用しないことを選択した場合、生産性の大きなメリットを逃します。 しかし、オープンソースソリューションを使用することを決定した場合、ソフトウェアサプライチェーンに安全でないコンポーネントを導入する可能性があり、適切なツールとプロセスでリスクを軽減する必要があります。
では、ソフトウェアサプライチェーンとは何でしょうか? ソフトウェアサプライチェーンは、組織のアプリケーションに入る前にコードを開発するために必要なステップで構成されています。 チェーンには、コードを書いたすべてのオープンソースコントリビューター、コードが依存する依存関係、開発者がコードをダウンロードしたリポジトリ、および組織の内部レビューが含まれます。 チェーン内の各リンクは、安全でないコードや悪意のあるコードが運用アプリケーションに侵入する可能性がある潜在的な弱点を表します。
何がうまくいかない可能性があります
Googleのセキュリティポリシーは 、「攻撃者がコードを挿入することに成功した場合、それはほとんどゲームオーバーです」と指摘しています。 残念ながら、継続的配置 (CD) が一般的になるにつれて、感染したコードをユーザーにリリースする前にこのような攻撃を見つけるウィンドウは狭まっています。
攻撃者の目標はさまざまです。 暗号通貨マイニングのためのリソースの乗っ取り、クレデンシャルスタッフィングのためのユーザー名とパスワードの組み合わせの収集、およびデータスクレイピングはほんの一例です。 結果はしばしば悲惨です。
オープンソースソリューションを使用することの潜在的なリスクのいくつかを調べてみましょう。
一般的な攻撃形態
正規のパッケージを装った悪意のあるソフトウェアは、パッケージ管理ソフトウェアに日常的に表示されます。 サプライチェーン攻撃には、最新のソフトウェアの多数の依存関係であるタイポスクワッティングと依存関係の混乱という2種類があります。 どちらの場合も、加害者はさまざまな戦術を使用して、開発者または管理ソフトウェアをだまして、悪意のあるコードを実行できる依存関係ファイルをダウンロードさせます。
タイポスクワッティング
タイポスクワッティングは、キーボードのキーの近接性と一般的なスペルミスに依存して入力を取得します。 この攻撃方法は、プログラミング言語の基盤を超えています。 Webの初期の頃から、ドメイン名のタイプミスが問題でした。 パッケージと画像の欺瞞はますます蔓延しており、開発者の素早い指に頼っています。
タイポスクワッティングで、発行元がスペルミスのある名前のパッケージをアップロードしました。 スペルミスの名前は元のパッケージの名前と非常によく似ているため、開発者は単語のスペルを間違えたことに気付かず、無意識のうちに悪意のあるコードをダウンロードします。
依存関係の混乱
依存関係の混乱は、ソフトウェアが使用するプライベート依存関係とパブリック依存関係の組み合わせを利用します。 ハッカーは通常、Node.jsアプリケーションのpackage.jsonファイルを検査して、npmで内部の要求されていないパッケージを見つけます。 彼らはこの同じ名前空間で悪意のあるパッケージを作成し、自動化された開発者ツールは、意図した内部パッケージの代わりにこれらの外部の悪意のあるパッケージをインストールします。
この戦術はnpmに限定されません。 たとえば、Pythonのピップは、悪用の機が熟した不安を表示します。 ここで、ハッカーは、要件.txtファイルで識別される内部パッケージと同じ名前のパッケージをPyPiに登録できます。 登録時に、正規のパッケージよりも高いバージョン番号を選択します。 この大きい数値が –extra-index-url を含むビルドに含まれている場合、それが優先され、この一見新しいバージョンが古いバージョンを置き換えます。
タイポスクワッティングと同様に、依存関係の混乱はすべての言語の問題です。 同様の攻撃は、Java の Maven pom.xml ファイルまたは Gradle 設定ファイル、または .csproj でも発生する可能性があります .NET の NuGet パッケージを参照するファイル。 ツールがコードを誤って置き換え、アプリケーションを脆弱なままにします。
これらの問題は、推移的な依存関係のチェーンの奥深くに存在する可能性があることを覚えておくことが重要です。 上の図では、攻撃者が依存関係、依存関係、依存関係を標的にしていることがわかります。 このネスティングにより、エコシステムは管理不能になり、監査が困難になります。
私たちは、開発者が悪意のあるコードベースの変更を行わないことを信頼し、フォーアイレビューポリシーがソフトウェアを保護するというコンテンツを感じるかもしれません。 依存関係がアップグレードされると、他の誰かが私たちの厳格さでレビューを実行していることを信頼します。 しかし、これは小さなチームや個人によって維持されるパッケージには当てはまらないかもしれません。
シナリオ例
悪意のあるアクターは、いくつかのユーティリティ関数のように、一見無害なパッケージを作成します。 これをパッケージXと呼びましょう。
次に、コードをパッケージ配布サイトに発行します。 コードが GitHub で検査可能であるからといって、必ずしもパッケージ管理サイトの同じコードであるとは限らないことに注意してください。
パッケージ Y のコードへのプルリクエストの一部としてパッケージ X を使用し、オープンソースプロジェクトのマイナーなバグを修正します。 彼らの本当に有用なバグ修正は、悪意のある依存関係(パッケージX)とプレストを引き込みました! 悪意のあるコードがリポジトリにあります。
コードがパッケージ Y を使用している場合、ソフトウェアはパッケージ X の脆弱性を継承します。
組織は、隠れた脆弱性のリスクを軽減するために、オープンソースコードを絶えず更新する必要があります。 これらの組織は、自動脆弱性スキャンなどの検出方法を使用して、既知の脆弱性が損害を引き起こす前に特定する必要もあります。
グローバルなニュース報道により、データやセキュリティ違反が迅速に公表されるため、これらのインシデントは組織の評判を損なう可能性があります。 その信頼を再構築することは非常に困難です。
開発者がサプライチェーンを保護できるようにする
開発に伴うすべてのセキュリティリスクは、開発者がセキュリティを可能な限り簡単にするツールにアクセスする必要があることを意味します。 幸いなことに、Dockerはプラットフォーム全体にセキュリティ対策をシームレスに統合して、リスクを軽減し、ソフトウェアサプライチェーンを保護するのに役立ちます。 最初のステップは、構成証明と検証です。 信頼を確立するには、コードを検証する必要があり、そのセキュリティについて何も仮定しないでください。
Docker Business ユーザーが利用できる Docker のイメージ アクセス管理機能を使用すると、組織はソフトウェアの入手先を制御できます。このアプローチでは、アクセスとアクセス許可の制御が開発者からサイト レベルに移行し、オプションを簡単に設定できるトグル オプションと、大規模な承認を管理するためのロールベースのアクセス制御 (RBAC) を使用できます。 この制御により、開発者は承認されたセキュリティで保護されたイメージのみを使用できます。
画像アクセス管理は、ソースが正当であることを保証する良い方法でもあります。 ビジネスに何百人もの開発者がいる場合、各ソフトウェアエンジニアが無邪気にインストールしているものを追跡することは困難になります。 Docker Business ユーザーは、チームとリポジトリの作成、削除、編集を記録する監査ログを取得して、可視性を高めます。
開発者がコンテナー イメージをより適切に決定できるように、Docker には、Docker Hub のバッジを使用してイメージを検証する視覚的な方法が用意されています。 これらのバッジは、Docker 検証済み発行元 イメージと Docker 公式イメージ に固有であり、開発者がプルしているものが信頼され、安全で、使用できる状態であることを開発者に知らせます。
Dockerは、セキュリティパートナーであるSnykを通じて脆弱性スキャンツールも提供しています。 開発者は、CLI で Snyk スキャナーを使用して、ローカルの Dockerfile とローカル イメージのセキュリティ体制に必要な分析情報と可視性を得ることができます。 これには、共通脆弱性識別子 (CVE) の一覧、OS パッケージやライブラリなどのソース、それらが導入されたバージョン、検出された CVE を修復するための推奨される修正済みバージョン (利用可能な場合) が含まれます。 このステップが自動化されると、開発者だけが不安を手動でスキャンすることに頼る必要がなくなります。
安心を得る
パッケージXの例に戻ると、最悪のシナリオを防ぐために複数のレイヤーがあります。
- イメージアクセス管理 により、開発者は信頼できる検証済みのソースからのみベースイメージをプルできます。
- ロールベースのアクセス制御 を使用すると、開発者は、新しいコンテンツを取り込むことができる開発者を制御し、侵害を単一のチームの作業に分離することで、爆発範囲を縮小できます。
- 脆弱性スキャンは 、新しいイメージを構築するときに CVE を自動的にスキャンします。 安全でない依存関係の問題を迅速に解決するために、脆弱性スキャンは開発者の依存関係を精査してフラグを立て、修復オプションを提供します。
- 監査ログ は、すべてのアクティビティをキャプチャする3か月の履歴を提供します。 このレコードは、組織が影響を受けるすべての内部サプライチェーンを迅速に発見するのに役立ちます。
セキュリティに対するこの階層化されたアプローチにより、チェックの機会が増えます。 警戒と手動チェックは依然として理想的ですが、攻撃の防止と対処に役立つこれらのツールを利用できると安心できます。
結論
この記事では、 バイデン大統領が対処した真のサプライチェーンのセキュリティ問題を探りました。
アプリの依存関係を標的にすることで、サイバー犯罪者は精査を回避することを期待して複数の組織に到達できます。 多くの場合、組織がロックダウンされているときに侵入する最も簡単な方法です。 誰もが潜在的な標的であり、攻撃は広範囲にわたる影響を与える可能性があります。 加害者は長いゲームをプレイし、ソーシャルエンジニアリングを使用してアクセスを取得し、おそらくリポジトリメンテナとしての時間を提供することに満足しているようです。 開発者と自動化ツールがコンポーネントをシステムに統合すると、攻撃者がマルウェアを注入する可能性のあるポイントが複数発生します。
Dockerは、アプリケーションに移行する前にオープンソースコードと依存関係を精査するための堅牢なツールスイートを提供します。 Docker Businessを使用すると、ソフトウェア開発は、セキュリティ上の懸念に妨げられることなく、コンテナの生産性向上の恩恵を受け続けることができます。
Docker Business の使用を開始 して、Docker がビジネスの安全性とセキュリティの維持にどのように役立つかをご確認ください。
ドッカーコン2022
5月10日火曜日に開催されるDockerCon2022にご参加ください。 DockerCon は、次世代の最新アプリケーションを構築している開発者や開発チームにとってユニークな体験を提供する、無料の 1 日の仮想イベントです。 コードからクラウドにすばやく移行する方法と開発の課題を解決する方法について学びたい場合は、DockerCon 2022 でアプリケーションの構築、共有、実行に役立つ魅力的なライブ コンテンツが提供されます。 今すぐご登録ください https://www.docker.com/dockercon/
フィードバック
「安全でないソフトウェアサプライチェーンの影響」に関する0の考え