mcpField
A
action-audit

action-audit

github.com/bitwardenセキュリティ16263 回インストール今日更新
リポジトリ

action-audit について

GitHub Actions の参照を組織内で読み取り専用監査するスキルです。指定 Action の調査と未固定参照の一括確認に対応し、Bitwarden のワークフロー規則に沿って結果と修正案を示します。

主な機能

  1. 01インシデント・組織監査モード
  2. 02GitHub ワークフローファイルの検索
  3. 03Action 参照と固定状態の分類
  4. 04Bitwarden 固定規則の適用
  5. 05結果と修正案の報告

活用シーン

  1. 01問題のある Action の参照箇所を確認
  2. 02組織内の不適合な Action 固定を検索
  3. 03修正前に Action 参照を確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/bitwarden/ai-plugins --skill action-audit

インストール後、Claude Code で/action-auditを入力して読み込まれたか確認します。

詳細

ルール

  • このスキルは読み取り専用です。 ファイルの変更、作成、削除は行わないでください。
  • 変更を伴う API 呼び出しは禁止です。 gh api の GET リクエストは自由に使用できます。-X POST、-X PUT、-X PATCH、-X DELETE は使用しないでください。
  • 不確実な点は明示してください。 調査結果が曖昧な場合は、推測せずにレポートにその旨を記載してください。

ピン留めの準拠ルール

アクション参照を分類する前に、${CLAUDE_PLUGIN_ROOT}/skills/bitwarden-workflow-linter-rules/SKILL.md を読み、以下のすべての手順の準拠基準として step_pinned ルールを適用してください。準拠しているかどうかの唯一の基準はこのスキルです。

モード

  • incident（デフォルト）：特定のアクションを対象に検索します。アクションが侵害された場合や非推奨になった場合に使用します。
  • audit：組織全体のすべてのワークフローファイルを調査し、準拠していないアクション参照をすべて確認します。

手順 1：コンテキストの解析

ユーザーのリクエストからモードを判断します。

  • 特定のアクション（例：tj-actions/changed-files）が指定されている場合は、incident モードを使用します。
  • ピン留めされていないアクションを全般的に調査するよう求められた場合は、audit モードを使用します。
  • 置換するアクションが言及されている場合は、修正手順のために記録します（これは別途 action-remediate スキルで処理します）。

手順 2：組織全体を検索

Incident モード — 特定のアクションを検索します。

gh search code "uses: <action-name>" --owner <org> --path .github/workflows/ --limit 100

間接参照を見つけるため、uses: プレフィックスを付けずに検索することもできます。

gh search code "<action-name>" --owner <org> --path .github/workflows/ --limit 100

Audit モード — すべてのワークフローファイルを見つけて、uses: 参照を抽出します。

gh search code "uses:" --owner <org> --path .github/workflows/ --limit 100

次に、${CLAUDE_PLUGIN_ROOT}/skills/bitwarden-workflow-linter-rules/SKILL.md の step_pinned 準拠フィルターを各参照に適用してください。

注： GitHub のコード検索インデックスは、直近のプッシュから反映まで数分から数時間かかることがあります。検索結果に最新のコミットが反映されていない可能性があります。この注意事項を出力に記載してください。

手順 3：結果の解析と表示

各 uses: 参照（ローカルの ./ パスを除く）について、次の項目を特定します。

  1. リポジトリとファイルパス
  2. 現在の uses: の値（行全体）
  3. アクションの種類：
    • internal — bitwarden/ で始まる
    • third-party — その他すべて（ローカルを除く）
  4. ピン留めの状態：
    • hash — 40 文字の完全な SHA にピン留めされている
    • tag — バージョンタグにピン留めされている（例：@v3、@v1.2.3）
    • branch — 名前付きブランチを参照している（例：@main、@master）
    • none — 参照がない
  5. 準拠状況： ${CLAUDE_PLUGIN_ROOT}/skills/bitwarden-workflow-linter-rules/SKILL.md の step_pinned ルールを適用します。準拠している場合は ✅、それ以外は ❌ を表示します。

次の表を表示します。

リポジトリファイル現在の参照種類ピン留めの状態準拠
..................

incident モードではすべての行を含めます。audit モードでは、準拠している行（✅）を除外します。

準拠していない調査結果がない場合は、その旨をユーザーに伝えて終了します。

Step 4: 修正対象を解決する

アクションの種類とモードに応じて、適切な修正方法を適用します。準拠していない参照をすべて同じように扱わないでください。

インシデントモード — 置き換えアクションが指定されている場合：

ステップ 1 でユーザーが置き換えアクションに言及している場合、侵害されたアクションの SHA は解決しないでください。代わりに、置き換えアクションの SHA を解決します。

gh api repos/<owner>/<repo>/commits/<ref> --jq '.sha'

解決した置き換え先の SHA と検証リンク（https://github.com/<owner>/<repo>/commit/<sha>）をユーザーに提示します。確定する前に確認を求めてください。

内部アクション（bitwarden/）：

  • 想定される修正は、ref を @main に変更することです。SHA の解決は不要です。
  • アクションが現在 SHA を指定している場合、自動的に非準拠とみなさないでください。SHA ピン留めは @main より制約が厳しく、意図的な場合があります（例：セキュリティインシデント中に固定している、または再現性のためにピン留めしている）。修正リストに含める前に、そのままユーザーに伝え、@main に変更するかどうかを確認してください。

サードパーティ製アクション：

  • 準拠していないアクションごとに、現在の SHA を解決します。
gh api repos/<owner>/<repo>/commits/<ref> --jq '.sha'

ここで、<owner>/<repo> はアクションのリポジトリで、<ref> は対象のタグまたは main です。

ユーザーに以下を提示します。

  • 解決した SHA
  • 検証リンク：https://github.com/<owner>/<repo>/commit/<sha>

「この SHA は正しいようですか？確認するには yes と入力するか、別の SHA を指定してください。」と尋ねます。

レポートを確定する前に、確認を待ってください。

監査モードでは、サードパーティ製アクションを重複なくまとめ、出現箇所ごとではなく各アクションを一度ずつ解決します。

Step 5: サマリーレポート

最終的なサマリーを出力します。

リポジトリファイル現在の参照種類準拠修正
..................

修正列には以下を記載します。

  • 内部アクションの場合：change ref to @main
  • サードパーティ製アクションの場合：解決した 40 文字の SHA と追加するインラインコメント（例：@abc123...def456 # v4.1.1）

今回の調査結果に基づいて修正を適用するには、action-remediate スキルを使用できることをユーザーに伝えてください。

コメント

Markdown 対応