mcpField
S
scan-code

scan-code

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

scan-code について

Scan Codeは、Power Pagesプロジェクトのソースファイルと依存関係のセキュリティ問題を調べるスキルです。opengrepの静的解析とtrivyのスキャンを組み合わせ、結果をまとめます。ツールがない場合は、エージェントによるコード確認も選べます。

主な機能

  1. 01opengrepによる静的解析
  2. 02trivyによる依存関係、シークレット、ライセンスのスキャン
  3. 03範囲と深度を選んでスキャン
  4. 04結果の要約とHTMLレポートの生成
  5. 05代替手段としてエージェントによるコード確認

活用シーン

  1. 01Power Pagesのソースにあるセキュリティリスクを確認
  2. 02依存関係の脆弱性、シークレット、ライセンス問題を発見
  3. 03スキャン結果からセキュリティレポートを作成

インストール

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

$npx skills add https://github.com/microsoft/power-platform-skills --skill scan-code

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
commands.md
scripts/
check-tools.js
run-opengrep.js
run-trivy.js
transform-scan-code.js

詳細

プラグインの確認:node "${PLUGIN_ROOT}/scripts/check-version.js" を実行してください。メッセージが出力された場合は、続行する前にユーザーに表示してください。

コードのスキャン

Power Pages サイトプロジェクトのソースファイルと依存関係をスキャンし、セキュリティ上の問題を検出します。opengrep(静的解析)と trivy(依存関係/シークレット/ライセンスのスキャン)を実行し、検出結果を提示します。

最初のリクエスト: $ARGUMENTS

警告: 続行する前に、ユーザーに次のように伝えてください。「このスキルは、ローカルマシンにインストールされている場合に限り、opengrep と trivy を使用します。これらのサードパーティ製オープンソースツールは、独自の規約、プライバシーポリシー、データ取り扱い方針に基づいて、ソースコードと依存関係をスキャンし、データを収集または送信する可能性があります。Microsoft はこれらを管理していません。AI によるフォールバックを選択した場合、AI サービスがソースコードを処理します。続行する前に、所属組織のポリシーと適用されるサードパーティの規約を確認してください。」

注意点

  • 両方のツールをインストールする必要があります。 check-tools.js を実行して確認してください。いずれかが見つからない場合は、エージェント主導のレビューによる代替手段を提示してください(ステップ 1.2 を参照)。
  • 検出結果がある場合、Opengrep は終了コード 1 を返します。 これは通常の動作であり、エラーではありません。スクリプトが処理します。
  • 出力が大きくなることがあります。 大規模なプロジェクトでは、両方のツールが大量の JSON を生成する場合があります。スクリプトは出力をフラットな検出結果リストに正規化します。
  • Trivy の重大度フラグが影響するのは脆弱性の検出結果のみです。 シークレットとライセンスの検出結果は、--severity フラグに関係なく常に返されます。
  • シークレットは、どこでも完全な値を表示しません。 あなたがソースを直接読む場合(エージェント主導のレビュー)も、検出結果を提示する場合も、認証情報(API キー、トークン、パスワード、接続文字列、秘密鍵、その他シークレットのようなあらゆる値。固定リストはありません)を見分けるよう注意してください。その生の値をどこにも出力してはいけません。コンテキスト、セッション、チャット、ログ、要約、レポート、その他すべての出力が対象です。一部だけの表示も禁止です。値を表示する箇所では、マスク(例:********)に置き換えてください。

ワークフロー

  1. 前提条件 — プロジェクトの場所を特定し、ツールが利用可能か確認します
  2. 範囲の選択 — 何をどの深さでスキャンするかを決めます
  3. スキャンの実行 — ツールを実行し、結果を取得します
  4. 要約 — 検出結果を提示し、使用状況を記録して、次の対応を提示します

タスクの追跡

タスクを 3 つのグループに分けて作成します。開始時に各タスクを in_progress に、完了時に completed にします。

グループ作成するタイミングタスク
1開始時前提条件を確認する
2前提条件の確認後範囲を選択する(レビュー モードではスキップ)
3範囲の決定後(またはレビュー モード)スキャンを実行する · 要約する(常に実施)

