chore(codex-security): sync public projection

  - [codex-security] simplify standard security scan (#1154250)

GitOrigin-Timestamp=2026-07-27T12:20:24-07:00
GitOrigin-RevId: 081b5a80efb844fdc5f22f99e45f7a3e38eda352

Author: ianw-oai

sdk/typescript/_bundled_plugin/references/final-report.md

@@ -53,7 +53,11 @@ Set the finding category and CWE from the primary broken control. Do not add sec
 
 Examples that should normally become separate final findings include SQL API modes such as `execute`, `executemany`, and `executescript`; deserializer variants such as `pickle.load`, `pickle.loads`, `yaml.load`, and `yaml.load_all`; distinct path/file helper calls; SSRF modes with different destination controls; and missing-auth protected actions such as create, delete, reset, admin, and job-trigger endpoints.
 
-Before completing canonical JSON, reconcile each final finding against its candidate-ledger path from `scan-artifacts.md`, the saved validation closure table, and the repository coverage ledger when those artifacts exist. Every final candidate finding must have discovery, validation, and attack-path receipts for the same candidate id, or an explicit follow-up-needed reason for the missing proof. Start from validated rows marked `reportable` or `survives: yes`, not only from the most polished candidate narrative. Every `reportable` seeded or root-control ledger row must become a canonical finding with the same root-control file:line. Rows closed as `suppressed`, `not_applicable`, or `deferred` should appear in canonical coverage surfaces using public-facing outcomes such as `Rejected`, `Not applicable`, or `Needs follow-up`. Do not silently drop a seeded/root-control row because a same-family neighboring finding survived. If attack-path analysis omitted a reportable validation row, populate a concise canonical attack path from the validation evidence and threat model rather than dropping the row.
+For a standard repository or scoped-path scan, assemble the canonical JSON from the enriched `<discovery_dir>/candidate_ledger.jsonl`. Map each nested `validation` record into the finding's validation fields, map its confidence and rationale into top-level `confidence.level` and `confidence.rationale`, and map each nested `attack_path` record into dataflow, reachability, severity, and change conditions.
+
+Apply row outcomes in this order: validation disposition `reportable` plus attack-path decision `reportable` becomes a finding with its distinct instance and all relevant entrypoint, root-control, sink, and supporting locations; otherwise, a `deferred` result from either phase becomes `needs_follow_up` coverage and a `coverage.deferred` entry using the recorded uncertainty or proof gap; otherwise, validation disposition `not_applicable` becomes `not_applicable` coverage; otherwise, validation disposition `suppressed` or attack-path decision `ignore` becomes `rejected` coverage. A missing required phase record leaves the candidate unresolved and prevents complete coverage. Do not require phase receipts, per-candidate narratives, or another reconciliation pass.
+
+Diff, deep, and resumed legacy scans may still provide per-candidate ledgers, validation closure tables, and repository coverage ledgers. When those artifacts exist, retain their traceability: start from reportable/surviving rows, preserve exact affected locations, and map suppressed, not-applicable, or deferred rows to public-facing coverage outcomes. Do not silently drop a seeded row because a same-family neighbor survived.
 
 ## Report Structure
 

sdk/typescript/_bundled_plugin/references/sarif-adapter.md

@@ -10,7 +10,7 @@ The adapter:
 - uses stable `ruleId` values
 - keeps rule descriptors stable across scans
 - emits repository-relative POSIX paths
-- uses one root-control location for GitHub annotation when available and keeps remaining evidence locations under `relatedLocations`
+- keeps the root-control location first for GitHub annotation when available and emits every distinct affected or code-evidence location in `locations`, so vulnerable sinks remain matchable
 - preserves the semantic fingerprint under `codexSecurity/v1`
 - emits GitHub's source-line `primaryLocationLineHash` when it can safely hash a bounded regular non-symlink source file inside the available source root
 - maps categorical severity to SARIF `level`

sdk/typescript/_bundled_plugin/references/scan-artifacts.md

@@ -38,6 +38,19 @@ End each repository-scoped threat model with these two lines:
 
 ## Finding Discovery (Phase 2) Paths
 
+### Standard Repository Or Scoped-Path Scan
+
+- Deterministic in-scope file list: `<discovery_dir>/in_scope_files.txt`
+- Compact combined candidate ledger: `<discovery_dir>/candidate_ledger.jsonl`
+  - The combiner reads one or more temporary raw candidate sources, validates them against the in-scope file list, merges rows with the same CWE ids, locations, and optional instance, preserves their text, and assigns deterministic `candidate_id` values. This is the sole durable standard candidate artifact.
+  - After normalization, compact validation adds exactly one `validation` object to every row with `disposition` (`reportable`, `suppressed`, `not_applicable`, or `deferred`), `method`, `confidence` (`high`, `medium`, or `low`), `confidence_rationale`, concise `rubric` and `evidence`, `counterevidence_or_proof_gap`, `remaining_uncertainty`, and optional `artifact_paths`. Add `source`, `control`, `sink`, or `preconditions` only when they clarify or differ from the discovery fields.
+  - Compact attack-path analysis adds exactly one `attack_path` object to each validation row marked `reportable` or `deferred`, with `decision` (`reportable`, `ignore`, or `deferred`), `dataflow`, `reachability`, `counterevidence`, `impact` and `likelihood` (`high`, `medium`, `low`, `ignore`, or `unknown`), `severity` (`critical`, `high`, `medium`, `low`, `ignore`, or `unknown`), `severity_rationale`, `change_conditions`, and `proof_gap` when deferred. A `reportable` decision requires severity `critical`, `high`, `medium`, or `low`; `ignore` requires severity `ignore`; `deferred` uses a provisional reportable severity or `unknown`.
+  - Preserve all discovery fields and row order during enrichment, rewrite atomically, and do not pass the enriched ledger back to `normalize_candidates.py`.
+- Optional compact validation evidence: `<discovery_dir>/validation_artifacts/<candidate_id>/`
+  - Create this directory only for actual PoCs, crafted inputs, or logs and reference those paths from the row's `validation` object. Do not create placeholder per-candidate directories or narrative reports.
+
+The legacy ranking, raw/deduped candidate, per-finding receipt, and phase-report paths below are for diff/deep or resumed legacy workflows. A compact standard scan uses the enriched ledger instead.
+
 ### Coverage Planning
 
 - Advisory seed research: `<context_dir>/seed_research.md`
@@ -69,12 +82,16 @@ End each repository-scoped threat model with these two lines:
 
 ## Validation (Phase 3) Paths
 
+Compact standard scans use the nested `validation` record and optional compact evidence path above. Other scan modes use these paths:
+
 - Scan-level validation summary: `<findings_dir>/validation_summary.md` if applicable
 - Per-finding validation report: `<findings_dir>/<candidate_id>/validation_report.md`
 - Per-finding validation artifacts: `<findings_dir>/<candidate_id>/validation_artifacts/`
 
 ## Attack-Path Analysis (Phase 4) Paths
 
+Compact standard scans use the nested `attack_path` record above. Other scan modes use these paths:
+
 - Scan-level attack-path analysis report: `<findings_dir>/attack_path_analysis_report.md` if applicable
 - Per-finding attack-path analysis report: `<findings_dir>/<candidate_id>/attack_path_analysis_report.md`
 
@@ -95,5 +112,5 @@ End each repository-scoped threat model with these two lines:
 
 - Put scan phase outputs and supporting evidence under the numbered artifact subdirectories above.
 - Keep fix-finding outputs outside the numbered scan phases because fix-finding can run standalone or against an existing scan.
-- Do not author the final `report.md` directly. Put complete scan-level report semantics in the canonical JSON files and detailed per-finding prose in `findings/<slug>/<slug>.md`. Put derived design guidance under `hardening/`. Finalization deterministically writes the unsealed `report.md` projection and links any recorded write-ups and hardening portfolio. Do not add these derived documents to the sealed artifact list.
+- Do not author the final `report.md` directly. Put complete scan-level report semantics in the canonical JSON files. Detailed per-finding prose in `findings/<slug>/<slug>.md` and derived design guidance under `hardening/` are optional for a standard scan. Finalization deterministically writes the unsealed `report.md` projection and links any recorded write-ups and hardening portfolio. Do not add these derived documents to the sealed artifact list.
 - Keep the full scan bundle together under `scan_dir`.

sdk/typescript/_bundled_plugin/references/scan-contract.md

@@ -60,7 +60,7 @@ Do not put line numbers in `identity.anchor`. When two sibling vulnerabilities s
 
 Fingerprint matching is a reconciliation signal, not proof that two findings are equivalent. Treat ambiguous matches as unresolved.
 
-When a finding has multiple affected locations, label the vulnerable control location `root_control` when one is known. Adapters use the first `root_control` location as the primary annotation location and otherwise fall back to the first affected location. Preserve supporting entrypoint, wrapper, sink, and concrete-implementation locations as additional evidence.
+When a finding has multiple affected locations, label the vulnerable control location `root_control` when one is known. Adapters keep the first `root_control` location first and otherwise fall back to the first affected location, while preserving every distinct entrypoint, wrapper, sink, concrete-implementation, and code-evidence occurrence as a matchable location.
 
 ## Rule ID Policy
 

sdk/typescript/_bundled_plugin/references/shared-hard-rules.md

@@ -1,6 +1,6 @@
 # Shared Hard Rules
 
-Apply these rules for every top-level Codex Security scan workflow before the scan-mode-specific hard rules in that workflow:
+Apply these rules for diff, deep, and resumed legacy Codex Security scans before the scan-mode-specific hard rules in that workflow:
 
 - Keep the phases separate.
 - Follow the execution plan in order.

sdk/typescript/_bundled_plugin/scripts/finalize_scan_contract.py

@@ -1478,6 +1478,32 @@ def _sarif_primary_location(finding: dict[str, Any]) -> dict[str, Any]:
     )
 
 
