Skip to content

Deepen Security finding recording behind one interface - #614

Merged
JacobStephens2 merged 4 commits into
mainfrom
issue-610
Oct 10, 2026
Merged

JacobStephens2 merged 4 commits into
mainfrom
issue-610

Conversation

@JacobStephens2

@JacobStephens2 JacobStephens2 commented Oct 10, 2026 •

Copy link
Copy Markdown
Owner

Summary

Security runs and Security reviews share one recording interface; storage identity, native decoding, and notification metadata stay in the Security finding record module.

record_or_reuse(candidate)
  matching fingerprint → validated existing record
  otherwise → create → validate record + metadata → cache → created record

Security run    → reproduce untriaged records once per fingerprint
Security review → update reproduction only for a created record

Closes #610

Evidence

  • Before: CARGO_BUILD_JOBS=2 cargo test --bin thirdshift repeated_fingerprints_create_one_validated_record failed to compile against the previous record interface (E0599, E0422).
    After: all seven shared-interface tests pass, covering both storage formats, every existing state, preserved Day shift grades/write-ups, safe metadata, lazy historical records, and creation/decoding failures.

  • The Pass adapter test verifies duplicate counters, notification list order, and one reproduction per fingerprint. The CLI scenario verifies ordered existing/new metadata for both storage formats. Existing Security review scenarios pass, including review-to-Security-run handoff.

  • cargo fmt --check — passed.

  • CARGO_BUILD_JOBS=2 cargo clippy --all-targets -- -D warnings — passed.

  • CARGO_BUILD_JOBS=2 cargo test — full suite passed; zero failures, one existing ignored test.

Test seams

  • SecurityRecords::record_or_reuse: typed results, fingerprint reuse, grades, metadata, and failure recovery through advisory/private-issue creation adapters.
  • Security run through the existing Outside Pass adapter: duplicate counts, metadata order, and per-fingerprint reproduction deduplication.
  • Existing Security run and Security review CLI scenarios with real Git and fake gh/Harness: storage/privacy selection, reproduction policy, notification ordering, update reobservation, and review-to-run handoff.

Review coverage

thirdshift-code-review against main: Standards 0 findings; Spec 0 findings. Both axes read all eight changed files. Changed files left unread: none under Standards or Spec.

thirdshift-security-audit guidance review against pinned merge base d2f2faf7fe4a7586d4f15118891a2220791a6736: reviewed all eight changed files and supporting private-record storage, reproduction, fix-publication, and notification code. No introduced Security findings.

Sandboxed, offline validation: cargo test --offline --bin thirdshift github::advisories::tests (7 tests), cargo test --offline --bin thirdshift security::tests (11), cargo test --offline --test security_review (19), and cargo test --offline --test security_run (84); all 121 passed. Tests used local fixtures with external networking disabled.

Unaddressed findings

Standards

None.

Spec

None.

Security

None.

Security review outcome

No unaddressed introduced findings.

Merge Danger

Door: two-way

Reversible refactor; no migration or new grading/disclosure policy.

Blast Radius: Security

Recording for Security runs/reviews and the typed record queries used by fix publication.

Built with codex · gpt-6.1-sol · high

@JacobStephens2
JacobStephens2 merged commit f488b67 into main Oct 10, 2026
17 checks passed
@JacobStephens2
JacobStephens2 deleted the issue-610 branch October 10, 2026 04:53
@JacobStephens2 JacobStephens2 mentioned this pull request Oct 10, 2026
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.

Deepen Security finding recording behind one interface

1 participant