mcpField
C
cyber-audit

cyber-audit

github.com/hcaianoセキュリティ49 回インストール
リポジトリ

cyber-audit について

cyber-auditは、指定されたアドバイザリに基づいてマシンへの影響を調べ、結果を記録するセキュリティ監査スキルです。マシンの状態を変更せずにリスクを確認したい場合に適しています。

主な機能

  1. 01アドバイザリに基づく範囲設定
  2. 02マシンの読み取り専用チェック
  3. 03OSとエコシステム別の確認
  4. 04チェック結果の個別記録
  5. 05日付入り監査レポートの作成
  6. 06攻撃経路に基づく判定

活用シーン

  1. 01指定されたCVEに対するホスト確認
  2. 02脆弱なパッケージやバイナリの評価
  3. 03サービスへの到達可能性の確認
  4. 04監査記録の作成

インストール

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

$npx skills add https://github.com/hcaiano/skills --skill cyber-audit

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

同梱ファイルagents/openai.yamlreferences/checks.md

詳細

cyber-audit

このマシンが指定されたアドバイザリの影響を受ける状態かどうかを判定し、監査記録を残します。

厳守事項

  • マシン上では読み取り専用で作業します。 診断を行い、修復はユーザーが行います。~/security-audits/ 以外では、インストール、削除、アップグレード、再起動、設定変更、ファイルへの書き込みを行いません。アドバイザリを読むことは問題ありません。信頼できる情報源から取得するか、ユーザーが提供した全文を使用してください。
  • sudo は使用しません。
  • 状態を変更するコマンドが必要なチェックは実行せず、「未チェック(状態変更が必要)」と記録してください。
  • 呼び出しごとにレポートを1つ作成します。 「影響なし」の場合も例外ではありません。これが監査記録になります。

ワークフロー

  1. アドバイザリから対象範囲を特定します。 アドバイザリ自体から、影響を受けるパッケージまたはバイナリ、影響を受けるバージョン、プラットフォーム、攻撃ベクトル(サプライチェーン/RCE/ローカル/ネットワーク)を確認します。CVE ID またはパッケージ名しか提示されていない場合は、監査を始める前にアドバイザリを調べるか、全文を尋ねてください。根拠のない判定を出すより、判定を出さないほうが適切です。影響を受けるバージョンをアドバイザリの記載と照合できたら完了です。
  2. チェックします。 uname -s を読み取り、次に references/checks.md を読み、このアドバイザリのエコシステムと OS に対応するチェックを選びます。互いに独立したチェックは並行して実行します。
  3. 作業しながら表を作成します。 チェックごとに、具体的な結果(バージョン、パス、「なし」、「該当なし」、または理由を添えた「未チェック」)を1行記載します。選択したすべてのチェックに行があり、判定に必要な未確認事項がすべて明記されたら完了です。
  4. レポートを作成します。 mkdir -p ~/security-audits を実行し、下記のテンプレートを使って、環境から取得した今日の日付を含む ~/security-audits/YYYY-MM-DD-<short-kebab-slug>.md を作成します。判定が「影響あり」の場合は、ユーザーが実行する修復コマンドを フォローアップ に記載します。
  5. 判定を報告します。 1行で判定を伝え、レポートのパスを示します。

レポートテンプレート

# <Subject> — Audit

**Date:** YYYY-MM-DD
**Host:** <this machine>

## <CVEs | Advisory> in scope

- **<ID or source> "<Name>"** — <one-line description>. <Affected versions or scope>.

## Audit results

| Check | Result |
|---|---|
| <Check 1> | <Result> |
| <Check 2> | <Result> |

## Verdict

**<Not affected. | Affected. | Partially affected. | Inconclusive.>**

- <Rationale bullet 1>
- <Rationale bullet 2>

## Action taken

None — diagnostic only, no files modified outside the report directory.

## Follow-ups

- <Actionable item, or "None">

判定

どのチェックで露出を確認するかは、攻撃ベクトルによって決まります。

  • サプライチェーン/悪意のあるパッケージ:脆弱なバージョンが存在すれば露出しています。インストール時やインポート時のペイロードは、すでに実行されている可能性があるためです。実行中かどうかにかかわらず、脆弱なバージョンが存在する場合は影響ありです。レポートには観測されたパッケージの状態を記載し、ペイロードが実行されたとは記載しません。
  • ネットワーク/サービス(RCE):脆弱なコードが実行中で、到達可能である場合に露出しています。したがって、プロセスとリスナーのチェックで判定します。

判定:

  • 影響なし。 存在しないか、インストール済みでも修正済みです。ネットワーク/サービスのアドバイザリでは、インストール済みでも実行されておらず、露出していない場合も含みます。
  • 影響あり。 脆弱なバージョンが存在し、攻撃ベクトルから到達可能です。
  • 部分的に影響あり。 ネットワーク/サービスのアドバイザリのみ:インストール済みで実行中ですが、到達可能性が一部に限られます。例:ループバックにバインドされている、または認証やファイアウォールの背後でのみ公開されている場合です。緩和策を明記してください。サービスが完全に停止している場合は影響なしです。
  • 判定不能。 不在、バージョン、または到達可能性の証明に必要なチェックを実行できませんでした。そのチェックと不足している証拠をレポートに明記してください。

コメント