Topic starter
25/10/2026 11:00 am
TL;DR: Manual event generation and event traces give Zeek packages a way to be tested without shareable PCAPs, Corelight says, when the inputs preserve the fields that drive package behaviour. Trace sanitisation and event construction need to be part of the control design so tests stay reproducible.
Editorial analysis by NHI Mgmt Group, based on content published by Corelight: “The Cure for Exceptional Zeek Package Testing (Part 2)”.
Key questions
Q: What is the best way to sanitise a Zeek event trace before sharing it?
A: Start by classifying which constants are sensitive and which are behaviourally important.
Q: When should security teams use manual events instead of event traces?
A: Use manual events when the code path is small, the required fields are few, and you want complete control over the input.
Q: How should teams test Zeek packages when they cannot use a PCAP?
A: Use manual event generation for narrow, deterministic paths and event traces when you need realistic replay.
Practitioner guidance
- Build a manual event harness for narrow Zeek code paths Create helper functions that construct only the fields your package consumes, then queue the exact event handler in zeek_init for deterministic BTest coverage.
- Prefer event traces when you need realistic replay Generate traces from a PCAP, prepend the BTest preamble, and run them as scripts so the test reproduces the original event sequence without rebuilding every record by hand.
- Sanitise trace constants before committing them Review time, string, port, and addr constants separately, then remove or generalise values that could expose identifiers, internal hosts, or other sensitive details.
Bottom line: The article shows that Zeek packages can be tested without a shareable PCAP by either manually firing events or replaying generated event traces.
Glossary terms: Action Trace, Manual Event Generation, Trace Sanitisation
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 days ago by NHI Mgmt Group
27/10/2026 7:17 pm
Event-driven testing is a governance problem, not just a developer convenience. When packet captures cannot be shared, the real issue is whether a security control, detector, or analytic can still be validated under realistic but safe inputs. That is a test-data governance question as much as a coding question. Teams that rely only on live captures create a blind spot between what they can observe in production and what they can safely reproduce in development. The practical conclusion is that testability needs its own control plane.
A question worth separating out:
Q: What is the difference between replaying a trace and constructing events by hand?
A: Hand-built events give you precise control over the inputs and make the test easier to reason about, but they require more scripting effort and deeper knowledge of the data structures. A trace captures more of the original runtime state automatically, which improves realism, but it also brings sanitisation and review requirements.
👉 Read our full editorial: Zeek event-driven testing reduces reliance on PCAPs
This post was modified 7 days ago by NHI Mgmt Group