+def _sarif_locations(finding: dict[str, Any]) -> list[dict[str, Any]]:
+    primary = _sarif_primary_location(finding)
+    locations = [
+        primary,
+        *(location for location in finding["locations"] if location is not primary),
+    ]
+    locations.extend(
+        {
+            "path": evidence["path"],
+            "startLine": evidence["startLine"],
+            "endLine": evidence.get("endLine", evidence["startLine"]),
+            "role": f"evidence:{evidence['id']}",
+        }
+        for evidence in finding.get("codeEvidence", [])
+    )
+    unique: dict[tuple[str, int, int], dict[str, Any]] = {}
+    for location in locations:
+        key = (
+            location["path"],
+            location["startLine"],
+            location.get("endLine", location["startLine"]),
+        )
+        unique.setdefault(key, location)
+    return list(unique.values())
+
+
 def _github_primary_location_line_hash(
     finding: dict[str, Any],
     source_root: Path | None,
@@ -1579,23 +1605,15 @@ def _sarif_result(
     line_hash = _github_primary_location_line_hash(finding, source_root, line_hash_cache)
     if line_hash is not None:
         partial_fingerprints["primaryLocationLineHash"] = line_hash
-    primary_location = _sarif_primary_location(finding)
-    related_locations = [
-        _sarif_location(location, index)
-        for index, location in enumerate(finding["locations"])
-        if location is not primary_location
-    ]
     result = {
         "ruleId": finding["ruleId"],
         "ruleIndex": rule_index,
         "level": SARIF_LEVELS[finding["severity"]["level"]],
         "message": {"text": finding["summary"]},
-        "locations": [_sarif_location(primary_location)],
+        "locations": [_sarif_location(location) for location in _sarif_locations(finding)],
         "partialFingerprints": partial_fingerprints,
         "properties": properties,
     }
-    if related_locations:
-        result["relatedLocations"] = related_locations
     return result
 
 

sdk/typescript/_bundled_plugin/skills/attack-path-analysis/SKILL.md

@@ -16,6 +16,12 @@ If the user explicitly provides a different path for a required input or output,
 If a required input is still missing, stop and ask the user for it before continuing.
 Use the shared scan artifact path conventions in `../../references/scan-artifacts.md`.
 
+### Compact Standard-Scan Mode
+
+When `$security-scan` explicitly invokes this skill in compact standard-scan mode, load the per-scan threat model and the enriched `<discovery_dir>/candidate_ledger.jsonl`. Analyze, in one invocation, every row whose validation disposition is `reportable` or `deferred`. Add one nested `attack_path` record to each row that enters the phase, using the compact record shape in `../../references/scan-artifacts.md`, while preserving every discovery and validation field and the original row order.
+
+In this mode, the nested record replaces the per-finding attack-path report and receipt. Rewrite the ledger atomically. Keep attack-path facts, counterevidence, severity calibration, and policy adjustment as separate reasoning steps even though their output is compact. All reachability, instance-preservation, and evidence requirements still apply; only the artifact packaging changes.
+
 ## Workflow
 
 1. 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.
@@ -31,9 +37,9 @@ Use the shared scan artifact path conventions in `../../references/scan-artifact
 4. 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.
 5. Calibrate impact and likelihood from the repository evidence.
 6. Apply a separate final policy-adjustment pass mechanically using those facts and the calibrated severity.
-7. Drop any candidate whose final policy decision is `ignore`.
-8. Save that finding's visible attack-path report to its per-finding attack-path analysis report path from `../../references/scan-artifacts.md`.
-9. Append one attack-path receipt per candidate id to that finding's candidate ledger path 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.
+7. Record final policy decision `ignore` explicitly. Outside compact standard-scan mode, drop it from the surviving finding set; in compact mode, retain the ledger row for coverage mapping.
+8. In compact standard-scan mode, add the nested `attack_path` record to every candidate that entered the phase and atomically replace the ledger.
+9. Outside compact standard-scan mode, 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.
 
 ## Scope and Attack Path Checklist
 
@@ -76,6 +82,10 @@ Apply severity and policy calibration using `references/severity-policy.md`.
 
 ## Output Contract
 
+In compact standard-scan mode, use the nested record defined in `../../references/scan-artifacts.md`. Every validation row with disposition `reportable` or `deferred` must receive exactly one attack-path decision. The record is the phase closure for this mode; do not also create a narrative report or receipt.
+
+Outside compact standard-scan mode, use the following report contract.
+
 For each surviving finding include:
 
 - title
@@ -94,13 +104,13 @@ Render attack-path facts using `references/attack-path-facts.md`.
 
 - Prefer repository evidence first, but use network connectivity when it materially helps confirm deployment context, reachable surfaces, or other reportability-relevant facts.
 - Do not invent attack chains that the code does not support.
-- Do not leave candidate coverage implicit. Every candidate finding that reaches attack-path analysis must leave an attack-path receipt in its candidate-ledger path from `../../references/scan-artifacts.md`, even when the final policy decision is `ignore` or the path remains deferred.
+- Do not leave candidate coverage implicit. In compact standard-scan mode, every candidate that reaches attack-path analysis must receive a nested `attack_path` record, even when the final policy decision is `ignore` or `deferred`. In other modes, every such candidate must leave an attack-path receipt in its candidate-ledger path from `../../references/scan-artifacts.md`.
 - 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.
 - 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.
 - Missing public-ingress evidence is not by itself dispositive counterevidence.
 - Keep attack-path analysis, severity calibration, and final policy suppression as separate sub-stages.
 - Use the final policy-adjustment matrix mechanically rather than re-arguing severity from scratch after the facts are set.
-- Save a final visible report for each candidate finding using that finding's attack-path analysis report path from `../../references/scan-artifacts.md`.
+- Outside compact standard-scan mode, save a final visible report for each candidate finding using that finding's attack-path analysis report path from `../../references/scan-artifacts.md`. Compact standard scans use the nested phase record instead.
 
 -- Considerations for attack path --
 - A bug matters if evidence shows an attacker could exploit it.