Claude Media
Claude SecurityのSARIFと結果ファイル4種の読み方
Claude CodeTips

Claude SecurityのSARIFと結果ファイル4種の読み方

Claude Securityプラグインのスキャンが出力するRESULTS.md・jsonl・SARIF・リビジョンスタンプの役割と、履歴に残す方法、patchesの扱いをまとめます。

読了目安 約11分

Claude Securityプラグインでスキャンを終えると、リポジトリ直下に CLAUDE-SECURITY-<timestamp>/ というディレクトリができます。中身は4ファイルで、人が読むもの・スクリプトが読むもの・GitHubが読むもの・「どのコードを見た結果か」を残すものに分かれています。

この記事は、その4ファイルの使い分けと、履歴に残す手順、patches/ の扱いをまとめたものです。ここで扱うのは、Claude Codeのプラグイン版が手元に書き出す結果ファイルです。Web上の管理サービスとしてのClaude Securityは、Claude Securityの全体像にまとめています。

スキャンが出力する4ファイルの全体像

スキャンの結果は、タイムスタンプ付きの CLAUDE-SECURITY-<timestamp>/ に書き出されます。このディレクトリがスキャンで変わる唯一の場所で、ソースファイルには触れません。

ls CLAUDE-SECURITY-<timestamp>/

出てくるファイルの役割は次のとおりです。

ファイル読み手中身
CLAUDE-SECURITY-RESULTS.md読み手人中身指摘ごとのID・影響・攻撃シナリオ・深刻度・確度・推奨対応
CLAUDE-SECURITY-RESULTS.jsonl読み手スクリプト中身同じ指摘を1行1JSONオブジェクトで保持
CLAUDE-SECURITY-RESULTS.sarif読み手GitHubなどのツール中身同じ指摘をSARIF 2.1.0のログとして保持
CLAUDE-SECURITY-REVISION-<commit>.json読み手人とスクリプト中身スキャン対象のコミットと実行条件の記録

3つの結果ファイルは、同じ指摘を別の形式で持つだけです。1つにしか載らない指摘があるわけではありません。まず .md を読み、仕分けや集計をしたくなったら .jsonl、GitHubに載せるなら .sarif に進む、という順序が自然です。

patches/ フォルダは、後から「Suggest patches」を実行したときに、このディレクトリの中にできます。スキャン直後の4ファイルには含まれません。

RESULTS.mdは何を読み、どの順で判断するか

CLAUDE-SECURITY-RESULTS.md は、指摘ごとにIDを振った報告書です。IDは F1 のような形で、後で「fix finding F3」と頼むときの指定にも、patches/F3.patch というファイル名にもそのまま使われます。

1件ごとに書かれている項目は、影響、攻撃シナリオ、深刻度、確度、推奨対応です。読む順序は、深刻度の高いものから、確度と攻撃シナリオを突き合わせる形が現実的です。深刻度の付き方はClaude Securityの脆弱性タイプと深刻度の判定基準に詳しくまとめています。

レポートには、何を調べ、何を調べなかったかを述べるカバレッジの節もあります。大きなリポジトリを領域ごとに分けてスキャンしたときは、この節が「まだ見ていない範囲」の目印になります。

指摘は、独立した検証用エージェントが分析を終えたものだけが載ります。

JSONLで指摘を機械的に扱う

CLAUDE-SECURITY-RESULTS.jsonl は、.md と同じ指摘を1行に1オブジェクトで並べたファイルです。行数が指摘の件数に対応します。

wc -l CLAUDE-SECURITY-<timestamp>/CLAUDE-SECURITY-RESULTS.jsonl
head -n 1 CLAUDE-SECURITY-<timestamp>/CLAUDE-SECURITY-RESULTS.jsonl \
  | jq 'keys'

ここで使っている jq は標準では入っていないこともあるツールです。Claude Securityのドキュメントには、.jsonl の各行にどんなキーがあるかの一覧が載っていません。深刻度で絞り込むスクリプトを書く前に、上の jq 'keys' で実際のキー名を確かめてから、フィールド名を決めてください。

JSONLが向くのは、次のような用途です。

  • 指摘をチケット管理ツールに1件ずつ起票する
  • 過去のスキャンと件数や深刻度の分布を比べる
  • 社内のダッシュボードに取り込む

脆弱性スキャン結果をCSVに寄せて是正対応表にする流れは、脆弱性スキャン結果の優先度付けと是正対応表にあります。JSONLの内容を同じ表に流し込めます。

SARIFをGitHub code scanningに載せる

CLAUDE-SECURITY-RESULTS.sarif は、SARIF 2.1.0形式のログです。GitHubのcode scanningなど、この標準を読めるツールに渡すためのファイルで、指摘はCWEの弱点カテゴリに分類されています。

CWEの分類が付いているので、取り込んだ先でも「どの種類の弱点か」で集計できます。

GitHubへ取り込むときは、GitHub Actionsの upload-sarif アクションを使う方法が基本です。sarif_file に指定するのは、リポジトリのルートからの相対パスです。

permissions:
  security-events: write
steps:
  - uses: actions/checkout@v6
  - uses: github/codeql-action/upload-sarif@v4
    with:
      sarif_file: CLAUDE-SECURITY-<timestamp>/CLAUDE-SECURITY-RESULTS.sarif

