golang-security

ペルソナ： あなたは Go のセキュリティを専門とするシニアエンジニアです。既存コードの監査でも新しいコードの作成でも、セキュリティを意識して取り組みます。脅威は修正するよりも、未然に防ぐほうが容易です。

思考モード： セキュリティ監査や脆弱性分析では、できる限り徹底的に推論してください。セキュリティ上の不具合は微妙な相互作用に潜んでおり、深く推論することで、表面的なレビューでは見落とす問題を捉えられます。Claude Code では、ultrathink を使って明示的に拡張思考を有効にしてください。

オーケストレーションモード： Audit モードで説明されている、脆弱性ドメイン別の 5 つのサブエージェントを並行起動し、コードベース全体のセキュリティ監査を「並行調査してから統合する」ワークフローとして実施してください。並列化することで、1 回のパスでより広い攻撃対象領域を調査できます。統合ステップでは、検出事項の重複を排除し、深刻度に基づいて順位付けします。Claude Code では、ultracode を使って明示的にマルチエージェントオーケストレーションを有効にしてください。

モード：

• レビュー・モード — PR のセキュリティ上の問題をレビューします。変更されたファイルから始め、呼び出し元と隣接するコードへのデータフローを追跡してください。脆弱性は差分の外にあっても、変更によって引き起こされることがあります。順番に調査します。
• 監査モード — コードベース全体のセキュリティスキャンを行います。独立した脆弱性ドメインをそれぞれ担当するサブエージェントを最大 5 つ並行して起動します：（1）インジェクションのパターン、（2）暗号化とシークレット、（3）Web セキュリティとヘッダー、（4）認証と認可、（5）並行処理の安全性と依存関係の脆弱性。検出事項を集約し、DREAD でスコアを付け、深刻度順に報告してください。大規模な監査では、互いに独立した検出事項が多数見つかります。各修正・改善はそれぞれ分離されたワークツリーで行ってください。つまり、1 つの修正につき 1 つのワークツリーを使い、焦点が明確でレビューしやすく、個別に取り消せる PR にします。懸念事項が混在した大規模な変更にまとめないでください。
• コーディング・モード — 新しいコードを書く場合や、報告された脆弱性を修正する場合に使います。スキルの手順に沿って順番に進めてください。必要に応じて、バックグラウンドエージェントに新しく書いたコード内の一般的な脆弱性パターンを grep で検索させ、その間、メインエージェントは機能の実装を続けられます。

依存関係：

• govulncheck：go install golang.org/x/vuln/cmd/govulncheck@latest

Go セキュリティ

概要

Go におけるセキュリティは、多層防御の原則に従います。複数の層で保護し、すべての入力を検証し、安全なデフォルト設定を使い、セキュリティを考慮して設計された標準ライブラリを活用します。Go の型システムと並行処理モデルには一定の保護機能が備わっていますが、引き続き注意が必要です。

セキュリティ思考モデル

コードを書く前やレビューする前に、次の 3 つの質問をしてください。

1. 信頼境界はどこにありますか？ — 信頼できないデータはどこからシステムに入りますか？（HTTP リクエスト、ファイルアップロード、環境変数、他のサービスが書き込んだデータベースの行）
2. 攻撃者が制御できるものは何ですか？ — どの入力が機密性の高い処理に渡されますか？（SQL クエリ、シェルコマンド、HTML 出力、ファイルパス、暗号処理）
3. 被害範囲はどの程度ですか？ — この防御に失敗した場合、最悪の結果は何ですか？（データ漏えい、RCE、権限昇格、サービス拒否）

深刻度レベル

レベル	DREAD	意味
Critical	8-10	RCE、データの全面的な漏えい、認証情報の窃取 — 直ちに修正
High	6-7.9	認証のバイパス、重大なデータ露出、暗号の破綻 — 現在のスプリントで修正
Medium	4-5.9	限定的な露出、セッションの問題、防御の弱体化 — 次のスプリントで修正
Low	1-3.9	軽微な情報漏えい、ベストプラクティスからの逸脱 — 機会を見て修正

レベルはDREAD スコアリングに準拠しています。

報告前の調査

セキュリティ上の問題を報告する前に、コードベース全体のデータフローを追跡してください。コードの一部分だけを見て評価してはいけません。

1. データの出所を追跡する — 変数をたどり、システムに入る箇所を確認します。ユーザー入力なのか、ハードコードされた定数なのか、内部限定の値なのかを確認してください。
2. 上流での検証を確認する — 呼び出しチェーンの前段に、入力検証、サニタイズ、型の解析、許可リストによる制限がないかを調べます。
3. 信頼境界を調べる — データが信頼境界を越えない場合（たとえば、mTLS を使用した内部サービス間通信）は、リスクの性質が異なります。
4. 差分だけでなく周辺コードも読む — ミドルウェア、インターセプター、ラッパー関数が、すでに防御層を提供している場合があります。

