セキュリティは「レビュー」ではなく「コンパイル時」に。ESLintで実現する防御的開発の極致
多くのチームが「コードレビューでセキュリティ指摘をする」という非効率なプロセスに依存しています。しかし、人間がコードを読んでセキュリティホールを見つけるのは、計算機に任せるべきタスクを脳のメモリで処理しているのと同じです。
真のテックリードは、「脆弱性が混入した時点でCIが落ちる」環境を構築します。今回は、`eslint-plugin-security`を軸に、チームのコード品質を「物理的に」担保するための設計思想を伝授します。
—
1. なぜ「静的解析」が最強の防壁なのか
セキュリティ上の脆弱性は、多くの場合「言語の仕様上、強力すぎて扱いが難しい関数」から生まれます。`eval()`や`new Function()`、あるいは非推奨なライブラリの利用は、検知さえできれば開発効率を落とすことなく、最高レベルの防御が可能です。
導入すべき神プラグイン: `eslint-plugin-security`
このプラグインは、Node.jsのランタイムレベルでの危険なパターンを静的に抽出します。
インストール
npm install –save-dev eslint-plugin-security
設定例 (.eslintrc.js):
module.exports = {
plugins: [“security”],
extends: [
“plugin:security/recommended” // Node.js環境特有の危険なコードを網羅的に検知
],
rules: {
// 万が一、どうしてもevalが必要な例外がある場合は、個別にコメントで無効化させる運用を徹底する
“security/detect-eval-with-expression”: “error”,
“security/detect-object-injection”: “warn” // プロパティアクセス時の変数を制限する
}
};
—
2. 実務で「絶対禁止」を強制する: `no-restricted-properties` の活用
チーム開発で最も恐ろしいのは、「過去の負の遺産」がコピペされ続けることです。例えば、セキュリティ的に不完全な自作の暗号化ライブラリや、特定の脆弱なパッケージを追放したい場合、ESLintの組み込みルールである `no-restricted-imports` や `no-restricted-properties` を活用します。
ベストプラクティス設定例:
{
“rules”: {
“no-restricted-imports”: [
“error”,
{
“paths”: [{
“name”: “crypto”,
“importNames”: [“createHash”],
“message”: “脆弱なアルゴリズムの使用を避けるため、プロジェクト標準の ‘security-wrapper’ を使用してください。”
}]
}
],
“no-restricted-properties”: [
“error”,
{
“object”: “document”,
“property”: “cookie”,
“message”: “直接のCookie操作は禁止です。専用のCookieManagerクラスを経由してください。”
}
]
}
}
- なぜこれが必要か: ドキュメントに「使うな」と書いても人間は読みません。しかし、IDE上に赤い波線が出てビルドが通らなくなれば、開発者は必然的に「正しい書き方」を学習します。これが「教育を自動化する」という設計思想です。
—
3. 生産性を最大化する「隠れた」テクニック
VS Codeの「自動修復」を極める
ESLintの設定をどれだけ厳しくしても、手動で直していては開発スピードが落ちます。以下の設定を `settings.json` に入れることで、保存（Command + S）と同時にセキュリティチェックと整形が完了します。
{
“editor.codeActionsOnSave”: {
“source.fixAll.eslint”: “explicit” // ESLintの自動修正機能を最強にする
},
“eslint.validate”: [“javascript”, “typescript”, “typescriptreact”]
}
チーム開発における「設定の共有化」ルール
設定ファイル（`.eslintrc`）を各メンバーの環境に依存させないために、以下のルールを徹底してください。
1. 依存関係の固定: `package.json` の `devDependencies` に全てのルールプラグインを定義する。
2. Huskyによる強制: `pre-commit` フックを使い、コミット前に必ず lint を通す。
- `npx husky add .husky/pre-commit “npx eslint src –fix”`
3. ルール変更のプロセス: ルールを緩める場合は、必ずテックリードの承認（Pull Request）を必須とする。
—
4. アーキテクトからの提言：コードは「防御」の一部である
開発スピードとは、単にコードを書く速さではありません。「後からバグを直す時間」をゼロにする速度こそが本質です。
今回紹介した設定は、一見すると開発の自由度を奪うように見えるかもしれません。しかし、実際には「どの関数を使っていいか悩む時間」や「セキュリティレビューで指摘されて修正に戻る往復時間」を劇的に削減します。
ESLintは単なる構文チェッカーではありません。あなたのチームのセキュリティポリシーを具現化する「自動化されたテックリード」です。今すぐ、最も危険な関数一つからブロックする設定を投入してみてください。その小さな一歩が、数ヶ月後の大規模なセキュリティインシデントを未然に防ぐ鍵となります。