1. 前提条件

1.1 プロジェクトの場所を特定し、レビュー モードを検出する

Glob を使用して **/powerpages.config.json を検索してください。$ARGUMENTS に --review <out-dir> が含まれている場合は、出力ディレクトリを記憶してください。ステップ 2 はスキップされ(Advanced の深さですべてのチェックを実行)、ステップ 4 では JSON のみを書き込みます。

1.2 ツールの利用可否を確認する
node "${PLUGIN_ROOT}/skills/scan-code/scripts/check-tools.js"

いずれかのツールが見つからない場合は、どのツールが見つからないかをユーザーに伝えてください。その後、フォールバックとしてエージェントによるレビューを提案します。

レビュー モード(非対話型)では、エージェントによるレビューを提案しないでください。 対話形式でのオプトインが必要であり、オーケストレーターは JSON ファイルを想定しています。{ "status": "skipped", "reason": "<which tool> is not installed" } を <REVIEW_DIR>/scan-code.json に書き込み、終了してください。

🚦 ゲート(plan · scan-code:1.agent-review-fallback): スキャンツールが見つからない場合は、作業を始める前にフォールバックとしてエージェントによるレビューを提案してください。レビューでは Glob/Read/Grep を使ってソースを読み込むため、大量のトークンを消費します。したがって、ユーザーのオプトインが必要です。

トリガー: ステップ 1.2 で、check-tools.js がツールの不足を報告した場合のみ(対話モードのみ。レビュー モードでは、ツールが不足していると処理を停止するため、ここには到達しません)。 確認する理由: エージェントによるレビューを同意なく自動で開始すると、大量のトークンを消費します。ユーザーは、ツールをインストールして再実行することを希望する場合があります。 キャンセル時の状態: 何もありません。ファイルの読み込みも、スキャンの実行もありません。

説明 — ユーザーに提示するすべてのテキスト(警告、AskUserQuestion の選択肢ラベル、要約)は、これを「手動レビュー」と呼んではいけません。 エージェントが実行するレビューです。「私がコードを直接確認して、問題を指摘できます」のように、あなたが自分でコードを確認すると説明してください。

このレビューでは多数のファイルを読み込み、大量のトークンを消費することをユーザーに警告してから、git の状況を確認してください。

  • フィーチャーブランチ(main、master、またはそれに相当するブランチ以外):現在のブランチの変更のみをレビューする方法(git diff <main-branch>...HEAD)を提案します。
  • main/master ブランチ、または git リポジトリがない場合: プロジェクトのソース全体をレビューする方法を提案します。

ユーザーが承諾した場合は、Glob + Read + Grep を使い、関連ファイルに一般的なセキュリティパターン(ハードコードされたシークレット、安全でない API の使用、入力検証の欠落、公開されたエンドポイントなど)がないかレビューし、検出結果を提示してください。シークレットの値をどこにも表示してはいけません。 出力の種類を問わず(あなたのコンテキスト、セッション、チャット、ログなど)、認証情報の生の値を、たとえ一部であっても出力してはいけません。値を表示する必要がある箇所では、******** のようにマスクに置き換えてください。ツールをインストールしようとしないでください。


2. スコープを選択する

レビュー モードではスキップしてください。両方のツールを Advanced 深度で実行します。

スコープの選択

以下の質問を順番に行います。それぞれ個別の AskUserQuestion 呼び出しとして実行してください。まとめてはいけません。ユーザーの最初のリクエストですでに回答されている質問は省略し、次に進みます。

🚦 ゲート(計画 · scan-code:2.scope-choice): ツールを実行する前に、スキャン対象としてコード、パッケージ、または両方を選択します。実行するスキャナーが決まります。

トリガー: フェーズ 2 の開始時(対話モードのみ。レビュー モードでは質問せず、すべてを Advanced の深度でスキャンします)。最初のリクエストですでにスコープが指定されている場合は省略します。 確認する理由: すべてを自動スキャンすると、ユーザーが望んでいないツールが実行される可能性があります(例:パッケージについてだけ尋ねているのに、時間のかかるコードチェックが実行される)。誤ったスコープを選ぶと、ユーザーが気にしていた内容を見落とすレポートになります。 キャンセル時の状態: 何もありません。スキャナーはまだ実行されていません。

