コードを監査してレポートを生成する

ラボをセットアップする

1. Galaxium Travelsリポジトリをクローンします。

   git clone -b bob-learning-path-branch https://github.com/IBM/galaxium-travels

2. FileをクリックしてからOpen Folderをクリックします。

3. クローンしたgalaxium-travelsディレクトリに移動して開きます。

4. ナビゲーションバーの横にあるBobアイコンをクリックするか、ショートカットOption + Command + B（macOS）またはCtrl + Alt + B（Windows）を使用して、Bobチャットインターフェースを開きます。

5. チャット入力フィールドで/initを実行して開発環境を初期化し、BobのAGENTS.mdファイルを作成します。プロンプトが表示されたらApprove todo tools for taskをクリックします。

監査スキルを作成する

スキルを作成します。これは、Bobが特定のタスクを実行するために使用する再利用可能な命令セットです。

次のスキルは、OWASP ASVS Level 1要件に対してGalaxium Travelsコードベースを監査します。

スキルは次の制御をチェックします。

1. チャットインターフェースの下にあるBob - Settingsをクリックしてから、Bob Settingsをクリックします。

2. 左サイドバーのSkillsをクリックします。

3. **+**ボタンをクリックして新しいスキルを作成します。

4. Skill Nameフィールドにasvs-auditと入力します。これは、チャットで/asvs-auditを使用してスキルを呼び出すために使用される名前です。

5. Descriptionフィールドに短い説明を入力します。

   Audits a codebase against OWASP ASVS Level 1 access control, input validation, API security, and configuration requirements.

6. Allow Bob to use this skillトグルがオンになっていることを確認します。

   トグルがオンの場合、プロンプトまたはプランが呼び出すと、Bobは独自にスキルをアクティブ化できます。このチュートリアルで後で作成する監査プランは、まさにそれを行います。

7. Scope & Locationをgalaxium-travelsに変更します。

   これにより、スキルがプロジェクトの.bob/skills/ディレクトリに保存されるため、このプロジェクトでのみ使用でき、チームはコードベースと一緒にバージョン管理できます。グローバルロケーション（~/.bob/skills/）を使用すると、マシン上のすべてのプロジェクトでスキルを使用できるようになります。

8. Skill Instructionsテキストボックスに次のスキルを入力します。

   ---
   name: asvs-audit
   description: Audit a codebase against OWASP ASVS Level 1 access control, input validation, API security, and configuration requirements and produce structured findings ready for SARIF and OSCAL export.
   user-invocable: true
   ---
   
   Perform a structured security audit of this codebase. Work through the following phases in order. Do not skip phases or combine them.
   
   ## Phase 1: Discover
   
   Read and understand the application before auditing. Focus on:
   - Entry points: main files, route definitions, controllers
   - Authentication and session handling code
   - Input validation and sanitization code
   - Database query code
   - Any files flagged as high-risk in earlier analysis
   
   Summarize what you find before proceeding to Phase 2.
   
   ## Phase 2: Audit
   
   Check each control below. For each one record: PASS, FAIL, or N/A.
   For every FAIL, record the file path and line number.
   
   ### V4.1 General Access Control
   - V4.1.3 — Users can only access their own resources; other users' data is not accessible
   - V4.1.5 — Access control denies by default — unauthenticated requests are rejected
   
   ### V4.2 Operation Level Access Control
   - V4.2.1 — Sensitive resources cannot be accessed by manipulating a predictable object ID (IDOR protection)
   
   ### V5.1 Input Validation
   - V5.1.1 — All string inputs have defined maximum length constraints
   
   ### V13.1 Generic Web Service Security
   - V13.1.3 — API endpoints do not accept credentials or PII in URL query parameters
   
   ### V14.4 HTTP Security Headers
   - V14.4.1 — HTTP responses include appropriate security headers such as Content-Security-Policy, X-Frame-Options, and X-Content-Type-Options
   
   ### V14.5 HTTP Request Header Validation
   - V14.5.3 — CORS origin is validated against an explicit allowlist — wildcard origins are not permitted
   
   ## Phase 3: Generate Findings
   
   For each FAIL, produce a finding in this format:
   
   **Finding [N]:**
   - Rule: ASVS [control number]
   - Severity: Critical / High / Medium / Low
   - File: [path]
   - Line: [number or range, if identifiable]
   - Issue: [one sentence describing what was found]
   - Fix: [one sentence describing the recommended change]
   
   ## Phase 4: Summary
   
   Produce a short summary:
   - Total controls checked
   - Pass / Fail / N/A counts
   - Two-sentence overall security posture assessment
   
   Save the findings to the location specified by the plan or prompt that invoked this skill. Do not generate SARIF, OSCAL, or other report files — report generation is a separate task. Report that the audit is complete and wait for the next instruction.

   これは、監査中にBobが従う完全な命令セットです。

9. Createをクリックします。

監査する高リスク領域を見つける

トークンを節約するために、Bobにセキュリティに最も関連するファイルとフォルダを特定するよう依頼します。これらの領域で監査スキルを実行します。

1. チャットパネルがまだ開いていない場合は、Option + Command + B（macOS）またはCtrl + Alt + B（Windows）で開きます。

2. モードセレクターからAskを選択します。

   各モードには異なる機能と推論スタイルがあります。Askモードは質問と分析に最適ですが、Askモードではファイルの書き込みや編集はできません。

3. チャット入力フィールドに次のプロンプトを入力して、コードベースを探索し、最も高いセキュリティリスク領域を見つけます。

   Explore this codebase as a Senior Security Analyst. Give me a short summary covering:
   
   1. The primary tech stack and framework
   2. Identify the files and folders most relevant to security
   
   Make sure to also review:
   1. How authentication and session management are handled
   2. How user input is accepted and validated
   3. Where database queries are made
   4. Any API endpoints that accept external input
   
   I want to understand the highest security risk areas before running an audit.

   Bobはファイルを読み取り、アプリケーション構造の要約を返します。

高リスク領域を監査するためのプランを作成する

高リスク領域を監査する際にBobが従うプランを作成します。

1. Planモードに切り替えます。

2. Bobに高リスク領域を監査するためのプランを作成するよう促します。プロンプトが表示されたらApprove todo tools for taskをクリックします。

   Create a plan for auditing the high-risk areas found in the previous
   exploration.
   
   When auditing, use the asvs-audit skill to guide the process.
   
   When the plan runs, create the security/ directory if it does not exist and
   save the findings to security/audit-findings.md
   
   Save the plan to plan/audit-plan.md

3. Bobは、監査の範囲や焦点を当てる特定の領域を明確にするためのフォローアップ質問をする場合があります。それらに答えるか、Bobにuse your recommendationと伝えることができます。

4. プランファイルを開いて、監査アプローチとBobが実行時に何を行うかを理解します。

コードベースを監査する

1. **+**ボタンをクリックして新しいタスクを開始します。

2. チャットインターフェースでAgentモードになっていることを確認します。

   Agentモードは、ファイルの書き込みと実行を含む完全な機能をBobに提供します。これは、監査とレポート生成フェーズに必要です。

3. チャットインターフェースのPermissionsセレクターをクリックし、Read、Edit、Execute、Skillチェックボックスをオンにします。このタスクでは、他のすべてのトグルをオフのままにします。

   権限	状態	理由
   Read	✅ オン	Bobはコードベース、監査プラン、スキルを読み取る
   Edit	✅ オン	Bobは検出結果をsecurity/audit-findings.mdに書き込む
   Execute	✅ オン	Bobはパスを解決したりファイル構造を確認したりするためにシェルコマンドを実行する場合がある
   Skill	✅ オン	監査プランはasvs-auditスキルを呼び出す
   MCP	❌ オフ	ローカルコード分析には不要

4. Bobに監査プランを実装するよう依頼します。

   Implement the @plan/audit-plan.md

