ある開発者のもとに、好条件のスカウトが届きます。やり取りはスムーズで、選考の一環として「このリポジトリをローカルで動かして、簡単な課題を解いてほしい」と言われる。エンジニアにとってごく自然な依頼です。けれど、その npm install と「動作確認」のひと手間が、端末にバックドアを仕込む引き金だった——A backdoor in a LinkedIn job offer で報告されたのは、まさにこの手口です。技術的な脆弱性を突くのではなく、「いい求人」という人間の心理を突いて、開発者自身に悪意あるコードを実行させる攻撃です。
受託開発に携わる人にとって、これは他人事ではありません。開発者の端末には、クライアントのソースコード、本番環境への SSH 鍵、クラウドの認証情報、各種 API トークンが集まっています。一人の開発者の端末が乗っ取られれば、被害は受託先全体に波及する——この構造を理解しておく必要があります。
なぜ「偽求人」が刺さるのか
サプライチェーン攻撃というと、改ざんされたパッケージが配布される話を思い浮かべます（その全体像は 2026年サプライチェーン攻撃まとめ（GH Media） に整理しました）。偽求人型はその一種ですが、入り口が「人」である点が厄介です。
- 警戒が緩む文脈：採用選考という「信頼が前提の場」なので、相手のコードを疑いにくい
- 実行が自然：コーディング課題は「動かして確認する」のが当たり前で、不審に見えない
- 標的が選ばれている：転職を考えていそうな、特定スキルを持つ開発者が狙い撃ちされる
- 検知が遅れる：マルウェアは「課題」の依存パッケージやビルドスクリプトに紛れ込み、表からは見えない
npm install や make、docker compose up の一発が任意コード実行になりうる構造そのものは、求人に限らず受託開発に常につきまといます。この本質は 「npm install は任意コード実行」時代の受託開発環境（GH Media） でも掘り下げました。
「素性の分からないコードを、母艦で動かさない」を仕組みにする
防御の中心は、ルールの徹底ではなく環境の分離です。「怪しいリポジトリは動かさない」という心がけは破られますが、「そもそも母艦の端末では動かせない」状態を作れば、人間の油断が事故に直結しなくなります。
| 守りたいもの | 具体策 |
|---|---|
| 顧客の鍵・ソースが載る母艦端末 | 素性不明のコードは隔離環境（使い捨てVM・コンテナ・クラウド開発環境）でのみ実行 |
| 依存パッケージ経由の実行 | npm install --ignore-scripts を既定にし、postinstall を明示許可制にする |
| 認証情報の漏えい | 本番鍵を端末に常駐させず、短命トークン化・必要時のみ発行する |
| 異常の検知 | 不審な外部通信・プロセスを検知できるよう端末監視（EDR）を入れる |
要は、「課題を動かす」行為をクライアント資産から物理的に切り離すことです。隔離環境を一手間で立ち上げられるよう標準化しておけば、開発者は「とりあえず母艦で動かす」必要がなくなります。開発環境の標準化そのものは 受託開発の環境標準化（GH Media） にまとめています。
受託チームで決めておく「採用導線セキュリティ」
技術的な分離と合わせて、チームの運用ルールも軽く整えておくと効果的です。実際に私たちがクライアントの受託チーム向けに提案するのは、次のような最小限の取り決めです。
- 選考課題・スカウト由来のコードは隔離環境専用とし、母艦での実行を禁止する
- 受け取ったリポジトリは、動かす前に
package.jsonのscriptsと依存の追加分にざっと目を通す - 業務端末に常駐する認証情報を棚卸しし、「なくても回る」鍵は端末から外す
- 不審なスカウトや課題に気づいたら、責めずに共有できる窓口を作る（隠されるのが一番危ない）
派手なツールは要りません。鍵は「個人の注意力」ではなく「環境と運用」に責任を移すことです。
まず、隔離環境を一手間で立てられる状態を作る
偽求人型攻撃への一番効く対策は、研修で警戒心を高めることではなく、素性の分からないコードを母艦で動かさなくて済む環境を用意することです。使い捨ての隔離環境をすぐ立てられ、本番鍵が端末に残らない——その状態が常にあれば、油断が事故に変わりません。受託チームの開発環境を、こうした「事故が致命傷にならない」設計に整えるお手伝いをしています。
