npmパッケージのサプライチェーン攻撃が新たな段階に突入した。これまでの攻撃は理論上の脅威に留まっていたが、今回のShyhalud攻撃では実際に被害が発生し、PostHogを含む800以上のパッケージが侵害された。攻撃者はGitHub ActionsのCI/CD環境を悪用し、pre-installスクリプトを通じてシステムに侵入、AWS・GCP・Azureのシークレット、環境変数、npmトークンを窃取し、さらに他のパッケージへと感染を拡大させるワームのような挙動を示した。PostHogへの攻撃は外部貢献者によるプルリクエストを発端とし、pull_request_targetトリガーの脆弱性を突いてGitHub Personal Access Tokenを盗み出すという巧妙な手口であった。この事態はJavaScriptやnpmの問題ではなく、CI/CD環境における権限管理とコード実行の複雑性に起因するものであり、オープンソース開発者が公開性ゆえに攻撃の標的となるという皮肉な現実を浮き彫りにしている。
npmサプライチェーン攻撃の新たな段階
やれやれ、今年5回目くらいになりますが、またnpmパッケージが大量に悪用されてしまいました。以前私がこれらのnpmエクスプロイトについて取り上げた際、特に指摘したことがあったのを覚えている方もいるかもしれません。そのハッキング手法は実に巧妙でした。様々な暗号通貨のアドレスの形状に大まかに一致する文字列を探し出し、それを見つけると、開始部分と終了部分が何となく似ている、ハードコードされた数百個のアドレスの中の1つと入れ替えるというものでした。
入れ替えられても、送信ボタンを押す前にアドレスの変更に気づく可能性が低くなるわけです。正直なところ、かなり賢いやり方です。ただし、これはアプリケーションにバンドルされるフロントエンドパッケージにのみ影響するという点を除けばの話ですが。
つまり、これがあなたに影響を与える可能性があったのは、影響を受けたパッケージを使用しているウェブサイトにいて、そのパッケージがアップデート後にインストールされ、それがウェブサイトにバンドルされ、影響を受けたパッケージを含む新バージョンのサイトがデプロイされた場合のみです。これがあなたに影響を与えるためには、驚くほど多くのことが8時間という短い時間内に起こらなければならないのです。
影響を受けた18個のパッケージ、いや19個のパッケージのうち、フロントエンドに含まれる可能性があったのは1つだけで、ここで攻撃を受けたパッケージの大部分は、彼らが構築したハッキング手法では機能しません。しかし、これらのハッカーは仕事があまり上手ではなく、バックエンド向けのnodeパッケージやツール向けのパッケージに対応したハックを用意していなかったため、fetchやDOMノードアクセスなどの特定の機能を必要とするフロントエンドハックを埋め込んでいました。そう、これらのエクスプロイトが以前に大きな問題を引き起こさなかったのは、事実上運が良かっただけなのです。
実被害が発生した最新のサプライチェーン攻撃
そして、私たちの運は尽きてしまったようです。なぜなら、最新のサプライチェーン攻撃は今回、潜在的な実際の被害をもたらしたからです。もはや理論を構築しているのではありません。もはや被害を引き起こす可能性のある仮想的な攻撃を見ているのではありません。実際に起こってしまったのです。
私たちは今ここにいます。そして、私たち自身もT3 Chatでほぼ影響を受けるところでした。なぜなら、私たちの依存関係の1つであるPostHogが攻撃を受けたからです。本日早くに公開されたライブラリバージョンのいくつかに悪意のあるコードが含まれていることを確認しました。現在、パッケージマネージャーからこれらのバージョンを非推奨にし、クリーンなバージョンのライブラリを再公開する予定です。
これまでに確認されたバージョンへの影響については、大規模な依存関係のチェーンとツリーのメンテナンスがどのように機能するかから、npmがパッケージのバージョンを非公開にすることを許可していないことがいかに悪いか、npmのような大規模で多様でリスクの高いシステムでこれらすべてに対処することが全くのカオスであることまで、多くの層があります。
一方では、このようなことをもっと多く見てこなかったことは幸運です。しかし他方では、私たちが構築するアプリケーションと、私たちが構築するエコシステムが確実に安全であり続けるために、真剣な変革が必要な時期に来ています。特に、私たちがデプロイするコードを読む機会がますます少なくなっていく世界においては。
もし私が怪しいパッケージをデプロイして、本来アクセスすべきでない資格情報へのアクセスを盗むことを選べば、かなりの金額を稼げることがますます明白になっています。でも、私は決してそんなことはしません。代わりに、今日のスポンサーから少しお金をいただきましょう。
私のビジネスであるT3 Chatは順調に進んでいます。多くの人は、それが私が有名だからだと思っているようですが、人気はある程度買えるものです。私のような人にアプローチして、あなたの製品について話すよう説得することはできます。私の人気が役立っているのはそこではありません。
しかし、私の人気が与えてくれる1つの大きな利点があります。それは採用パイプラインです。私はこの業界で最高のチームを持っています。他の会社が、私が雇うことができた人材の質だけで私たちに勝てる世界はありません。雇用できる人々の素晴らしいコミュニティを持てたことは、本当に幸運です。しかし、誰もがそうではありません。そして、おそらくあなたも確実にそうではないでしょう。
リクルーターにお金を払ってLinkedInで人々にスパムを送ることもできます。あるいは、世界最高のエンジニアのネットワークに入り込み、これらすべてに永遠に時間がかかったり、莫大な費用がかかったり、結果として低品質な採用になったりすることを心配することなく、最高の品質基準で必要なものだけを雇うこともできます。だからこそ、本日のスポンサーであるG2Iをぜひチェックすべきです。
これは、時間とお金を無駄にして適切なエンジニアを1人か2人見つけようとすることなく、優秀なエンジニアを雇う最良の方法です。彼らの8000人のエンジニアネットワークは、ランダムな大学卒業生の集まりではありません。これらは実際の業界経験を持ち、最初の面接から最初のPRマージまで1週間以内に準備ができている人々です。
狂気じみて聞こえますが、私は何度もそれが起こるのを見てきたので、実際に信じています。G2Iは、あなたが探している採用チームであり、これまでに作られた最高の採用プラットフォームであり、あなたが具体的に必要とする期間と経験レベルに応じた適切なエンジニアを獲得するための最速の道です。
採用を行うのにこれ以上良い場所はありません。そして、私が探している企業があるとき、最初に紹介するのがG2Iです。私が投資しているすべてのスタートアップに勧めている理由を知りたいですか? 今すぐsodv.link/g2iでチェックしてください。
Shyhaludキャンペーンの詳細
Shyhaludが再び襲来しました。Shyhaludキャンペーンの新たな波がnpmを襲い、500以上のパッケージの700以上のバージョンが影響を受けました。Zapier、Async API、Postman、PostHog、ENS domainsからの複数のnpmパッケージが、アカウント乗っ取りと開発者の侵害によって侵害されました。この悪意のある攻撃者は、これらのパッケージに以下の変更を加えました。package JSONファイルにpre-installスクリプトsetup_bun.jsを追加しました。そう、bunのセットアップです。
人々が興奮している新しいものを潜り込ませて、実際に何かを悪用する方法として賢いですね。これはステルスローダーであり、静かにbunランタイムをインストールまたは配置し、その後、すべての出力を抑制した状態で、environment.jsという10メガバイトの難読化されバンドルされた悪意のあるスクリプトを実行します。では、これはどのように起こったのでしょうか? これは2段階のローダーでした。
npmはpre-installスクリプトを実行し、setup_bun.jsを実行します。pre-installスクリプトは非常に怪しく、ありがたいことに、ますます多くのパッケージマネージャーが承認なしでそれらを実行することを拒否しています。pre-installスクリプトのポイントは、インストールを実行したときに何かを実行できることです。post-installも少し怪しいですが、それほど悪くはありません。
アイデアは、このパッケージをインストールすると、その前後に何かを実行できるコードを実行できるということです。良い例はPrismaです。npm install Prismaを実行し、プロジェクト内にPrismaパッケージまたはディレクトリがあることを検出すると、Prismaスキーマのタイプを持つように、実際のコードベース内のPrismaモジュールを更新するコード生成ステップを実行できます。
これは、ORMがデータベース内のデータを知りたい場合には素晴らしいことです。しかし、インストール直後にそのコードを生成する必要がある怖いスクリプトを介してそれを行うという事実は、少し奇妙です。そして、これは悪意のある攻撃者によって大いに悪用される可能性があります。ここで話しているこのpre-installスクリプトは、OSアーキテクチャを検出し、その特定のプラットフォーム用のbunランタイムをダウンロードまたは配置します。
キャッシュディレクトリにbunバイナリをキャッシュし、このbun environmentファイルを実行するデタッチされたbunプロセスを生成し、その後、すべての標準出力エラーを抑制してすぐに返します。パッケージのインストールは正常に完了しますが、ペイロードはバックグラウンドで実行されます。
GitHub検索を介したC2発見
メインペイロードを実行する前に、マルウェアはビーコンフレーズ「sh1 hood the second coming」を検索して、公開GitHubリポジトリを検索することで自己修復を試みます。
見つかった場合、GitHubアクセストークンを含む保存されたファイルを読み取り、3層のBase64を介してデコードし、その後、復元されたトークンをエクスフィルトレーションの主要な資格情報として使用します。Base64を3回行うのは巧妙です。なぜなら、検出可能な署名やキーを出荷していないことになりますが、Base64デコードを試みて結果がさらにナンセンスになった場合、それが何か別のものを意味するとは想定しないからです。しかし、Base64を3回行うというのは、識別可能なキーを出荷しないための奇妙で賢い方法です。
その後、実行されている環境のフィンガープリントを取得します。GitHub actionsのrunner OSをチェックしたり、build kite、code buildなど、CI環境にいる場合に存在する可能性のあるすべてのフラグや変数をチェックしたりして、CIおよびCD環境を検出します。
GitHub actionsにいる場合、疑似操作を通じてルートアクセスを取得しようとします。疑似アクセスがある場合はそれを使用し、ない場合はDocker権限を悪用して、疑似アクセスを持つことを可能にする新しい疑似更新を書き込もうとします。そして、どうやらこれは、GitHub actionsでパスワードなしのルートアクセスを持つマルウェアに対して機能するようです。素晴らしいですね。
特権を取得すると、DNSとファイアウォールの操作を行います。systemd resolvedを停止します。私の理解では、これによりアクションが停止するのを防ぎます。DNS設定を置き換え、リゾルバーを再起動し、IPテーブルをフラッシュします。そして今、あなたのCIに中間者攻撃が仕掛けられています。
つまり、あなたがそこで行っているネットワーク上のすべてのことが、すべてのトラフィックを見るために彼らがハイジャックしたこのDNS層を経由して実行されることになります。そして、パッケージインストールを悪意のあるミラーにリダイレクトできます。セキュリティスキャナーがインターネットに到達するのをブロックできます。セキュリティ更新さえ防ぐことができます。恐ろしいことです。では、そこに到達したら彼らが行ういくつかのことを紹介しましょう。
環境変数を収集します。素晴らしいですね。これにより、AWSキーから推論用のOpenAIキー、その他すべてのものまで、すべてを取得できます。あなたはこれらの企業にStripeキーを渡したくないでしょうが、今やこれらの怪しい悪意のある攻撃者がそれらを取得できるのです。また、truffle hogを使用してハードコードされたシークレットをスキャンし、コードベース内にあるすべてのシークレットを見つけることができます。
その後、クラウドプロバイダーAPIを呼び出して、AWS、GCP、またはAzureのものにアクセスできるかどうかを確認しようとします。ここでの呼び出しは、存在する場合はAWS用のパッケージを使用して、run secretsという変数または関数にアクセスし、AWSのシークレットを取得しようとします。GCPでも同じです。Azureでも同じです。
AWSモジュールは、利用可能なすべてのリージョンをループし、それぞれのAWSシークレットマネージャーからすべてのシークレット値を列挙してダンプします。このリージョナルスイーピングは異常に積極的であり、マルチリージョンデプロイメントにおける資格情報の収集を大幅に増加させます。恐ろしいです。
自動化された資格情報スクレイピング
そして、自動化された資格情報スクレイピングでGitHub actionのシークレットを盗聴します。なんてこった、これらのどれか1つでも非常に悪いのに恐ろしいですが、さらに悪化し続けています。データのエクスフィルトレーション。盗まれたGitHubトークンを使用して、被害者のアカウントを使用してGitHubリポジトリを作成します。
リポジトリ名はランダムに生成されます。一部のリポジトリは、キャンペーンマーカーとして「shaed the second coming」という説明で作成されます。これらの連中は自分たちの成功を自慢するのが大好きなのです。そして、トリプルBase64エンコーディング。ああ、見てください。私は予想していました。なぜ彼らがこれをしたのか分かっていました。
これは組み込みのシークレットスキャンを回避します。サードパーティのシークレット検出ツールをバイパスします。リポジトリをカジュアルに閲覧しているだけでは何も見えず、それを探してスクロールしても何も見えず、盗んだデータのフォレンジック分析を複雑にします。
そして、被害者のリポジトリに5つのJSONファイルをアップロードします。システム情報、環境変数、Azureシークレット、truffle hogの発見、そしてGitHub actionのシークレットです。そして、これを公開リポジトリとして公開するので、彼らは常にGitHubをスキャンしてこれらの特定のフラグを探し、トークンをすばやく取得できます。
マルウェアの伝播メカニズム
そして、彼らがどのように伝播したかを紹介します。おそらくCIハイジャック中にnpmトークンを探し、見つかった場合はnpmレジストリに対して検証し、そのメンテナーによるすべてのパッケージを取得し、それぞれに対してupdate packageを呼び出します。これにより、パッケージをダウンロードし、セットアップファイルを注入し、pre-installスクリプトを追加するためにpackage JSONにパッチを当て、パッチバージョンをバンプします。たとえば1.0の場合、1.0.1にバンプし、その後、悪意のあるバージョンを公開します。
そして、多くの人がGitHub actions上でnpmのデプロイメントを設定しているため、これはPostHogで見たものを含めて大量のものに影響を与えることになります。私は、彼らの依存関係の1つが悪意があり、その依存関係が含まれていたと想定していましたが、PostHogパッケージの実際の悪意のあるバージョンが、PostHog自体のコード内に含まれて公開されたようです。
これは、開発者がJavaScriptエコシステムについて何も理解していないように見えた以前のハックとは正反対です。これらの連中はそれを非常によく知っており、ここから可能な限りすべての悪用の可能性を絞り出したようです。
また、npm underscoreというプレフィックスが付いたものを探して、このCI完全からnpm乗っ取りチェーンを作成するために、GitHub actionで実行される一般的なトークンマイニングもあります。
侵害されたGitHub actionワークフローは、シークレットに保存されたnpmトークンを明らかにし、それが追加のパッケージを汚染するために使用されます。この自動化されたピボットメカニズムにより、ワームは直接的なnpmトークン環境変数がなくても伝播をブートストラップできました。
自己破壊機能
そして、そこで有用なものが見つからない場合、自己破壊します。ああ待って、それ自体を削除しているだけではありません。システム上で触れることができるすべてのものを削除しています。Windowsでは、ユーザープロファイル内のすべてのファイルを削除します。ディレクトリを削除し、cipher呼び出しですべての空き領域を上書きします。
LinuxとMacでは、すべての書き込み可能なユーザーファイルを見つけ、シングルパス上書きでシュレッドし、その後、空のディレクトリを削除します。
これまでスクロールしていないのに、なぜこんなに長いのか不思議でした。右側のスクロールバーを見ると、ページの5分の1未満しか進んでいません。その理由は、記事の残りの部分がすべて、これまでに感染したことが分かっているパッケージのリストだからです。問題が見えますか? これまでに分かっているだけで834個が攻撃を受けました。
PostHogの事後分析
PostHogは彼らの偽のOSウェブサイトで事後分析2を行いました。これを簡単に見てみましょう。では、これはどのように起こったのでしょうか? PostHog自身のパッケージ公開資格情報は、上記のワームによって侵害されませんでした。彼らは、攻撃のペイシェントゼロとして機能するために、他の多くの主要ベンダーと同様に直接標的にされました。
つまり、PostHogは特に標的にされた最初の被害者の1つでした。攻撃者が最初に取ったステップは、彼らのボットの1つのGitHub Personal Access Tokenを盗み、その後、それを使用してCIランナーで利用可能な残りのGitHubシークレットを盗むことでした。これらのシークレットには、このnpmトークンが含まれていました。これらのステップは、攻撃の数日前、11月24日の11月18日5時40分に行われました。
次に、BRWJというランダムなもののようなGitHubユーザーを削除し、このコミットを含むpostリポジトリに対してポールリクエストを作成しました。これはタイポ修正のPRであり、output is exact sync web hook.ITE/greatという内容を追加しています。これは確実に超怪しくないと確信しています。
PRは、外部貢献者に対して実行していたワークフローによって実行されるスクリプトのコードを変更し、そのスクリプトの実行中に利用可能なシークレットを攻撃者が制御するwebhookに送信するように変更しました。
これが、従業員やチーム外の人々が提出したPRに対してCIを実行することが非常に怖い理由です。なぜなら、誰でも悪意のあることを行うPRを提出でき、それが任意の環境で実行されると、おそらくそれを使って怪しいことができるからです。そして、それがここで起こったことです。
シークレットには、組織全体にわたって広範なリポジトリ書き込み権限を持っていたボットの1つのGitHub Personal Access Tokenが含まれていました。PR自体は、ユーザーが削除されたときに、それが由来したフォークとともに削除されましたが、そのコミットは削除されませんでした。PRは開かれ、ワークフローが実行され、PRはクローズされました。すべて1分以内に。
そして5日後、攻撃者は資格情報を使用してワークフロー実行を削除しました。私たちは、これが盗まれた資格情報がまだ有効かどうかをテストするためだったと考えています。そして、それは成功しました。そのため、20分弱後、15分さえかからずに、彼らは資格情報を再び使用しましたが、今回はレポートの著者になりすましたコミットを作成するためでした。
私たちは、これが著者がたまたま最後の正当な貢献者であったランダムに選ばれたブランチであると考えています。著者がGitHubアカウントに社会的特権を持っていないことを考えると。このコミットは、ポールリクエストや類似のものの一部としてではなく、デタッチされたコミットとして直接公開されました。
その中で、攻撃者は任意のlint PRワークフローを直接変更して、すべてのGitHubシークレットをエクスフィルトレートしました。ワークフローから呼び出されたスクリプトのみを変更でき、そのためボットのpersonal access tokenのみをエクスフィルトレートできた以前のPR攻撃とは異なり、このコミットは超許可的なpersonal access tokenを考慮すると、リポジトリへの完全な書き込みアクセス権を持っていました。つまり、GitHub actionランナーのスコープで任意のコードを実行できたということです。
これで、彼らはすべてのランナー、すべてのGitHub actionsを制御し、そこから欲しいものを何でも取得できます。そして、攻撃者は完了後にワークフロー実行を削除するため、これらのものを監査して特定することが本当に困難でした。この時点で、彼らはnpm公開トークンを持っていました。
そして12時間後、翌朝UTC午前4時11分に、悪意のあるパッケージをnpmに公開し、このワームの拡散を開始するのに役立ちました。PostHogは、この広範な攻撃の初期ベクトルで使用された唯一のベンダーではありませんでした。他のベンダーも、独自の監査ログで同様の攻撃パターンを特定できると予想しています。
では、なぜこれが起こったのでしょうか? PostHogは誇らしげにオープンソースです。そして、それは多くのリポジトリが頻繁に外部からの貢献を受けることを意味します。私のチームでさえPostHogに貢献していて、それは本当にクールなことです。貢献が変更したコードベースのどの部分に応じて、自動的にレビュアーを割り当てます。通常、GitHub codeファイルがこれに使用されます。
しかし、レビューを、自分が所有していないコードに取り組んでいる可能性のある内部貢献者に対してPRをブロックするのではなく、ソフト要件にしたいと考えています。彼らにはこれを行うことになっているワークフローがありましたが、適切な人々に自動的にタグを付けるという目的を無効にする手動承認が必要だったため、外部貢献者に対しては決して機能しませんでした。
そのため、エンジニアの1人がこれに気づきました。それは、フォークから来る外部貢献者にはワークフローが実行されないことを意味するpull requestでトリガーされたためです。そこで、彼らはそれをon pull request targetに変更しました。これはYAMLの異なる呼び出しで、同じリポジトリのブランチでプルリクエストが行われたときではなく、リポジトリでPRが形成されるたびにトリガーが実行されるようにします。
この変更は安全に思えました。なぜなら、彼らの理解では、これはマスターまたはターゲットリポジトリにあるコードを実行するというものだったからです。しかし、これはワークフローが定義されたとおりに実行されることを保証するだけであり、コードが正しいコードであることを保証するものではありません。なぜなら、そこで実行されるコードは任意のコードである可能性があるからです。
彼らは、これで実行されるコードがプルリクエストからのコードではなく、リポジトリからのコードであると想定していましたが、それは真実ではありません。彼らは自分たちのランナー上で任意のコード実行を設定してしまったのです。GitHub CIが十分に簡単ではないことのさらなる証拠が必要な場合は、これがそれです。
外部貢献者に対してこれが実行されるようにするためにunderscore targetを追加するという1つのシンプルで無邪気な変更が、彼らのサーバー上でのリモートコード実行、いや彼らのCI上での、まあ同じことですが、それを可能にしてしまったのです。正気の沙汰ではありません。
そして、これが彼らがその変更をマージした理由です。なぜなら、それは一見無邪気だったからです。従業員の1人が、外部PRに対してより良いフィードバックを提供するためにこれを望んでいました。レビューした人も同じように考えました。これは全く問題ありませんでした。そして、PRがマージされてからこの攻撃が発生するまでの1ヶ月半の間、誰もセキュリティホールに気づきませんでした。
そして、同じ問題を抱えている他の場所、GitHub上の他のリポジトリがたくさんあると確信しています。ワークフロールール、トリガー、および実行コンテキストは、推論するのが難しいです。非常に推論が難しいため、GitHubは積極的に変更を加えて、それらをよりシンプルにし、上記の理解に近づけようとしています。ただし、私たちの場合、これらの変更は初期攻撃から私たちを保護することはできなかったでしょう。
また、この特定の攻撃をコピーしようとする模倣犯もおり、彼らはそれを防ぐためにイライラするような手動で不確実な対策を講じなければなりませんでした。GitHubがpull request targetの動作に加えている変更は、それらの模倣犯攻撃を自動的に防いでいたでしょう。
PostHogの今後の対策
そして、これが彼らが今後これを修正する方法です。はるかに厳格な精査、pnpm10へのパッケージリリースワークフローの強化により、pre-installおよびpost-installスクリプトが無効になります。非常に良いことです。もう一度言いますが、良いパッケージマネージャーを使用してください。これらの多くのことに大いに役立ちます。彼らにはセキュリティ担当者がいます。彼らは正しいことをしています。良い変更を行っています。そして、彼らだけではありません。
npmはサイトの上部にこのバナーを掲載しています。クラシックトークンの作成が無効になりました。既存のクラシックトークンは2025年12月9日に取り消されます。中断を避けるために、信頼できる公開またはグラニュラーアクセストークンに移行してください。彼らは、何でもできるこれらの包括的なトークンを取り除こうとしています。なぜなら、それらは巨大なセキュリティリスクだからです。
では、これを全体として防ぐにはどうすればよいでしょうか? CI/CDを保護する必要があります。上記にリストされているパッケージのいずれかがある場合は、すぐに削除し、nodeモジュールフォルダーを削除してください。これらのパッケージがシークレットまたは資格情報へのアクセス権を持つ環境にインストールされた場合、悪意のあるコードが機密情報をエクスフィルトレートした可能性があるため、すべてのAPIキー、トークン、およびパスワードを直ちにローテーションしてください。
OpenJSのガイダンスに従い、npmへの公開に対する異なるアプローチの長所と短所を理解してください。以下に示すように、Shawa and Haladの説明を含むShawa and Halad the second comingという説明を持つ奇妙なリポジトリをGitHubでチェックしてください。そう、このような見た目のリポジトリを見たり、いつでもそのようなリポジトリを持っていた場合は、すべてのシークレットを無効化してください。もう終わりです。
この記事を書いたSocketには、同様に役立つ無料のGitHubアプリもあります。私はSocketの連中が本当に好きです。この種のものを防ぐのに役立てたい場合は、間違いなく検討する価値があります。彼らはファイアウォールも持っており、ほとんどの依存関係がマシンに到達する前にブロックします。
事件から学ぶべき教訓
さて、起こってしまいました。このようなものは常に脆弱でした。しかし、実際に興味深いのは、npmが脆弱な部分であるようには見えないことです。私はそうだと思い込んでいました。それはGitHubです。それはCIです。それはオープンソース開発者が物事を公開で行うことに対する罰の方法です。
考えてみれば、PostHogがオープンソースでなければ、これは起こらなかったでしょう。オープンソースのメンテナーと開発者が公開で構築する方法を共有することの結果であり、悪意のある攻撃者がプルリクエストを提出する行為を通じて忍び込み、何かを実行できるようになるということは、ある意味クレイジーです。
私の最大の恐れは、これがnpmとJSエコシステムに関するFUDを引き起こすだけでなく、企業がオープンソースにしないインセンティブを増やすことにつながることです。これらは、ここから学ぶべき間違った2つの教訓です。
このすべてを見た後のあなたの想定が、npmは安全でない、JavaScriptをパッケージに使用すべきではない、オープンソースは悪い、なぜならハッキングされる可能性があるからだというのであれば、私にはあなたに売りたいさまざまな橋がたくさんあります。連絡してください。
ここでの教訓は、CIは複雑であり、CIプロセスが悪意のある攻撃者に実行してほしくないものを実行させないようにすることが重要だということです。それが起こる方法はたくさんあります。ボックスで実行されているコードのトリガーに対して先ほど見たフラグを介してかもしれません。
非常に怪しく、問題を引き起こす可能性のあるpre-installおよびpost-installスクリプトがある可能性があります。それは多くの異なるものである可能性があります。しかし、開発者として、何がコードをシステム上で実行させるのかを知り、実行させたくないコードを実行させないことが重要です。
これはJavaScriptや他の言語や他のツールセットに特有の問題ではありません。これは、CIのような任意の環境でコードを動的に実行できるようにすることの性質である問題です。
したがって、AIがエンジニアとしての私たちの仕事をすべて置き換えると思うなら、セキュリティに取り組んでください。あなたの前にやるべきことがたくさんあるようです。これらの悪意のあるパッケージバージョンのいずれかをインストールしていないか確認し、インストールしている場合はシークレットをクリアしてください。
うまくいけば、これが役に立ち、少し怖くなったことを願っていますが、非合理的な方法ではありません。GitHub actionsやコードを実行できるようにする他のものには注意してください。そして次回まで、平和をオタクたち。
コメント