Written with AI assistance from the source video. The video is the authority.
6:21Maximilian Schwarzmüller
Log in to leave a comment
No posts yet
セキュリティ事故のニュースに接した後、夜遅くまでググっているだけの時間はない。2026年5月、悪意あるビジュアルスタジオコードの拡張機能が配布され、開発者のマシーンが侵害され、社内のソースコードリポジトリ約3,800件がそのまま流出した。この状況でむやみにコードを削除したりラップトップをフォーマットすると、フォレンジックの証拠がすべて吹き飛んで原因も特定できない。パッケージマネージャーの実行ログ、グローバルCLIのタイムスタンプ、現在起動しているプロセスの権限を直接調べて、突破されたかどうかを確認しよう。
パッケージマネージャーはインストールの過程でシステムキャッシュディレクトリにトランザクションの記録を残す。npmは npm config get cache のパス内の _logs フォルダーにデバッグログを吐き出し、pnpmは pnpm store path にアーティファクトを置いておく。悪意あるパッケージはインストールの瞬間に実行されるスクリプトを通じて環境変数や資格情報を外部に持ち出すため、ライフサイクルの実行履歴から確認しなければならない。
直近14日分のログを漁って、無許可のパッケージ追加や外部スクリプトの実行有無を捉えるコマンドは次のとおりである。ターミナルを起動して以下のコマンドをそのまま入力する。
`bash
NPM_CACHE_DIR=$(npm config get cache)
find $NPM_CACHE_DIR/_logs/ -type f -mtime -14 -exec grep -Hn "lifecycle" {} +
`
結果画面から、自分が意図していない preinstall や postinstall フックが実行されたかどうかを確認する。3分で終わる。不審な外部URLとの通信記録がなければ、パッケージレベルの直接的な汚染の恐怖からはひとまず安心できる。
攻撃者はラップトップの中に潜伏するために、グローバルCLIツールやnpxキャッシュに悪意あるバイナリを埋め込む。グローバルインストールされたパッケージの一リストを取得し、バイナリフォルダーのファイル作成日と更新日をシステムログと照合して整合性を確認する。
`bash
npm list -g --depth=0 --json
ls -lact $(npm config get prefix)/bin/
`
修正のタイミングが不審な時間帯と重なっている場合は、以下のコマンドでハッシュ値を算出して照合する。
`bash
shasum -a 256 $(npm config get prefix)/bin/
`
パッケージのインストールスクリプトは開発者アカウントの権限のまま実行される。バックグラウンドで動作しているデーモンプロセスを停止させなければならない。
`bash
ps aux | grep -E "node|npm|pnpm|bun" | grep -v grep
lsof -i -P -n | grep -E "node|npm|pnpm"
`
不審なプロセスが外部のC2サーバーと通信している場合は、直ちに強制終了させる。
`bash
kill -9 [PID]
npm config set ignore-scripts true
`
サプライチェーン攻撃の定番パターンは、設定ファイルを改ざんしてレジストリを乗っ取る手口である。攻撃者はプロジェクト内の .npmrc ファイルやグローバル設定に悪意あるミラーサーバーのアドレスを埋め込む。ロックファイル内のダウンロードURLのパスを書き換えて、実際のインストール時に悪意あるtarballを受け取るように仕向けるため、設定値を隅々まで確認する必要がある。
ローカル設定とグローバル設定に未承認のオーバーライドが埋め込まれていないかを確認する手順は次のとおりである。まず設定バインディングの一覧を取得する。
`bash
npm config list
pnpm config list
`
次に、社内のプライベートレジストリのスコープが正しく設定されているかを確認する。
`bash
npm config get @company:registry
`
ユーザーのホームおよびプロジェクトルートの設定ファイルに外部のミラーアドレスがハードコードされていないかも直接検索する。
`bash
grep -Rn "registry" ~/.npmrc ./.npmrc
`
この3つのステップを経ることで、不審なミラーアドレスが登録されているかどうかを5分以内に判別できる。
package-lock.json と pnpm-lock.yaml ファイルは依存関係のダウンロード元のURLを記録しているため、正規表現を用いて汚染の有無を調べる必要がある。
`bash
grep -E '"resolved": "https?://' package-lock.json | grep -vE 'registry.npmjs.org|registry.corp.example'
`
pnpmを使用している場合は、以下のコマンドを入力する。
`bash
grep -E 'resolution: {tarball:' pnpm-lock.yaml | grep -vE 'registry.npmjs.org|registry.corp.example'
`
汚染されたロックファイルが見つかった場合は、すべて削除して新しく作成し直す必要がある。
`bash
rm -rf node_modules package-lock.json pnpm-lock.yaml
npm cache clean --force
pnpm store prune
npm config set registry https://registry.npmjs.org/
npm ci --ignore-scripts
`
ライフライクルのスクリプト実行を無視し、不変の状態の依存関係ツリーを再構築することで、クリーンな状態の環境を確保することができる。
悪意あるバイナリはLinuxおよびMac環境においてブラウザのパスワード保存領域を漁り、環境変数に設定されたAIのAPIキー、AWS Access Key、SSHキーをごっそり持ち去る。ターミナル環境において認証情報が露出していないかを今すぐ点検しなければならない。
`bash
ls -la ~/.ssh/
env | grep -E 'TOKEN|KEY|SECRET|AUTH|AWS|GITHUB|OPENAI|ANTHROPIC'
grep -E '(ghp_[A-Za-z0-9]{36}|AKIA[0-9A-Z]{16}|bearer)' ~/.zsh_history ~/.bash_history
`
平文で露出しているキーが見つかった場合は、容赦なく直ちに無効化する。GitHub CLIでログインしているトークンのスコープも確認する。
`bash
gh auth status
`
すべてのリポジトリへのアクセス権限が付与されたClassicトークンは今すぐ削除する。PATを再作成する際は特定のリポジトリのみを指定し、読み取り権限も最小限の範囲に抑えておく。
ローカルホストと開発プロセスを隔離するには、DevContainerの構成を使用する必要がある。プロジェクトのルートに .devcontainer/devcontainer.json ファイルを作成し、以下のようにイメージを設定する。
`json
{
"image": "mcr.microsoft.com/devcontainers/javascript-node:22",
"postCreateCommand": "npm ci --ignore-scripts"
}
`
このようにコンテナを起動すると、パッケージのインストールやビルドがラップトップ本体のシステムの認証情報から完全に隔離された状態で実行されるため、社内資産の流出経路を根本から遮断することができる。