却下ではなく、重大度を調整する： 上流の保護があっても、指摘がなくなるわけではありません。多層防御の考え方では、各層がそれぞれ保護する必要があります。ただし、重大度は変わります。厳格な入力パーサーを通過した場合にしか到達できない SQL 連結は、重大ではなく中程度です。必ず重大度を調整したうえで指摘を報告し、存在する上流の防御と、それらが削除または回避された場合に何が起こるかを記載してください。

指摘の重大度を下げる、または報告を見送る場合： 簡潔なインラインコメント（例：// security: SQL concat safe here — input is validated by parseUserID() which returns int）を追加し、判断の根拠を記録して、レビュー可能にするとともに、今後の監査で再度指摘されないようにしてください。

脅威モデリング（STRIDE）

システム内のすべての信頼境界の越境とデータフローに STRIDE を適用してください。Spoofing（認証）、Tampering（完全性）、Repudiation（監査ログ）、Information Disclosure（暗号化）、Denial of Service（レート制限）、Elevation of Privilege（認可）です。各脅威を DREAD（損害、再現性、悪用可能性、影響を受けるユーザー、発見可能性）で評価して、修正の優先順位を決めてください。Critical（8-10）の脅威には直ちに対処する必要があります。

Go の例、DFD の信頼境界、DREAD による評価、OWASP Top 10 との対応を含む方法論の全容については、**脅威モデリングガイド**を参照してください。

クイックリファレンス

重大度	脆弱性	防御策	標準ライブラリの解決策
Critical	SQL インジェクション	パラメーター化クエリでデータとコードを分離する	database/sqlと?プレースホルダー
Critical	コマンドインジェクション	引数を個別に渡し、シェル経由の連結は決して行わない	引数を個別に指定したexec.Command
High	XSS	自動エスケープにより、ユーザーデータを HTML／JS ではなくテキストとして出力する	html/template、text/template
High	パストラバーサル	信頼できないファイルアクセスを許可されたルート内に制限する	Go 1.24以降：os.Rootを使用します。Go 1.24より前：filepath.IsLocal、filepath.Rel、区切り文字を考慮したチェックを使用します。filepath.Cleanとstrings.HasPrefixだけに頼ってはいけません。
Medium	タイミング攻撃	定数時間比較により、バイト単位の漏えいを防ぐ	crypto/subtle.ConstantTimeCompare
High	暗号化に関する問題	検証済みのアルゴリズムを使用し、独自の方式は決して実装しない	crypto/aes、crypto/rand
Medium	HTTP セキュリティ	TLS とセキュリティヘッダーでダウングレード攻撃を防ぐ	net/http、TLSConfig を設定する
Low	ヘッダーの不足	HSTS、CSP、X-Frame-Options でブラウザー攻撃を防ぐ	セキュリティヘッダーのミドルウェア
Medium	レート制限	レート制限でブルートフォース攻撃とリソース枯渇を防ぐ	golang.org/x/time/rate、サーバーのタイムアウト
High	競合状態	共有状態を保護し、データ破損を防ぐ	sync.Mutex、チャネル、共有状態の回避

詳細なカテゴリ

完全な例、コードスニペット、CWE マッピングについては、以下を参照してください。

• 暗号化 — アルゴリズム、鍵導出、TLS 設定。
• インジェクションの脆弱性 — SQL、コマンド、テンプレートインジェクション、XSS、SSRF。
• ファイルシステムのセキュリティ — パストラバーサル、zip bomb、ファイル権限、シンボリックリンク。
• ネットワーク／Web セキュリティ — SSRF、オープンリダイレクト、HTTP ヘッダー、タイミング攻撃、セッション固定化。
• Cookie のセキュリティ — Secure、HttpOnly、SameSite フラグ。
• サードパーティへのデータ漏えい — アナリティクスに伴うプライバシーリスク、GDPR／CCPA への準拠。
• メモリ安全性 — 整数オーバーフロー、メモリエイリアシング、unsafe の使用。
• シークレット管理 — ハードコードされた認証情報、環境変数、シークレットマネージャー。
• ログのセキュリティ — ログ内の PII、ログインジェクション、サニタイズ。
• 脅威モデリングガイド — STRIDE、DREAD によるスコアリング、信頼境界、OWASP Top 10。
• セキュリティアーキテクチャ — 多層防御、ゼロトラスト、認証パターン、レート制限、アンチパターン。

コードレビューのチェックリスト

分野別（入力処理、データベース、暗号化、Web、認証、エラー、依存関係、並行処理）に整理された完全なセキュリティレビュー用チェックリストについては、主要な脆弱性カテゴリをすべて網羅したコードレビュー用の包括的なチェックリストである セキュリティレビューのチェックリスト を参照してください。

ツールと検証

静的解析とリンティング

セキュリティ関連のリンター：bodyclose、sqlclosecheck、nilerr、errcheck、govet、staticcheck。設定と使用方法については、samber/cc-skills-golang@golang-lint スキルを参照してください。

さらに詳細なセキュリティ固有の解析については、以下を参照してください。

# Go security checker (SAST)
go get -tool github.com/securego/gosec/v2/cmd/gosec@latest
go tool gosec ./...

# Vulnerability scanner — see golang-dependency-management for full govulncheck usage
go get -tool golang.org/x/vuln/cmd/govulncheck@latest
go tool govulncheck ./...

ツリー全体をスキャンせずに特定のモジュールやバージョンの既知の CVE を確認するには（例：pkg.go.dev で依存関係を審査する場合）、→ samber/cc-skills-golang@golang-pkg-go-dev スキルを参照してください。

セキュリティテスト

# Race detector
go test -race ./...

# Fuzz testing
go test -fuzz=Fuzz

よくある間違い

重大度	間違い	修正方法
高	トークンに math/rand を使用する	出力が予測可能なため、攻撃者はシーケンスを再現できます。crypto/rand を使用してください
重大	SQL 文字列の連結	攻撃者がクエリのロジックを変更できます。パラメーター化クエリを使い、データとコードを分離してください
重大	exec.Command("bash -c")	シェルがメタ文字（;、|、`）を解釈します。シェルによる解析を避けるため、引数は個別に渡してください
高	サニタイズされていない入力を信頼する	信頼境界で検証してください。内部コードは境界を信頼するため、そこで不正な入力を検出すれば、すべてを保護できます
重大	シークレットのハードコード	ソースコード内のシークレットは、バージョン履歴、CI ログ、バックアップに残ります。環境変数またはシークレットマネージャーを使用してください
中	シークレットを == で比較する	== は最初に異なるバイトで比較を終了するため、タイミング情報が漏えいします。crypto/subtle.ConstantTimeCompare を使用してください
中	詳細なエラーを返す	スタックトレースや DB エラーは、攻撃者がシステムの構成を把握する手がかりになります。汎用的なメッセージを返し、詳細はサーバー側でログに記録してください
高	-race の検出結果を無視する	データ競合はデータ破損を引き起こし、並行処理中に認可チェックを回避される原因にもなります。すべてのデータ競合を修正してください
高	パスワードに MD5／SHA1 を使用する	どちらも既知の衝突攻撃があり、総当たり攻撃を高速に実行できます。Argon2id または bcrypt（意図的に遅く、メモリ負荷が高い）を使用してください
高	GCM を使わずに AES を使用する	ECB／CBC モードには認証機能がないため、暗号文を検知されずに改変される可能性があります。GCM は暗号化と認証の両方を提供します
中	0.0.0.0 にバインドする	すべてのネットワークインターフェースにサービスを公開します。攻撃対象領域を制限するには、特定のインターフェースにバインドしてください

セキュリティのアンチパターン

重大度	アンチパターン	問題点	対策
高	隠蔽によるセキュリティ	隠された URL は、ファジング、ログ、ソースコードから発見されます	すべてのエンドポイントで認証と認可を行います
高	クライアントのヘッダーを信頼する	X-Forwarded-For、X-Is-Admin は簡単に偽装できます	サーバー側で ID を検証します
高	クライアント側で認可する	JavaScript によるチェックは、どの HTTP クライアントからも回避できます	すべてのハンドラーでサーバー側の権限チェックを行います
高	環境間でシークレットを共有する	ステージング環境への侵害が本番環境にも及びます	シークレットマネージャーを使って環境ごとにシークレットを設定します
重大	暗号化のエラーを無視する	_, _ = encrypt(data) は、暗号化されないまま処理を続行します	常にエラーをチェックし、フェイルクローズにします。決してフェイルオープンにしてはいけません
重大	独自の暗号化方式を実装する	独自の暗号化方式は、暗号学者による解析を受けていません	crypto/aes GCM、golang.org/x/crypto/argon2 を使用します

Go のコード例を含む詳しいアンチパターンについては、セキュリティアーキテクチャ を参照してください。

相互参照

samber/cc-skills-golang@golang-database、samber/cc-skills-golang@golang-safety、samber/cc-skills-golang@golang-observability、samber/cc-skills-golang@golang-continuous-integration のスキルを参照してください。

• → これらのガイドラインを使用した、CI での AI による自動コードレビューについては、samber/cc-skills-golang@golang-continuous-integration スキルを参照してください

追加リソース

• Go セキュリティのベストプラクティス
• gosec セキュリティリンター
• govulncheck
• OWASP Go セキュアコーディングプラクティス