Update to Codex Security

{
  "description": "Use when Codex is already in the attack-path-analysis phase of a security scan or the user explicitly asks to trace a security finding from source to sink and calibrate severity. Do not use as the primary trigger for full PR, commit, branch, patch, or repository scans.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 261
    },
    {
      "relative_path": "references/attack-path-facts.md",
      "size_in_bytes": 2882
    },
    {
      "relative_path": "references/severity-policy.md",
      "size_in_bytes": 15288
    }
  ],
  "name": "attack-path-analysis",
  "skill_md_contents": "---\nname: attack-path-analysis\ndescription: Use when Codex is already in the attack-path-analysis phase of a security scan or the user explicitly asks to trace a security finding from source to sink and calibrate severity. Do not use as the primary trigger for full PR, commit, branch, patch, or repository scans.\n---\n\n# Security Attack Path Analysis\n\nBefore choosing paths or saving retained output, read `../../references/artifact-storage.md` and follow its storage policy.\n\n## Objective\n\nTurn validated or still-plausible findings into explicit attacker stories, structured attack-path analysis facts, severity calibration, and a final reportability decision grounded in the threat model.\n\n## Artifact Resolution\n\nThe path references in this skill are the default locations for this phase.\nIf the user explicitly provides a different path for a required input or output, use the user-provided path instead of the corresponding default path referenced in this skill.\nIf a required input is still missing, stop and ask the user for it before continuing.\nUse the shared scan artifact path conventions in `../../references/scan-artifacts.md`.\n\nStandard scans and Deep Scan workers assess attack paths within their ordinary Standard scan workflow; neither invokes this separate phase skill.\n\n### Compact Workbench-Backed Diff Mode\n\nWhen a workbench-backed `$security-diff-scan` has a `scanId`, load the per-scan threat model and read the validated candidates with `list_codex_security_candidates({ scanId, cursor?, limit? })`. Analyze every `reportable` or `deferred` candidate, preserve every discovery and validation field and the original candidate order, and submit all decisions together with one `record_candidate_attack_paths({ scanId, attackPaths: [{ candidateId, attackPath }] })` call. Submit `attackPaths: []` when no candidate enters this phase. The existing tool atomically updates the stored candidates; do not create per-finding reports, receipts, or manual candidate ledgers in this compact diff mode. Keep attack-path facts, counterevidence, severity calibration, and policy adjustment as separate reasoning steps. Other scan and standalone workflows retain their existing artifact behavior.\n\n## Workflow\n\n1. Load the per-scan threat model path from `../../references/scan-artifacts.md` as the repo-specific threat-model source of truth. Start from this along with the potential findings. Both inputs are required for this workflow.\n   - For repository-wide and scoped-path scans, include validation closure rows marked `reportable` or `survives: yes` even if they were not assigned polished candidate numbers during discovery.\n2. Determine whether the affected code is in scope for the repository threat model and whether it belongs to a product surface or production workflow.\n3. Build a factual attack path using repository evidence only:\n   - service mapping\n   - exposure and entry points\n   - identity, privilege, and trust boundaries\n   - secrets handling and sensitive-data flow\n   - reachability\n   - existing controls and mitigations\n4. Before finalizing scope or reportability-driving facts, identify the strongest repository counterevidence against the key scoping fields and explain why it is or is not dispositive.\n5. Calibrate impact and likelihood from the repository evidence.\n6. Apply a separate final policy-adjustment pass mechanically using those facts and the calibrated severity.\n7. Record final policy decision `ignore` explicitly; in compact diff mode, retain its candidate record for coverage, and otherwise drop it from the surviving finding set.\n8. For a durable diff scan, submit the nested decision for every eligible candidate in the single compact tool call. Otherwise, save that finding's visible attack-path report and append one attack-path receipt per candidate id at the default paths from `../../references/scan-artifacts.md`. The receipt must record the candidate id, attack-path reportability decision, attack-path facts or exact proof gap, and attack-path artifact/report reference for that candidate finding.\n\n## Scope and Attack Path Checklist\n\nUse this checklist before finalizing the attack-path facts or policy decision:\n\n- Determine whether the finding is actually a real security vulnerability rather than a correctness bug or false positive.\n- Determine whether the affected code belongs to a product surface or production workflow.\n- Map the relevant service, component, or workflow context from repository evidence.\n- Establish exposure and entry points from repository evidence such as listeners, ingress, load balancers, service ports, manifests, routing, or network policy.\n- Establish identities, privileges, and trust boundaries that matter for the path.\n- Establish whether sensitive data, secrets references, or privileged control paths are involved.\n- Determine whether a realistic attacker can actually reach and use the issue from an in-scope attack surface.\n- Identify the strongest repository counterevidence against the scoping and reportability-driving fields before finalizing them.\n- Lower confidence or keep fields unknown when repository evidence is incomplete; do not automatically suppress a finding solely because deployment evidence is missing.\n\n## Counterevidence Checklist\n\nFor the most interpretive fields, explicitly ask what repository evidence suggests the opposite and why it does or does not defeat the finding:\n\n- In-Scope Status According to the Threat Model\n- Vector\n- Auth Scope\n- Exposure\n- Cross-Boundary Behavior\n- Preconditions\n- Impact Surface\n\nLook specifically for repository evidence that the path is:\n\n- out of scope\n- internal-only\n- admin-only\n- not cross-boundary\n- not attacker-reachable\n- not meaningfully reportable\n\n## Severity and Policy Checklist\n\nApply severity and policy calibration using `references/severity-policy.md`.\n\n## Output Contract\n\nIn compact diff mode, every candidate with validation disposition `reportable` or `deferred` must receive exactly one nested attack-path decision. The recorded decisions are the complete phase output; do not also create narrative reports or receipts. Otherwise, use the following report contract.\n\nFor each surviving finding include:\n\n- title\n- candidate id, instance key, and ledger row id when provided\n- affected lines from validation, preserving labeled entrypoint/wrapper, root_control, sink, and concrete_implementation locations\n- attack path steps\n- rendered attack-path facts\n- counterevidence summary and challenges\n- severity calibration\n- final policy decision\n- enough reasoning that a later reader can understand why the finding survived or was suppressed\n\nRender attack-path facts using `references/attack-path-facts.md`.\n\n## Hard Rules\n\n- Use repository evidence and explicitly supplied context. Access the network only when the user has expressly authorized that access; an offline scan never accesses the network.\n- Do not invent attack chains that the code does not support.\n- Do not leave candidate coverage implicit. In compact diff mode, record a nested attack-path decision for every eligible candidate, even when the final policy decision is `ignore` or `deferred`. Otherwise, every candidate that reaches attack-path analysis must leave an attack-path receipt in its candidate-ledger path from `../../references/scan-artifacts.md`.\n- Do not drop exact affected locations while converting validated findings into attack paths. Repository-wide seeded/root-control rows that survive validation must keep their root-control file:line even when a wrapper, route, or transport is easier to explain.\n- Do not skip a reportable validation row because a neighboring same-family finding has a cleaner story. Either produce attack-path facts for that exact row or make an explicit final policy decision with repository counterevidence.\n- Missing public-ingress evidence is not by itself dispositive counterevidence.\n- Keep attack-path analysis, severity calibration, and final policy suppression as separate sub-stages.\n- Use the final policy-adjustment matrix mechanically rather than re-arguing severity from scratch after the facts are set.\n- Outside compact diff mode, save a final visible report for each candidate finding using that finding's attack-path analysis report path from `../../references/scan-artifacts.md`.\n\n-- Considerations for attack path --\n- A bug matters if evidence shows an attacker could exploit it.\n- The attack surface should generally be one that is plausibly exposed to end users / external actors (or another actor explicitly in scope in the threat model).\n"
}