security について
セキュリティエンジニアやコーディングエージェント向けの、リポジトリ全体を対象とする監査スキルです。依存関係、シークレット、予防フック、コードの脆弱性を調べ、既定では変更せずに報告します。
主な機能
- 01複数エコシステムの依存関係監査
- 02作業ツリーと Git 履歴のシークレットスキャン
- 03コミット前スキャンの確認
- 04OWASP、アクセス制御、データ保護の点検
- 05パスと影響度別の問題報告
活用シーン
- 01リポジトリのセキュリティ状況の評価
- 02コミット済みシークレットや脆弱なパッケージの検出
- 03コミット前スキャン設定の確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ tartinerlabs/ skills --skill securityインストール後、Claude Code で/securityを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
rules/auth-access-control.mddata-protection.mdhardcoded-secrets.mdinsecure-dependencies.mdowasp-top-10.md詳細
リポジトリのセキュリティ対策状況を監査するセキュリティエンジニアです。
デフォルトでは監査して報告してください。gitleaks git --redact や npm audit のような読み取り専用スキャンは監査に含まれます。フックの設定やコードの編集は、ユーザーから修正、強化、またはセットアップを依頼された場合に限って行います。依頼が曖昧な場合は、まず報告し、修正を適用するか尋ねてください。
対象範囲
このスキルが監査するのはリポジトリであり、目の前の変更ではありません。個別の差分レビューでは構造上確認できない、次の4点を中心に監査します。
- 脆弱な依存関係。差分ではなくロックファイルに記録されています
- Git の履歴にすでにコミットされたシークレット
- コード上の問題ではなく予防策の欠如である、pre-commit スキャナーの未設定
- 最近誰も変更していないコードに潜む脆弱性
差分ごとのレビューは、異なるツールを使う別の作業です。Claude Code では、security-guidance プラグインが編集、コミット、プッシュのたびに各差分を自動でレビューしており、以下のルールよりも詳細に確認します。そのため、「この変更は安全か」という質問には、そのプラグインを優先してください。このスキルはリポジトリ全体の監査に使用します。
同様のレビュアーが存在しない環境(Codex、Cursor、Antigravity、skills.sh、CI、またはプラグインなしの Claude Code)では、rules/ が監査の全手順であり、補足ではありません。ステップ4を最後まで実行してください。
ルールの概要
| ルール | 影響度 | ファイル |
|---|---|---|
| 安全でない依存関係 | HIGH | rules/insecure-dependencies.md |
| ハードコードされたシークレット | HIGH | rules/hardcoded-secrets.md |
| OWASP Top 10 | HIGH | rules/owasp-top-10.md |
| 認証とアクセス制御 | HIGH | rules/auth-access-control.md |
| データ保護 | MEDIUM | rules/data-protection.md |
ワークフロー
ステップ1:依存関係の監査
rules/insecure-dependencies.md に従います。マニフェストからエコシステムを特定し、そのエコシステムに対応する監査ツールを実行します。Python または Go プロジェクトで npm だけを監査すると、CVE を見落としても気づけません。Critical と High の CVE を報告し、その後、メンテナンスされていないパッケージや大幅に古いパッケージを報告します。
ステップ2:シークレットのスキャン
プロジェクトのスキャナー(デフォルトでは GitLeaks。プロジェクトですでに TruffleHog を使っている場合は TruffleHog)で作業ツリーをスキャンし、正規表現では検出できない項目について rules/hardcoded-secrets.md を確認します。たとえば、.gitignore に含まれていない .env、設定ファイル内の接続文字列、コミット済みの秘密鍵などです。
作業ツリー内のシークレットは、git add を一度実行するだけで取り消せなくなります。履歴内のシークレットは、すでにクローンへのアクセス権を持つすべての人に公開されています。履歴のスキャンは読み取り専用であり、監査中に実行できるため、すべての監査で実施してください。
gitleaks git --redact --verbose
長期間運用されているリポジトリでは、数分かかることがあります。開始後ではなく開始前にその旨を伝え、ユーザーが待ちたくない場合はスキップしてください。ただし、スキップしたことを必ず報告し、未スキャンの結果がクリーンと誤解されないようにします。
ステップ3:pre-commit の強化
プロジェクトの pre-commit フックでシークレットスキャナーが実行されるかを確認し、設定されていない場合は HIGH の指摘として報告します。これは、ステップ2の問題の再発を防ぐ制御策です。依頼された場合は設定します。
- pre-commit フックが存在し、すでにスキャナーを実行しているかを確認します(例:
.husky/pre-commitにgitleaksが含まれている) - 設定されていない場合は、そのエコシステムの pre-commit の仕組みにスキャナーを組み込みます。
- JS/TS — Husky をセットアップし、
lint-stagedコマンドの前にgitleaks git --staged --redact --verboseを追加します - その他の言語 — 同じスキャナーコマンドを、そのエコシステムの pre-commit ツールに追加します(例:Python の
pre-commitフック、またはそれ以外の場合は通常の.git/hooks/pre-commit)
- JS/TS — Husky をセットアップし、
- フックで旧式の
gitleaks protectコマンド(非推奨で、検出結果を秘匿しない)が使われている場合は、gitleaks git --staged --redact --verboseに書き換えます
意図的に別のスキャナーを使っているプロジェクトには、すでに制御策があるため、その旨を報告し、GitLeaks に置き換えず、そのままにします。
ステップ 4:リポジトリ全体のコード監査
コードベース全体を rules/owasp-top-10.md、rules/auth-access-control.md、および rules/data-protection.md に照らしてスキャンします。これらのチェックは言語に依存しません。現在の作業より前から存在するコードも含め、ツリー全体を対象にします。変更されていないコードは、差分レビュー担当者が決して確認しない部分であり、このステップがある理由でもあります。
ステップ 5:報告
各検出事項を path:line の形式で報告します。問題点 → 修正方法を、カテゴリ別にまとめ、影響度の高い順に並べ、最後にカテゴリごとの検出数を記載します。