質問 1 — 何をチェックしますか?

ラベル説明
すべてコードとパッケージの両方をチェックします。(推奨)
コードのみソースファイルにセキュリティ上の問題がないかチェックします。
パッケージのみインストール済みパッケージに既知の問題がないかチェックします。

🚦 ゲート(計画 · scan-code:2.depth-choice): コードチェックの詳しさを選択します。コードチェックが含まれる場合にのみ尋ねます。

トリガー: フェーズ 2 で、スコープの選択にコードが含まれる場合(対話モードのみ)。最初のリクエストですでに深度が指定されている場合、またはコードチェックが除外されている場合は省略します。 確認する理由: 詳細オプションでは、実行に時間がかかる、より広範なルールセットを使います。これを自動的に選ぶと大規模なプロジェクトで予想外に時間がかかる一方、簡易オプションを自動的に選ぶと、ユーザーが検出を期待していた弱点を気付かれないまま見逃す可能性があります。 キャンセル時の状態: 何もありません。スキャナーはまだ実行されていません。

質問 2 — コードチェックが含まれる場合のみ:詳しさを選択してください。

ラベル説明
Advanced一般的なリスクと、より深いコード上の弱点を対象にします。(推奨)
Basic一般的なリスクのみを対象にします。

深度のマッピング(内部用。ユーザーには表示しません):Advanced = p/default,p/owasp-top-ten,p/cwe-top-25。Basic = p/default,p/owasp-top-ten。

カスタムルール

どちらのツールもカスタムルールに対応しています。ユーザーから指定されない限り、こちらから提案しないでください。

  • Opengrep:--rulesets は、カンマ区切りのレジストリパックとローカルファイルパスを受け付けます。カスタムルールセットは、深度のデフォルト設定に置き換わるのではなく、追加されます。
  • Trivy:--secretConfig はカスタムのシークレット検出パターンに、--ignoreFile は既知の検出結果の抑制に、--trivyConfig はライセンス分類などの設定に使用します。--no-licenseFull を指定すると、実行時間を短縮するためソースレベルのライセンススキャンを省略できます。

3. スキャンの実行

各ツールの 生の JSON 出力を一時ファイルに保存します。ステップ 4 の変換スクリプトで正規化します。

静的解析(opengrep)
node "${PLUGIN_ROOT}/skills/scan-code/scripts/run-opengrep.js" --projectRoot "<PROJECT_ROOT>" --rulesets "<comma-separated-rulesets>" > "<TEMP_DIR>/opengrep.json"

選択した深度(Basic または Advanced)のルールセットを渡します。ユーザー指定のカスタムルールセットがあれば追加します。大規模なプロジェクトでは run_in_background: true を指定して実行します。

依存関係/シークレット/ライセンスのスキャン(trivy)
node "${PLUGIN_ROOT}/skills/scan-code/scripts/run-trivy.js" --projectRoot "<PROJECT_ROOT>" > "<TEMP_DIR>/trivy.json"

--licenseFull はデフォルトで有効です。パッケージのメタデータと併せて、ソースコードのヘッダーや LICENSE ファイルもスキャンします。大規模なプロジェクトでは run_in_background: true を指定して実行します。

正規化
node "${PLUGIN_ROOT}/skills/scan-code/scripts/transform-scan-code.js" --opengrepFile "<TEMP_DIR>/opengrep.json" --trivyFile "<TEMP_DIR>/trivy.json" --projectRoot "<PROJECT_ROOT>"

実際に実行したツールのファイルのみを渡します。標準出力は、統一された { status, findings } 形式になります。


4. 要約

4.1 レビューモード

レビューモードでは、transform-scan-code.js の標準出力を <REVIEW_DIR>/scan-code.json に書き込みます。その後、停止します。提示内容の処理は、オーケストレーションを行うスキルが担当します。

4.2 HTML レポートを生成する

レビュー モードではスキップしてください。

