go-dependency-audit

Go 依存関係の監査

追加するすべての依存関係は、自分で管理していないコードであり、その責任は自分にあります。 徹底的に監査してください。

1. 脆弱性スキャン

govulncheck（Go 公式ツール）：

# Install
go install golang.org/x/vuln/cmd/govulncheck@latest

# Scan project
govulncheck ./...

# Scan binary
govulncheck -mode=binary ./cmd/api-server

govulncheck は Go 脆弱性データベースを参照し、実際にコードパスに影響する脆弱性のみを報告します。呼び出していない推移的依存関係は報告しません。

これを CI で実行してください。例外はありません。

追加のスキャン：

# Nancy (Sonatype OSS Index)
go list -json -deps ./... | nancy sleuth

# Trivy (container + deps)
trivy fs --scanners vuln .

2. go.mod の健全性

未使用の依存関係を確認する：

go mod tidy
git diff go.mod go.sum  # any changes = deps were stale

すべてのコミットの前に、必ず go mod tidy を実行してください。CI に追加します：

go mod tidy
git diff --exit-code go.mod go.sum

コミットするコードに replace ディレクティブを含めない：

// ❌ Bad — committed replace directive
replace github.com/foo/bar => ../local-bar

// ✅ Acceptable — in monorepos with workspace
// go.work handles this instead

例外：バグ修正のための一時的な replace は、コメントと関連する Issue を記載する場合に限ります：

// TODO(#1234): remove after upstream merges fix
replace github.com/foo/bar => github.com/myorg/bar v0.0.0-fix

チェックサムを検証する：

go mod verify

これにより、ダウンロードしたモジュールが想定されるチェックサムと一致することを確認できます。 失敗した場合は、サプライチェーンの改ざんを示しています。

3. 依存関係の評価基準

依存関係を追加する前に、以下を評価してください：

基準	確認項目
メンテナンス状況	最終コミットは 6 か月以内ですか？Issue への対応は活発ですか？
人気度	Star や Fork の数だけでは判断できません。本番プロジェクトでの利用状況が重要です。
ライセンス	プロジェクトと互換性がありますか？MIT／Apache／BSD が望ましいです。
サイズ	1 つの関数のために推移的依存関係を 50 個も追加しませんか？
代替手段	標準ライブラリを使って 50 行未満で実現できますか？
API の安定性	v1 以降ですか？セマンティックバージョニングに従っていますか？破壊的変更が頻繁にありますか？
テストカバレッジ	プロジェクトには有意義なテストがありますか？

標準ライブラリについて：

Go の標準ライブラリは優れています。依存関係を追加する前に、次のように考えてください： 「net/http、encoding/json、database/sql、text/template、crypto/*、os/exec などで解決できますか？」

答えが「はい」で、コードが 100 行未満なら、自分で書いてください。

4. モジュールバージョンの監査

バージョン付きの依存関係をすべて一覧表示する：

go list -m all

利用可能な更新を確認する：

go list -m -u all  # shows available updates

アップグレード戦略：

# Update specific module
go get github.com/foo/bar@latest

# Update all direct deps (minor/patch only)
go get -u ./...

# Update all deps including major versions (dangerous)
go get -u -t ./...

更新後は、必ずテストスイート全体を実行してください：

go get github.com/foo/[email protected]
go mod tidy
go test -race ./...

5. 推移的依存関係の分析

# Why is this module in my dependency tree?
go mod why github.com/some/transitive-dep

# Full dependency graph
go mod graph

# Visual dependency graph (with modgraphviz)
go mod graph | modgraphviz | dot -Tpng -o deps.png

次の点に注意してください：

• 🔴 既知の CVE がある推移的依存関係
• 🔴 放置された推移的依存関係（2 年以上コミットがない）
• 🟡 ダイヤモンド依存関係の競合（同じモジュールの異なるバージョン）
• 🟡 巨大な推移的依存関係ツリー（ロギングライブラリが gRPC を引き込むなど）

6. Go バージョンの管理

// go.mod
module github.com/myorg/myproject

go 1.22  // minimum Go version required

ルール：

• go ディレクティブには、使用する機能をサポートする最小バージョンを設定します。
• toolchain ディレクティブ（Go 1.21 以降）は、ツールチェーンのバージョンを正確に固定します。
• CI では複数の Go バージョンでテストします（最低限、現行とその前のバージョン）。

7. 推奨パッケージと避けるべきパッケージ

メンテナンスが行き届き、本番環境での実績があるパッケージ：

分野	パッケージ
ロギング	go.uber.org/zap、log/slog（標準ライブラリ 1.21 以降）
HTTP ルーター	github.com/go-chi/chi、net/http（1.22 以降のルーティング）
設定	github.com/caarlos0/env、github.com/spf13/viper
テスト	github.com/stretchr/testify、標準ライブラリの testing
データベース	github.com/jackc/pgx、github.com/jmoiron/sqlx
バリデーション	github.com/go-playground/validator
UUID	github.com/google/uuid
エラー	go.uber.org/multierr、標準ライブラリの errors（1.20 以降）

避けるべきパターン：

• ❌ main() を乗っ取るフレームワーク（Go は Java Spring ではありません）
• ❌ SQL を隠蔽する ORM（sqlx または生の database/sql を優先）
• ❌ 理解していないコードジェネレーター
• ❌ 3 年以上 v0 のままの v0.x パッケージ

監査結果の形式

## Dependency Audit Report

**Module:** github.com/myorg/myproject
**Go version:** 1.22
**Direct deps:** N | **Indirect deps:** M

### 🔴 Vulnerabilities
- CVE-XXXX-YYYY in github.com/foo/[email protected] — upgrade to v1.2.5

### 🟡 Outdated Dependencies
- github.com/foo/bar v1.2.3 → v1.5.0 available (minor)

### 🟢 Observations
- go.mod is clean, no replace directives
- All deps actively maintained