コードのセキュリティレビューと依存脆弱性対応

npm audit対応では、まずdirect dependencyを修正版へ上げ、transitive脆弱性はnpm overridesで脆弱範囲ごとに固定する。override後はnpm lsでinvalidな依存解決が出ていないか確認する。defaultのnpm auditにdev dependency由来の低severityが残る場合でも、npm audit --omit=devで本番依存が0件かを確認すると、リリースリスクと開発ツール由来の上流待ちリスクを分離して説明できる。

npm auditやdeprecated warning対応では、まずpackage.jsonのdirect dependencyを現在の安定系列・peer dependencyに合う組み合わせへ更新する。overridesで下位依存を強制すると警告は減るが、親パッケージの想定外のmajorへ差し替えると実行時リスクが残る。直依存の最新版でも残る脆弱性は、npm lsで経路を示し、同一majorの安全なoverrideで済むものと、上流修正待ちまたはライブラリ置換が必要なものに分ける。

APIキーやトークンをクエリパラメータ(?api_key=...)で受け付けると、URL経由でアクセスログ・リバースプロキシ・ブラウザ履歴・Refererヘッダに残り漏洩する(CWE-598)。特にWebフレームワークのアクセスログはパス+クエリ文字列ごと記録するものが多い(例: ginのデフォルトロガーはRequestURIを出力)。

対策: 認証情報は専用ヘッダ(例 X-API-Key)やAuthorizationヘッダのみで受け付け、クエリパラメータのフォールバックは設けない。同様にDB接続文字列など資格情報を含む値を平文でログ出力しない(CWE-532。ホスト名のみマスキングして出す等)。

Goプロジェクトの依存脆弱性チェックでは govulncheck ./... を使う。govulncheckは静的解析で「実コードから呼び出し到達があるか」を判定し、報告を3層に分類する: (1) Your code is affected = 実コードから到達=最優先で対応、(2) importしているが未到達、(3) requireのみで未import。同じCVEでも到達層によって実リスクが大きく異なるため、まず到達ありのものから対応する。多くは依存バージョンの更新(go get pkg@fixedversion → go mod tidy)だけで解消でき、修正後は再度 govulncheck を流して『No vulnerabilities found.』を確認し、go build と go mod verify で回帰がないことを検証する。ローカル未インストールでも go run golang.org/x/vuln/cmd/govulncheck@latest ./... で実行可能。

コードベースのシークレット混入を指摘する際は、ファイルが実際にgit管理下にあるかを git ls-files / git log --all -- <file> と .gitignore で必ず確認してから深刻度を決める。.envrc等に実キーが平文で書かれていても、.gitignore登録済みでコミット履歴にも無ければ『ソースコードへの秘密混入(CWE-798)』には該当せず、深刻度は過大評価になる。セキュリティ自動スキャンやサブエージェントの報告は深刻度を過大に出しがちなので、レポート前に到達経路・スコープ・追跡状況といった前提を一次情報で裏取りし、誤検知を補正する。

認証トークンやAPIキーの比較では == ではなく subtle.ConstantTimeCompare / hmac.Equal を使うのが原則(タイミング攻撃対策)。ただし比較対象が秘密鍵付きHMACでハッシュ化された値同士の場合、攻撃者は鍵を知らずハッシュを事前計算できないため、タイミングリークがあっても元の値の逆算には繋がらず実用上の悪用は困難。ベストプラクティスとして定数時間比較に統一しつつ、深刻度は『生の秘密値の直接比較』(高)と『HMAC済み値同士の比較』(低)を区別して評価する。