attack-path-analysis

bởi openai

Sử dụng khi Codex đã ở trong giai đoạn phân tích đường tấn công của một lần quét bảo mật hoặc người dùng yêu cầu rõ ràng để truy vết một phát hiện bảo mật từ nguồn đến điểm cuối và…

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.

Thêm skills từ openai

release
openai
Cắt một bản phát hành Symphony bằng cách tăng phiên bản đã cam kết, đưa nó vào, gắn thẻ commit đã hợp nhất, và xác minh quy trình phát hành Burrito. Sử dụng khi được yêu cầu…
signing-entitlements
openai
Kiểm tra các vấn đề về chứng thực, quyền hạn, hardened runtime và Gatekeeper cho ứng dụng macOS. Sử dụng khi được yêu cầu chẩn đoán lỗi ký mã, thiếu quyền hạn,…
building-ai-agent-on-cloudflare
openai
Xây dựng các tác tử AI trên Cloudflare bằng Agents SDK với quản lý trạng thái, WebSockets thời gian thực, tác vụ theo lịch trình, tích hợp công cụ và trò chuyện…
epigraphdb-skill
openai
Gửi các yêu cầu API EpiGraphDB nhỏ gọn cho ontology, tài liệu, MR, gen-thuốc và bằng chứng hỗ trợ đường dẫn. Sử dụng khi người dùng muốn tóm tắt EpiGraphDB ngắn gọn.
runtime-behavior-probe
openai
Lập kế hoạch và thực hiện các cuộc điều tra hành vi thời gian chạy với các tập lệnh thăm dò tạm thời, ma trận xác thực, kiểm soát trạng thái và báo cáo ưu tiên phát hiện. Chỉ sử dụng khi…
deep-security-scan
openai
Sử dụng khi người dùng yêu cầu quét bảo mật Codex sâu, toàn diện, nhiều lượt hoặc giảm sai lệch trên toàn kho lưu trữ hoặc phạm vi đường dẫn cụ thể. Chạy lặp lại các lượt độc lập…
define-security-policy
openai
Xác định, xem xét hoặc cập nhật hướng dẫn SECURITY.md cho một kho lưu trữ hoặc thành phần. Sử dụng khi người dùng muốn làm rõ những gì Codex Security nên xem xét, những gì nằm ngoài phạm vi…
validation
openai
Sử dụng khi Codex đã ở trong giai đoạn xác thực của một cuộc quét bảo mật hoặc người dùng yêu cầu rõ ràng để xác định liệu một hoặc nhiều phát hiện bảo mật ứng viên…