agent's chain-of-custody log missed the rescan that cleared a finding

TL;DR

If a finding disappears between drafts, the custody log must be able to answer when, by which scan, and on whose run. A rescan that clears a finding is an evidence event, and when the agent runs it without logging, the trail shows a finding vanishing for no reason. Log scan events automatically at the runner level, link each finding state change to the event that caused it, and refuse state changes with no event attached.

agent's chain-of-custody log missed the rescan that cleared a finding

Use this when

• A finding was present in an early draft, absent later, and no log entry records the rescan or retest that cleared it.
• The client or a reviewer asks for the history of a specific finding and the log has a gap.

Not for this skill when

• The finding was removed by documented human triage with the rationale logged. That is a proper state change; check the triage log before blaming the rescan path.
• The rescan is logged but under a different finding id after a merge. Trace the merge audit, which is a different trail.

Steps

1. Reconstruct the timeline from artefacts: scan output timestamps, report draft times, and the finding's last-present and first-absent appearances. Verify: Verify: the window in which the clearing rescan happened is narrowed and evidenced by file times.
2. Locate the rescan output itself in the run folders and confirm it shows the condition absent for the same host and check. Verify: Verify: the clearing evidence exists and matches the finding's identity.
3. Backfill the custody log honestly: add the rescan event with its true timestamp, marked as recorded late, and link the finding's state change to it. Verify: Verify: the log now explains the finding's full history without pretending the entry was made on time.
4. Move event logging into the runner: every scan, rescan, and retest invocation writes a log entry with target, tool, options hash, operator or agent run id, and output path, before results are processed. Verify: Verify: a test rescan appears in the log without any manual step.
5. Add the integrity rule: a finding may change state only with a linked event or a signed triage note, and a weekly check lists any state change lacking one. Verify: Verify: a test state change without an event is flagged by the check.

Variant phrasings

finding cleared by rescan missing audit log entry

The symptom phrasing.

runner level scan event logging chain of custody pentest

The design phrasing.

finding state change requires linked evidence event

The integrity-rule phrasing.

Compatibility: Compatibility: any agent scan runner; the log can be an append-only JSONL in the engagement folder with the same retention as results.

Why it happens

Agents log what their designers thought of as deliverables: findings and reports. Rescans feel like internal retries, so they run unrecorded, yet a rescan that clears a finding changes the engagement's conclusions as surely as the original scan created them. Custody breaks at exactly the informal steps, which is why logging belongs in the runner that executes every scan, not in the reporting step that only sees outcomes.

Edge cases / pitfalls

• Backfilled entries must be marked as backfilled; a custody log that hides its own repairs is worse than a gap.
• Clock differences between tester machines can order events wrongly; record timezone-aware timestamps from one source where possible.
• Retain raw rescan output for cleared findings as long as for confirmed ones; a cleared finding is the one most likely to be questioned later.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst2-w7N2lB54jcH89xSRe7A