レンダリングでは、統合セキュリティレビューと同じ共有テンプレートを使用します。まず、Step 3 の Normalize の標準出力を <TEMP_DIR>/scan-code.json に書き込み、その後、単一セクションのレビュー データ ペイロードを作成してレンダリングします。

node "${PLUGIN_ROOT}/scripts/build-review-data.js" \
  --reportName "Code Scan" \
  --inputDir "<TEMP_DIR>" \
  --siteName "<SITE_NAME>" \
  --goalLabel "Code & Packages scan" \
  --scopeLabel "<SCOPE_LABEL>" \
  --summary "<SUMMARY_TEXT>" \
  --output "<TEMP_DIR>/data.json"

node "${PLUGIN_ROOT}/scripts/render-review.js" \
  --data "<TEMP_DIR>/data.json" \
  --output "<PROJECT_ROOT>/docs/code-scan-<YYYY-MM-DD-HHMMSS>.html"

<TEMP_DIR> には、Step 3 の中間ファイル opengrep.json/trivy.json も scan-code.json とともに保存されます。build-review-data.js は scan-code.json のみを読み込み、その他のファイルは無視します。ファイル名には、ローカルのタイムスタンプを必ず含めてください(例:code-scan-2026-05-14-053805.html)。レンダリングが成功したら、<TEMP_DIR> を削除してください。生成した HTML をブラウザーで開きます。

4.3 概要を提示する

レビュー モードではスキップしてください。

平易な言葉で概要を説明します。検出項目の合計数、カテゴリ別の件数(コードパターン、脆弱なパッケージ、シークレット、ライセンス)、そして最初に確認すべき項目を伝えてください。

4.4 スキルの使用を記録する

参照先:${PLUGIN_ROOT}/references/skill-tracking-reference.md

--skillName "ScanCode" を使用してください。

4.5 追加の対応を提案する

検出項目がほかのスキルに該当する場合は、提案してください。

  • ヘッダー/Cookie の問題 → /manage-headers
  • WAF/ファイアウォールの問題 → /manage-firewall
  • 権限の問題 → 既存の権限を確認するには /audit-permissions、ロールベースのアクセスを設定するには /create-webroles、またはその両方を提案します
  • ログインまたは外部 ID の問題 → /setup-auth
  • コードレベルの問題(デバッグページの露出、情報漏えい) → 手動でのコード修正を提案します

有意義な追加対応がない場合は、このスキルを終了します。


制約

  • 平易な言葉 — ユーザーには、専門用語を絶対に使わないでください。opengrep、trivy、OWASP、CWE、静的解析、SAST、ルールセットなどの言葉は使わないでください。「コードにセキュリティ上の問題がないか確認する」「パッケージに既知の問題がないか確認する」「詳細なチェック」「簡易チェック」のような日常的な言葉を使ってください。ユーザーから尋ねられた場合に限り、技術的な名称を説明してください。ツールが見つからない場合の代替手段については、「手動レビュー」と呼んではいけません。エージェントが実施するものであり、自分でコードを確認すると説明してください。
  • 長時間実行される呼び出しのバックグラウンド実行 — 大規模なプロジェクトでは、両方のツールを run_in_background: true で実行してください。
  • 状況に応じたやり取り — 推奨事項には、実際のサイトのスキャン結果を必ず反映してください。一般的な助言を提示してはいけません。
  • 推奨事項によってサイトを壊さない — コードの検出項目に対する修正を提案する場合は、修正によってリグレッションが発生しないことを確認してください。
  • セキュリティを広げる提案は絶対にしない — 検出項目がセキュリティの強化(例:ハードコードされたシークレットの削除)を示唆する場合、利便性のためにそのまま残すことを提案してはいけません。
  • シークレットの値を絶対に開示しない — 生のシークレットは、値の一部であっても、正規表現や grep の一致結果であっても、出力、ログ記録、保存、再掲を絶対に行わないでください。シークレットの検出項目は、値ではなく種類、ファイル、行番号で特定してください。マスキング(例:********)は、シークレットの値を表示する必要がある場合にのみ適用します。値を表示する必要はありません。

参照資料

  • references/commands.md — スクリプトのフラグと応答形式です。スクリプト呼び出しを構成する際に読んでください。

コメント