Skip to content

fix(strix): bind PR source findings to the authenticated exact base→head delta #2159

Description

@seonghobae

Problem

Required Strix review on .github#2106 exact head 611ccd73460ab0188e0085956ade6180bb28a91a reported source findings against scripts/ci/pingora_edge_policy.py and scripts/ci/contextual_orchestrator_review_policy.py as part of that PR review, but neither file is in GitHub's canonical changed-file set for #2106.

This is not a claim that the underlying repository-wide concerns are harmless. It is an evidence-scope defect: a PR security verdict must distinguish an exact base→head delta finding from debt found in unchanged protected-base source.

Executable evidence

Authenticated PR identity:

  • PR: .github#2106
  • base: protected main@64f483db9d052322c65bcdf1675d66138156f306
  • head: 611ccd73460ab0188e0085956ade6180bb28a91a
  • GitHub changed-file inventory: exactly seven paths — codeql-scan-dispatch.yml, CHANGELOG, ADR/doctoring/gap docs, and two CodeQL contract tests. Neither reported source file appears.

Blob identity proves the two reported files are unchanged across the exact tuple:

  • scripts/ci/pingora_edge_policy.py: base blob = head blob = eb0e3a741a93a89c0364af07ff963920d82f9684
  • scripts/ci/contextual_orchestrator_review_policy.py: base blob = head blob = 241f84bef79259087085099f16b86b2580d0d207

Nevertheless Strix job 103684345530 produced findings against both paths and caused the PR review lane to fail.

The Pingora finding has a real canonical owner: #2149. Current #2149 closes quoted image/absolute command/package-option/line-continuation cases but still lacks ARG/ENV variable-indirection coverage; exact-head review 5190657129 records that remaining owner-local finding. Do not repair it in #2106.

The review-policy endpoint finding also needs provenance-aware classification before being called credential exfiltration. The .github launcher copies chat_base_url / credential metadata from CO DiscoveredModel; at the currently proposed CO pin 012beaac…, discovered rows populate chat_base_url and auth_scheme from the code-owned ProviderModelSource, not directly from remote model-list response fields. The leaf bridge still duplicates routing authority and is scheduled for retirement under #1759/#2042, but the Strix report did not establish an attacker-controlled path for this exact execution.

Required owner repair

  1. Before publishing a PR source finding, bind repository, PR number, live open state, exact base ref/SHA and exact head SHA.
  2. Materialize the complete canonical GitHub changed-file inventory for that exact tuple, with rename status and pagination.
  3. A finding presented as a PR-delta finding must map to an authenticated changed path and, where line-level evidence is claimed, to a changed hunk/side. Base-identical paths must not be attributed to the PR delta.
  4. If bounded dependency/context closure legitimately exposes a defect in unchanged source, publish it separately as repository_baseline / context_dependency evidence with explicit provenance. It may remain non-passing if policy requires that, but it must not be described as introduced or changed by the PR.
  5. Preserve security sensitivity: do not narrow the scanner workspace to changed files only. The model may need unchanged dependencies to judge changed code; the repair is evidence attribution, not context starvation.
  6. Fail closed if the authenticated changed-file set, base/head tuple, or finding path provenance cannot be established.
  7. Add deterministic RED fixtures for: changed source finding, unchanged dependency context, completely base-identical source finding, rename, stacked base, and stale-head report.

Acceptance

Replay an unchanged #2106-equivalent seven-path canary. A real defect in one of those seven paths still blocks. The Pingora/review-policy repository-baseline observations may be retained as separate owner debt, but they cannot masquerade as exact PR-delta findings. No synthetic success, source-neutral retrigger, scanner suppression, provider fallback, or branch-protection weakening is acceptance evidence.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions