コース目次 / 第4章
まとめ — 依存関係というサプライチェーン
npm audit・lockfile・typosquattingを畳みます。依存関係のリスクが防御側の日常的な習慣で管理できることを確認し、T5の他コースとのつながりを示します。
依存関係の脆弱性を防御側から読む、3つの道具を見ました。攻撃はせず、すべて自分のプロジェクトを守るための習慣でした。
SCA・早見表
| 確認すること | 道具 | 頻度 |
|---|---|---|
| 既知の脆弱性が無いか | npm audit / npm audit fix |
定期的に、できればCIで毎回 |
| 依存の中身が保証されているか | lockfileのintegrityハッシュ、npm ci |
開発はnpm install、CI/デプロイはnpm ci |
| そのパッケージ名は、本物か | 公式ページで名前・DL数・リポジトリを確認 | 新しい依存を足すたび |
3つとも、「特別なスキルより、確認する習慣」が効く領域でした。sec-tooling で学んだ「公式導線・真正性の確認」を、いま npm パッケージという具体的な対象に当てはめ直したとも言えます。
T5(診断実務・キャリア)との、つながり
このコースの視点は、sec-audit(ソースコード診断)にも活きます。コードを読む前に、「このプロジェクトは、何に依存しているか」を package.json と npm audit で確認する——これは、実務のコード診断でもごく最初のステップです。自分のコードだけでなく、依存の健全性まで含めて見る目が、診断の質を上げます。
このコースは攻撃を行いませんでしたが、それでも 法と倫理 の精神——自分の管理下にあるものだけを対象にする——は変わりません。npm audit や npm ci を向けるのは、常に自分自身のプロジェクトです。
お疲れさまでした。あなたはもう、依存関係というサプライチェーンを、日常の習慣として守れます。
こうなっていればOK
この章で卒業です。
この章はまだ完了していません。
保存できませんでした(プライベートブラウズ中かもしれません)。この端末に進捗は残りませんが、先へは進めます。