5. security/audit-findings.mdの検出結果を確認します。

   プランは、Bobにsecurity/ディレクトリがまだ存在しない場合は作成し、検出結果をsecurity/audit-findings.mdに保存するよう指示します。

   検出結果を保存することで、新しいコンテキストウィンドウを使用してモデルで新しいチャットを開始できます。コードベース全体とスキル命令を再読み込みすることなく、検出結果ファイルをBobに指示してレポートを生成できるため、レポート生成のためのコンテキストウィンドウが保持されます。

   コンテキストウィンドウに関する注意: すべてのモデルには設定されたコンテキストウィンドウがあります。大規模なコードベースを監査する場合、モデルのコンテキストウィンドウを超える可能性があります。大規模なコードベースの場合は、一度に1つのASVSカテゴリを監査してみてください。最初にV4を実行し、次にV5、V13、V14を実行し、最後にBobに検出結果を統合するよう依頼します。これは、SKILL.mdを簡潔に保ち、リポジトリ全体を一度にBobに指示するのではなく、焦点を絞った@コンテキストメンションを使用する良い理由でもあります。

セキュリティレポートを生成する

SARIFは、静的解析結果の標準交換形式です。Bobを含むIDE、GitHub Advanced Security、およびほとんどのCI/CDパイプラインは、SARIFファイルを直接使用できます。

1. **+**ボタンをクリックして新しいタスクを開始します。

2. Agentモードを使用していることを確認します。

3. チャットパネルのPermissionsをクリックし、Read、Edit、Executeチェックボックスをオンにします。このタスクでは、他のすべてのトグルをオフのままにします。

   権限	状態	理由
   Read	✅ オン	Bobはsecurity/audit-findings.mdの検出結果を読み取る
   Edit	✅ オン	BobはSARIFレポートをsecurity/ディレクトリに書き込む
   Execute	✅ オン	Bobはパスを解決したりファイル構造を確認したりするためにシェルコマンドを実行する場合がある
   Skill	❌ オフ	レポートの作成には不要。スキルはすでにエージェントが必要とする検出結果を作成した
   MCP	❌ オフ	ローカルコード分析には不要

4. @コンテキストメンションを使用して、BobにSARIFレポートを生成するよう依頼します。

   @security/audit-findings.md
   
   Generate a SARIF 2.1.0 report from the audit findings.
   
   Save it to `security/audit-results.sarif`.
   
   Include:
   - Tool name: "ASVS Security Audit"
   - A rule entry for each ASVS control that was checked, with the control ID and description
   - A result entry for each finding, with severity level, file path, line number, and the fix recommendation in the message field

   Bobはファイルを生成し、security/audit-results.sarifに保存します。ファイルに検出結果ごとに1つのresultsエントリを持つruns配列が含まれていることを確認します。

   Bobはまた、チャットで行ったマッピング決定を報告します。

   出力例:

   Severity mapping used: Critical/High → SARIF error; Medium/Low → SARIF warning.
   The message.text for each result contains the full issue description and the fix
   recommendation in one field, so tooling that renders SARIF (GitHub Code
   Scanning, VS Code SARIF Viewer, etc.) will surface the remediation guidance
   inline.

5. Bobでsecurity/audit-results.sarifを開いて検出結果を確認します。このファイルは、GitHub Advanced SecurityやCI/CDパイプラインなどの他のツールで使用して、監査の検出結果を表示できます。

OSCAL修復プラン（POA&M）を生成する

OSCAL POA&Mは、各検出結果をリスク情報、実装ガイダンス、マイルストーン割り当てを含む構造化された修復タスクにマッピングする機械可読JSONドキュメントです。Bobはこのファイルを作業キューとして読み取ることができます。各項目を処理し、修正を適用し、進行に応じてマイルストーンを完了としてマークします。

1. **+**ボタンをクリックして新しいタスクを開始します。

2. チャットパネルのモードメニューをクリックし、Agentを選択します。

3. チャットパネルのPermissionsをクリックし、Read、Edit、Executeチェックボックスをオンにします。このタスクでは、他のすべてのトグルをオフのままにします。

   権限	状態	理由
   Read	✅ オン	Bobはsecurity/audit-findings.mdの検出結果を読み取る
   Edit	✅ オン	BobはOSCAL POA&Mをsecurity/ディレクトリに書き込む
   Execute	✅ オン	Bobはパスを解決したりファイル構造を確認したりするためにシェルコマンドを実行する場合がある
   Skill	❌ オフ	レポートの作成には不要。スキルはすでにエージェントが必要とする検出結果を作成した
   MCP	❌ オフ	ローカルコード分析には不要

4. @コンテキストメンションを使用して、BobにOSCAL POA&Mレポートを生成するよう依頼します。

   @security/audit-findings.md
   
   Generate an OSCAL Plan of Action and Milestones (POA&M) from the audit findings.
   
   Save it to `security/poam.json`.
   
   For each finding include:
   - A unique UUID
   - The ASVS control ID as the finding reference
   - Severity and a one-sentence risk description
   - A concrete remediation task with enough detail for an AI agent to implement it without additional context — include file path, line reference, and the specific change required
   - A milestone label based on severity: Critical and High findings get "sprint-1", Medium and Low get "sprint-2"
   
   Use OSCAL version 1.1.2 structure.

   Bobはファイルを生成し、security/poam.jsonに保存します。

   出力例:

   Each poam-item contains:
   
   props — severity, asvs-control, and milestone label
   risks[] — one risk with a uuid, title, one-sentence risk description, and status: "open"
   
   remediations[] — one remediation with a lifecycle: "planned" flag, a title, and a description
   that is specific enough for an AI agent to implement without additional context
   (includes exact file paths, line numbers, and the concrete code change required)
   
   tasks[] — one or more discrete action tasks under each remediation (e.g. the IDOR finding breaks
   out the short-term ownership check and the long-term UUID migration as separate tasks)

これで、security/ディレクトリに2つの成果物ができました。

• audit-results.sarif — 開発者ツールとCI/CD統合のための構造化された検出結果
• poam.json — AI支援または人間主導の修復のための修復作業キュー

検出結果を確認する

POA&Mが生成されたら、検出結果を確認し、最初に修正するものを優先順位付けします。

1. **+**ボタンをクリックして新しいタスクを開始します。

2. チャットパネルのモードメニューをクリックし、Askを選択します。

3. @コンテキストメンションを使用して、BobにPOA&Mから最も重要な項目を強調表示するよう依頼します。

   @security/poam.json
   
   Review this remediation plan and identify the 3 most critical items to fix first.
   
   For each one include:
   - What the vulnerability is and why it is the highest priority
   - Which file and line to look at
   - What the fix involves and roughly how long it would take a developer to implement

   Bobはファイルを読み取り、優先順位付けされた要約を返します。

   出力例:

   #1 — No Authentication on Any Endpoint (Finding 1 · ASVS V4.1.5 · critical)
   Why it's the highest priority:
   This is the foundational flaw that makes every other vulnerability worse. With
   zero authentication in place, any anonymous caller on the network can execute
   all booking operations — book flights, read all user records, cancel any
   booking, register accounts. Until this is fixed, findings 2 and 3 also have no
   meaningful barrier.
   
   ...snip...
   
   #3 — PII in URL Query Parameters on GET /user (Finding 5 · ASVS V13.1.3 · high)
   Why it's third:
   Email addresses (PII) appearing in GET /user query strings are passively and
   silently leaked into server access logs, reverse-proxy logs, CDN caches, and
   browser history — a persistent, silent data breach that can violate GDPR. Unlike
   findings 2 and 3, this is an architectural leak that accumulates over time;
   every request compounds the exposure.
   
   Sprint-1 Fix Order Summary
   
   Priority    Finding Severity        Effort  Dependency
   1   Auth on all endpoints (V4.1.5)  Critical        2–4 h   None — fix first
   2   Wildcard CORS (V14.5.3) High    30 min  Independent — fix in parallel
   3   PII in query string (V13.1.3)   High    1–2 h   Independent — fix in parallel
   
   Findings 2 and 3 are blockers in the ownership-check fixes (Findings 2 and 3 in
   the POAM) that come afterward, since those require a known caller identity —
   which only exists once authentication (Finding 1) is in place.

   また、Model Context Protocol（MCP）サーバーを監査ワークフローに統合し、Bobに各検出結果のチケットを作成し、関連するコードにリンクし、POA&Mからの修復ガイダンスを含めるよう依頼することもできます。