Alex Birsanは最近、「依存関係の混乱:Apple、Microsoft、その他の数十の企業にハッキングした方法」という記事を公開しました。この記事では 、 npm(Javascript)、pip(Python)、gems( Ruby)企業にインフラストラクチャに悪意のあるコードをインストールして実行するように強制します。
問題は、たとえば
my-internal-package
、企業が内部パッケージを名前で参照し 、攻撃者が言語パッケージの中央レジストリ/リポジトリ(PHPの場合はpackagist.org)に同じ名前のパッケージを公開するという 事実に帰着します。
my-internal-package
より高いバージョンを持っています。次に、パッケージマネージャーが内部リポジトリではなく標準パッケージリポジトリからより高いバージョン番号を選択していたため、企業は内部パッケージの代わりにこれらの悪意のあるパッケージをインストールして実行しました。
TwitterでComposerとPackagistのこの問題の解決策について話し、 Geordieは、 ComposerとPackagistがこの深刻な問題から企業を保護するために使用しているさまざまな対策を要約しました。
- Composer , ,
my-company/our-internal-pkg
. packagist.org. Packagist.org .my-company/
. packagist.org ( ), ,my-company/dummy-pkg
, , , .my-company/my-internal-package
, «» packagist.org. - Composer 2.0, . , , . packagist.org, . , , , Composer .
- Private Packagist , packagist.org, , , . Private Packagist Composer 1.x , Composer 2.
- Private Packagist packagist.org , Composer. , .
- Composer (lock file) URL . composer install, , . , , .
- Composer 2では、各リポジトリのパッケージ名またはパターンのロードを除外できます。したがって、packagist.orgにプレフィックスが登録されていないとスペルが間違っているパッケージでも、composer.jsonのデフォルト構成を置き換えることで、packagist.orgからダウンロードできないようにすることができます。この除外フィルターは、追加のサードパーティパッケージリポジトリにも使用できます。
"repositories": {
"private-repo": {
"url": "https://my-repo.internal"
}
"packagist.org": {
"url": "https://repo.packagist.org",
"exclude": ["myprefix/*"]
}
}
アレックスが説明したものと同様のサプライチェーンへの攻撃は、企業にとって深刻な脅威であり、最近ニュースで取り上げられているため、ビジネスが直面するリスクを理解し、それらを軽減するための措置を講じることが重要です。
広告
プロジェクトをデバッグするためのVDS、開発と展開のためのサーバーをお探し ですか?あなたは間違いなく私たちのクライアントです:)サーバーの毎日の請求、数回のクリックで独自の構成を作成し、アンチDDoSおよびWindowsライセンスはすでに価格に含まれています。