npm installが危険な理由｜セキュリティ対策を知らないと損する話

Photo by Perry Merrity II on Unsplash

デザイナーの私が、まさかセキュリティの話で心が震える日が来るとは思いませんでした。

でもね、2026年現在、npm installって日常的に使うコマンドなんですけど、これがめちゃくちゃ危険な可能性があるって知ってました？副業でAIツール開発とか、小さなプロジェクトに関わるようになって気付いたんですが、私たちが何気なく実行しているコマンド一つで、パソコンに勝手にコードを実行させられちゃう…そういう世界で生きてるんですよ。

きょう話したいのは、TrivyやaxiosといったOSSへの「サプライチェーン攻撃」の話。FIRE目指してるからこそ、個人のセキュリティはしっかりしたいじゃないですか。一緒に考えてみませんか？

なぜnpm installは「任意コード実行」と言われるのか

まず率直に言うと、npm installって要は「インターネットから知らないコードをダウンロードして、自分のパソコンで実行する」ってことなんですよ。UI的に「ボタンポチッ」みたいに見えるけど、裏側は結構恐ろしい。

たとえば、私が使ってるデザインツールのプラグインをインストールするのと似てるんですけど、その「プラグイン」が実は悪意あるコードだったら？あるいは、有名なプラグインが乗っ取られたら？npm install実行した瞬間に、攻撃者が私のマシンでやりたい放題できちゃう。データ盗まれる、マイナーになる、バックドア仕込まれる…いろいろ起こる可能性があるんです。

2026年、これはもう「起こるかもしれない」じゃなくて「実際に起こってる」段階。Axiosっていう有名なHTTPクライアントライブラリまで狙われたニュースを見たときは、割と真面目にゾッとしました。

実際に起こった攻撃事例｜Trivyとaxiosの話

セキュリティスキャンツールの「Trivy」と、JavaScriptの定番ライブラリ「axios」。どちらも普通のプロジェクトで使われてる有名どころですよね。

こういった「誰もが使ってるOSS」が狙われるのには理由があって、影響範囲がめちゃくちゃ大きいからなんです。一つのパッケージを乗っ取ったら、数百万のプロジェクトが被害を受ける可能性がある。攻撃者にとって「効率が良い」んですよ。

Trivyやaxiosの場合、メンテナーのアカウントが乗っ取られたり、依存パッケージの脆弱性を悪用されたり、いろいろなパターンがあります。で、怖いのは「パッケージ自体は正常に動く」って点。セキュリティツールで引っかからないように慎重に設計されてる。気付かないうちに、私たちのコードが感染してるわけです。

正直なところ、これって「パッケージ管理の仕組み自体の問題」でもあるんですよ。デザイナー的には「ユーザーに意思確認させろよ」って思うけど、npm側も防ぎきれていないのが現状です。

開発環境をどう守るか｜2026年の新しい向き合い方

じゃあ私たちはどうすりゃいいのか。完全に安全な方法はないけど、被害を減らすことはできます。

まず第一は「意識」。毎回のnpm installを「未知のコードを実行してる」くらいの気持ちで扱う。チェックリストを作るとか、パッケージのバージョンを固定するとか、簡単なことから始める。

次に「スキャンツール」の活用。Trivyみたいなセキュリティスキャンツール自体は良いものなんです。自分のプロジェクトに組み込んで、定期的に脆弱性をチェックする。CI/CDパイプラインに入れておくのはマジで大事。

あとは「最小権限の原則」。開発環境と本番環境を分ける、重要な操作には追加認証を必須にする、みたいな基本的だけど効果的な対策ですね。副業とはいえ、自分のパソコンにはそれなりの資産がある。守り方を学んで損はないです。

デザイナーなのに、なぜセキュリティの話をしてるのか

これはね、FIRE目指してる身としては結構重要なんですよ。個人案件が増えると、自分でセキュリティも責任を持たなきゃいけない。クライアントのデータを盗まれたら、信用ガタ落ちだし、場合によっては賠償請求される。

AI副業でしろ、通常の開発案件でしろ、「セキュリティは誰かが見てくれるもの」って態度は2026年あたりから通用しない時代になってきてる気がするんです。デザイナーだからセキュリティ知らなくていい…はもう無理。

UI/UXの改善ばっかり考えてる時代は終わった。セキュアな設計、信頼できるツール選び、そういう視点も含めてデザイナーは考えなきゃいけないんですよ。

いま私たちができる対策｜実践的なチェックリスト

最後に、実際に私がやってることをシェアします。

まず「使うパッケージの厳選」。流行ってるからって片っ端から入れない。本当に必要か、代替案がないか、ちゃんと考える。依存を減らすだけでもリスクが下がります。

次に「package-lock.jsonの管理」。同じバージョンで統一することで、予期しないアップデートから守る。チームで開発するなら、これは絶対。

三番目は「定期的なアップデートと監査」。つまり放置しない。npm auditコマンドで脆弱性チェック、定期的にやる。

四番目は「最小権限で動かす」。開発マシンも本番サーバーも、必要最小限の権限で実行するクセをつける。

これらは全部「めっちゃ高度な対策」じゃなくて、基本的なことばかり。でもやってるのとやってないのでは雲泥の差ですよ。

結局のところ

正直なところ、npm installの話は「技術者向けの難しい話」じゃなくて「自分たちの安全に関わる話」なんです。セキュリティって、やってて気持ちいいものじゃないし、成果も見えにくい。でも…やっぱり大事。

FIRE目指してるからこそ、信用と資産は何より大事。一個のnpm installで吹き飛ぶようなリスクは、今から潰しておきたいなって私は思うんですよ。

今週の学び：セキュリティって「後付け」じゃなくて「最初から考える」もの。デザインと同じだ。

よくある質問

Q: npm auditだけで十分ですか？

A: 正直に言うと、npm auditだけでは不十分です。既知の脆弱性は検知できますが、新しい攻撃やサプライチェーン攻撃は見落とします。複数のスキャンツール（Trivy、Snyk、Dependabotなど）を組み合わせ、CI/CDパイプラインに組み込むのがベスト。

Q: 小規模な個人プロジェクトでもセキュリティ対策は必要ですか？

A: 絶対に必要です。むしろ個人こそ狙われやすい。クライアント案件なら尚更。被害を受けてからじゃ遅いので、今から習慣化させておいて損はないです。

Q: 信頼できるパッケージかどうか、どうやって判断すればいいですか？

A: GitHub上のスターの数、ダウンロード数、メンテナンスの活発さ、バグ報告への対応速度などを確認します。また、package.jsonで依存パッケージを見て「なぜこれが必要か」説明できるかも重要。

Q: package-lock.jsonをGitに含めるべきですか？

A: ライブラリ開発なら含めない、アプリケーション開発なら含める、が基本。含めることで、全員が同じバージョンで開発できるので、予期しないバグが減ります。

Q: セキュリティ対策に時間がかかるのでは？

A: 最初は確かに時間かかります。でも習慣化すると、数分の作業。むしろセキュリティ事故が起きた時の対応（信用回復、データ復旧）の方がずっと時間とお金がかかります。