TL;DR: Historical logs can expose Zeek package regressions that short PCAP-based tests miss, according to Corelight. Long-run replay helps catch cleanup, timing, and state bugs before they return in production.
Editorial analysis by NHI Mgmt Group, based on content published by Corelight: “The Cure for Exceptional Zeek Package Testing (Part 3)”.
Key questions
Q: Why do replay-based tests sometimes reveal bugs that PCAP-based tests do not?
A: PCAPs replay a moment in traffic, while logs can replay the operational history that built up the failure.
Q: What should teams do when a security script only fails after weeks or months in production?
A: Treat the incident as a test coverage gap and reconstruct the failure using the most representative logs available.
Q: How can security teams test detection logic against failures that only appear after long runtime?
A: Use historical log replay to drive the same code paths repeatedly, then compare behaviour across early and late runs.
Practitioner guidance
- Build replay tests from historical logs Convert representative conn logs into deterministic test inputs so edge cases can be re-run after every script change without waiting for live traffic to reproduce them.
- Preserve raw logs for regression analysis Keep uncompressed, representative telemetry sets that capture rare states, unusual field values, and long-duration behaviour that short PCAPs do not expose.
- Separate state cleanup from single-event validation Design tests that check both the correctness of one event and the behaviour of accumulated state across many events, especially where timers or tables are involved.
Bottom line: Log-driven testing exposes failures that only appear after a package has accumulated state over time, which is why short PCAPs can miss them.
Glossary terms: Input Framework, Longitudinal Analysis, Regression Test, Temporal Drift
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Log replay is a stronger regression control than packet capture when failure depends on time and state. The article shows that some detection or parsing bugs only appear after weeks or months of accumulated behaviour, not in short synthetic tests. That is a governance problem as much as a testing problem, because confidence in the script is being built on an incomplete sample of its operating conditions. Teams should treat historical telemetry as part of their quality assurance baseline, not as an ad hoc debugging aid.
A question worth separating out:
Q: How should teams govern time-dependent state in detection or parsing pipelines?
A: Assume that stateful security logic can fail when execution time, cleanup timing, or input pacing differs from production. Govern those components with explicit teardown checks, long-run replay, and validation against accumulated data so the control is assessed as a lifecycle, not a one-off function.
👉 Read our full editorial: Zeek log-driven testing exposes regressions that PCAPs miss