attack-path-analysis

作成者: openai

Codexがセキュリティスキャンのattack-path-analysisフェーズにすでにいる場合、またはユーザーがセキュリティ上の発見をソースからシンクまで明示的にトレースするよう求めた場合に使用します。

npx skills add https://github.com/openai/codex-security --skill attack-path-analysis

Security Attack Path Analysis

Determine whether each supplied finding has a supported attacker path, what impact it has, and whether it is reportable. Before creating or retaining files, read ../../references/artifact-storage.md.

Establish the attack path

For a scan phase, use its per-scan threat model and candidate set from ../../references/scan-artifacts.md. Preserve supplied input paths. If a required scan artifact is unavailable, report the missing input.

For standalone analysis, use the supplied finding, repository, threat model or security policy, and context. A per-scan artifact is not required. State material assumptions and ask for missing context only when it prevents a meaningful assessment.

  1. Establish the in-scope attacker, affected product surface, entry point, controlled input, security boundary, and sensitive operation. Trace the path from repository evidence.
  2. Identify relevant controls and the strongest counterevidence. Explain what they establish, which prerequisites remain, and whether the exact claimed boundary is crossed.
  3. Assess impact and likelihood from those facts. Apply references/severity-policy.md for the final decision. When the scan supplies a severity rubric, use it to grade reportable findings and retain ignore for candidates without security impact. Keep facts, severity calibration, and the final policy decision distinguishable in the result.
  4. Return an explicit decision for every eligible candidate, including ignored or deferred candidates. Do not replace a supported instance with a neighboring finding or lose its root-control location.

Use repository evidence and explicitly supplied context. Access the network only when the user has expressly authorized it; an offline scan never accesses the network. Do not invent unsupported attack chains. Missing deployment or public-ingress evidence can limit confidence without defeating an otherwise supported finding.

Scan integration

Standard scans and Deep Scan workers assess attack paths within their ordinary Standard scan workflow; neither invokes this separate phase skill.

Compact Workbench Diff

When a workbench-backed $security-diff-scan has a scanId:

  • Load the per-scan threat model and all validated candidates with list_codex_security_candidates({ scanId, cursor?, limit? }).
  • Analyze every reportable or deferred validation candidate. Preserve candidate identity and existing discovery and validation fields.
  • Submit every decision together with record_candidate_attack_paths({ scanId, attackPaths: [{ candidateId, attackPath }] }). Submit attackPaths: [] when no candidate enters this phase. The tool preserves the stored candidate order.
  • These nested decisions are the complete phase output. Do not create duplicate reports, receipts, or manual ledgers.

Other phase-based scans

Use the active workflow's report and receipt paths in ../../references/scan-artifacts.md. Every candidate entering this phase must have an explicit decision and a receipt with its ID, facts or exact proof gap, and report reference. Record ignored candidates before excluding them from the surviving finding set.

For repository-wide or scoped-path scans, include validation closure rows marked reportable or survives: yes, even if discovery did not assign a polished finding number. Preserve affected entrypoint/wrapper, root-control, sink, and concrete-implementation locations supplied by validation.

Output

For standalone analysis, follow the caller's format or return a concise assessment per finding. Scan phases use their output contract above. Include:

  • title and supplied candidate, instance, and ledger identities;
  • precise affected locations and attacker-to-impact steps;
  • relevant facts from references/attack-path-facts.md;
  • controls, counterevidence, prerequisites, and material proof gaps;
  • impact, likelihood, calibrated severity, and final policy decision with their reasons.

Retain enough evidence to explain both surviving and suppressed findings. Apply the severity policy to the established facts rather than reopening discovery or substituting a different attack story.

openaiのその他のスキル

release
openai
コミットされたバージョンを更新して Symphony リリースを切り、それをコミットし、マージされたコミットにタグを付け、Burrito リリースワークフローを確認します。求められた際に使用します…
signing-entitlements
openai
macOSアプリの署名、権限、ハード化されたランタイム、Gatekeeperの問題を検査します。コード署名の失敗や権限の欠落などの診断を求められた際に使用します。
building-ai-agent-on-cloudflare
openai
Cloudflare上でAgents SDKを使用してAIエージェントを構築し、状態管理、リアルタイムWebSocket、スケジュールタスク、ツール統合、チャットなどを実現します。
epigraphdb-skill
openai
オントロジー、文献、MR、遺伝子-薬剤、サポートパスエビデンスに関するコンパクトなEpiGraphDB APIリクエストを送信します。ユーザーが簡潔なEpiGraphDBサマリーを希望する場合に使用します。
runtime-behavior-probe
openai
一時的なプローブスクリプト、検証マトリックス、状態制御、および発見事項優先のレポートを用いて、ランタイム動作調査を計画・実行します。以下の場合にのみ使用してください…
deep-security-scan
openai
ユーザーがリポジトリ全体またはスコープ指定パスに対する深く網羅的な、マルチパスまたはバリアンス低減型のCodexセキュリティスキャンを求めた場合に使用します。独立した反復実行を複数回行います…
define-security-policy
openai
リポジトリまたはコンポーネントのSECURITY.mdガイダンスを定義、レビュー、または更新します。ユーザーがCodex Securityがレビューすべき内容、対象外の内容を明確にしたい場合に使用します。
validation
openai
Codexがセキュリティスキャンの検証段階にすでにある場合、またはユーザーが1つ以上の候補となるセキュリティ findings が…かどうかを判断するよう明示的に求めた場合に使用します。