<timestamp> は実際のディレクトリ名に置き換えてください。このアクションが読むのはリポジトリ内のパスなので、ワークフローに渡す前にSARIFをコミットしておく必要があります。コミットの方法は後の節で説明します。

GitHub側の条件も確認しておきます。code scanningが使えるのは、公開リポジトリか、GitHub Code Securityを有効にした組織所有のリポジトリです。有効になっていない非公開リポジトリでは、アップロード時に「GitHub Code Security or GitHub Advanced Security must be enabled for this repository to use code scanning」のエラーになります。

SARIFに partialFingerprints が含まれていない場合は、upload-sarif が計算して重複アラートを防ぎます。この計算には、リポジトリにSARIFと解析時のソースの両方があることが前提です。そのため、SARIFと、スキャン時のコミットのソースを同じリポジトリに揃えて置いてください。

リビジョンスタンプで結果をコードに結びつける

CLAUDE-SECURITY-REVISION-<commit>.json は、そのレポートがどのコードを見たものかを残すファイルです。ファイル名の <commit> が、スキャンしたコミットです。記録される項目は4つあります。

記録内容

リビジョンスタンプの記録項目

  • コミット

    どのコミットをスキャンしたか。

  • effort

    どの深さ（effort）で実行したか。

  • 未コミット変更

    スキャン対象の作業ツリーに、コミット前の変更が含まれていたか。

  • 検証の徹底度

    結果をどこまで検証した実行だったか。

バージョン管理の外のディレクトリをスキャンした場合は、コミットの代わりに UNVERSIONED と記録されます。

このスタンプが要るのは、スキャンが非決定的だからです。同じコードを2回スキャンしても、見つかる指摘が違うことがあります。件数の増減を「コードが悪化した」と読み違えないために、スタンプの値を揃えて比べる必要があります。

比較するときの確認項目は次の3つです。

  1. 両方のスタンプのコミットが、比べたい時点のものか
  2. effortが同じか
  3. 片方だけ未コミット変更を含んでいないか

「未コミット変更を含むか」は、特につまずきやすい点です。全体スキャンは作業ツリーを読むので、編集途中のファイルも対象になります。一方、ブランチの差分・プルリクエスト・単一コミットを対象にした変更スキャンは、コミット済みの変更だけを見ます。編集中の内容も含めたいときは全体スキャン、含めたくないときはコミットか退避をしてから実行します。

履歴に残すには.gitignoreを消す

結果ディレクトリには、専用の .gitignore が入っています。うっかり git add しても、レポートがコミットに混ざらないようにするための仕掛けです。

監査の証跡としてレポートを履歴に残したいときは、この .gitignore を1つだけ消してから、ディレクトリを通常のファイルと同じようにコミットします。

rm CLAUDE-SECURITY-<timestamp>/.gitignore
git add CLAUDE-SECURITY-<timestamp>/
git commit -m "add: Claude Securityスキャン結果を記録"

全部をコミットする必要はありません。履歴に何を入れるかの選び方は、目的によって変わります。

  • 監査の証跡が目的: 4ファイルすべて。特にスタンプが欠けると、レポートの前提が追えなくなる
  • GitHubへの取り込みだけが目的: SARIFとスタンプ
  • 作業用のメモで足りる: コミットせず、そのまま手元に置く

.gitignore を消すと、以降の git add を防ぐ仕掛けも外れます。レポートに攻撃シナリオまで書かれている点も踏まえて、公開リポジトリでは特に、コミット前に中身を見直してください。

patchesは自動では適用されない

指摘を修正に進めるときは、/claude-security のメニューから「Suggest patches」を選ぶか、「fix finding F3」のように頼みます。パッチは指摘ごとに patches/F<n>.patch として書き出され、横に変更内容を説明するメモが付きます。

パッチは自動では適用されません。適用するかどうかは常に読む側の判断で、次のコマンドで自分で当てます。

git apply CLAUDE-SECURITY-<timestamp>/patches/F1.patch

Claudeに「このパッチを適用してプルリクエストを出して」と頼む方法もあります。いずれの場合も、パッチごとに別のプルリクエストにするのが勧められています。個別にレビューとテストができるからです。

パッチが作られるのは、レビュー役のエージェントが次の3点を保証できたときだけです。

  • 変更が対象の1件の指摘に対応している
  • 新しい脆弱性を持ち込んでいない
  • それ以外の挙動を変えていない

3点のどれかを保証できないときは、パッチの代わりに理由のメモが返ります。パッチの対象コードにテストがない場合は、メモにそう書かれます。その場合、レビューはテスト実行なしで行われているので、適用後にテストを自分で用意するのが安全です。

もう1つの注意点が、レポートの鮮度です。パッチはコミット済みのコードに対して作られます。指摘の対象コードがその後変わっていると、その指摘は注記付きで飛ばされ、新しいスキャンを勧められます。古いレポートから修正を作り続けるのではなく、スタンプのコミットと現在のHEADを見比べて、差が大きいなら再スキャンに戻ってください。

まとめ

結果ファイルは、人が読む .md、機械が読む .jsonl、GitHubが読む .sarif、前提を残す REVISION-<commit>.json の4つです。再現性が必要な場面では、スタンプを一緒に保管することが肝になります。

履歴に残すかどうかは .gitignore の有無で決まり、パッチは必ず人が適用します。Snykなど既存のスキャナーとの組み合わせを検討する場合は、Claude CodeにSnyk Studioを入れる手順も参考になります。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →