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
커밋된 버전을 올리고, 이를 반영하고, 병합된 커밋에 태그를 단 후, Burrito 릴리스 워크플로우를 검증하여 Symphony 릴리스를 진행합니다. 다음과 같이 요청받았을 때 사용합니다…
signing-entitlements
openai
macOS 앱의 서명, 자격, 강화된 런타임 및 Gatekeeper 문제를 검사합니다. 코드 서명 실패, 누락된 자격 등을 진단하라는 요청을 받을 때 사용하세요.
building-ai-agent-on-cloudflare
openai
Cloudflare에서 Agents SDK를 사용하여 상태 관리, 실시간 WebSockets, 예약 작업, 도구 통합, 채팅을 통해 AI 에이전트를 구축합니다…
epigraphdb-skill
openai
온톨로지, 문헌, MR, 유전자-약물 및 지원 경로 증거에 대한 간결한 EpiGraphDB API 요청을 제출합니다. 사용자가 간결한 EpiGraphDB 요약을 원할 때 사용하세요.
runtime-behavior-probe
openai
런타임 동작 조사를 계획하고 실행하며, 임시 프로브 스크립트, 검증 매트릭스, 상태 제어, 결과 우선 보고서를 사용합니다. 다음 경우에만 사용하세요…
deep-security-scan
openai
사용자가 심층적이고, 철저하며, 다중 패스 또는 변동성을 줄이는 저장소 전체 또는 범위가 지정된 경로의 Codex Security 스캔을 요청할 때 사용합니다. 반복적으로 독립적인…
define-security-policy
openai
저장소 또는 구성 요소에 대한 SECURITY.md 지침을 정의, 검토 또는 업데이트합니다. 사용자가 Codex Security가 검토해야 할 대상과 범위를 벗어나는 항목을 명확히 하려 할 때 사용합니다…
validation
openai
Codex가 보안 스캔의 검증 단계에 이미 있거나 사용자가 하나 이상의 후보 보안 결과를 판별하도록 명시적으로 요청할 때 사용합니다…