Skip to content

fix: bound resident finding evidence - #161

Open
sylvesterkaczmarek wants to merge 3 commits into
openai:mainfrom
sylvesterkaczmarek:fix/bound-resident-finding-evidence
Open

fix: bound resident finding evidence#161
sylvesterkaczmarek wants to merge 3 commits into
openai:mainfrom
sylvesterkaczmarek:fix/bound-resident-finding-evidence

Conversation

@sylvesterkaczmarek

@sylvesterkaczmarek sylvesterkaczmarek commented Aug 18, 2026

Copy link
Copy Markdown
Contributor

Summary

Make the protected post-job hook reject resident network-finding evidence that the Rust producer cannot emit.

Problem

The Rust resident retains at most 1024 network findings. It also records a truncation flag and a lifetime sampled count with a strict relationship to the retained list.

The Action already independently validates the analogous critical-finding bound, but ordinary findings were only consumed or sliced downstream. A malformed report could therefore present a non-array, more than 1024 retained findings, or an impossible retained/truncated/sample-count combination without failing the protected post hook.

Evidence / reproduction

  • The Rust resident owns a bounded FindingCollection; the reporting path copies its retained list into evidence.findings, copies its truncation state into evidence.findings_truncated, and copies its lifetime sample count into counters.sampled_violations.
  • The producer retains at most 1024 findings. Before that boundary, every sampled finding is retained, so sampled_violations == findings.length. Once the retained list is full, further samples set truncation and increase the sampled count, so valid truncated evidence has exactly 1024 retained findings and sampled_violations > 1024.
  • On the base Action code, the protected report validator independently bounds critical_findings, but it has no equivalent producer-contract validation for ordinary findings.
  • Downstream consumers even use defensive report.findings.slice(0, 1024) in places. That limits presentation work but does not make an impossible report invalid; extra or inconsistent evidence can be silently ignored rather than rejected.
  • Minimal invalid states accepted by the old validation boundary include a non-array findings value, 1025 retained findings, findings_truncated: true with only 1023 retained rows, or a non-truncated list whose sampled count exceeds its retained length.
  • action/finding-evidence-bounds.test.cts pins valid producer boundaries at 0, 1, 1024, and first truncation (1024 retained / 1025 sampled), then verifies those impossible combinations are rejected.

This is the same trust-boundary principle already applied to critical findings: the protected post hook should accept only evidence states the resident producer can legitimately create.

Change

  • enforce the 1024 retained-finding producer bound in the protected post hook
  • require findings_truncated to match the producer state
  • require the sampled count to equal retained findings before truncation and exceed the retained count after truncation
  • validate before DNS correlation, summaries, and structured reporting
  • add boundary regressions for 0, 1, 1024, first truncation, and impossible combinations

No firewall, DNS authorization, or report schema behavior changes.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant