Zeek event-driven testing reduces reliance on PCAPs

At a glance

What this is: This is a Corelight walkthrough on testing Zeek packages by hand-raising events or replaying event traces when a PCAP is unavailable or cannot be shared.

Why it matters: It matters because security engineers and detection teams need reproducible test paths that preserve privacy, support edge cases, and validate logic without depending on raw packet captures.

Context

Zeek package testing often breaks down when the logic you want to validate depends on network traffic that is unavailable, sensitive, or too awkward to reproduce safely. In those cases, teams need a way to exercise the code path without relying on a live capture or on traffic that cannot be shared.

The practical problem is not just convenience. Security analytics, detection content, and protocol-aware packages all need deterministic inputs, but those inputs can be expensive to stage and hard to sanitise. Manual event generation and event traces are two ways to preserve testability without making the capture itself the test dependency.

Key questions

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. The key is to recreate the handler inputs the package actually consumes, then compare the resulting log output with a stable baseline. That gives you repeatable tests without requiring the original packet capture.

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. IP addresses and MAC addresses often need replacement, but ports, strings, and protocol fields should only change if the package does not rely on them. Sanitisation must preserve test meaning while removing unnecessary exposure.

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. Use event traces when a real capture already exists and you want to preserve the observed sequence with less reconstruction effort. The choice depends on whether fidelity or construction speed matters more.

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.

Technical breakdown

Hand-crafted Zeek events for isolated package tests

Zeek event handlers can be invoked directly, which means a test can queue the exact event your package consumes instead of waiting for live traffic to generate it. The main work is constructing the required records, such as conn_id, endpoint, and Conn::Info, with enough fields populated for the package logic to run. This approach is useful when only a small slice of the event payload matters and the rest can be stubbed. It also forces the test writer to understand the package contract, which is valuable when the runtime dependency is hidden behind Zeek scripting abstractions. See the Penetration Test Scoping Checklist.

Practical implication: Use direct event construction when you need deterministic tests for a narrow code path and cannot rely on packet replay.

Event traces as replayable runtime state

Zeek event tracing records the events a capture produced and turns them into a script that can be run again to reproduce the same event sequence. That removes much of the manual record-building effort, but it introduces a new responsibility: sanitising the trace before it enters source control or shared test suites. In practice, an event trace is a replayable model of runtime state, not just a log. It is only as safe and useful as the data you leave in it, and the trace can also be edited to create corner cases the original capture did not provide. See the NDR Guide.

Practical implication: Use event traces when you need realistic coverage quickly, then scrub sensitive fields before treating the trace as a reusable test asset.

Why Zeek test data needs controlled anonymisation

The article shows that sanitising a trace is not a mechanical search-and-replace exercise. IP addresses, MAC addresses, ports, and protocol-specific strings may all carry different levels of sensitivity depending on the package logic and the surrounding environment. If you anonymise too aggressively, you can break the behaviour you meant to test. If you anonymise too lightly, you risk exposing identifiers or other sensitive artefacts. The correct balance depends on whether the test depends on the exact value, the field type, or only the shape of the event.

Practical implication: Treat trace sanitisation as part of the test design, not as a post-processing step detached from the package logic.

NHI Mgmt Group analysis

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.

Sanitised event traces create a better security contract than raw captures. A packet capture is often too sensitive to move freely through engineering workflows, while a trace can preserve the behaviour that matters and strip away unnecessary detail. That makes event traces a strong pattern for security engineering, but only if the team defines what must stay faithful and what can be anonymised. For identity and access teams, the same logic applies to logs and audit trails: preserve the security signal, not the unnecessary exposure.

Trace fidelity is only useful when the package contract is understood. The article makes clear that manually built events require knowledge of the fields the package actually consumes, while the trace approach depends on how Zeek reconstructed the runtime state. This is the same discipline that governs any detection or analytics pipeline: if the input model is unclear, the test will pass for the wrong reason. Practitioners should treat the event schema as part of the control surface, because the test is validating assumptions as much as code.

Developer ergonomics improve when reproducibility is engineered into the workflow. The article’s deeper lesson is that security tooling becomes easier to maintain when inputs can be recreated, traced, and reviewed without operational friction. That reduces dependence on one-off captures and makes edge cases more testable across teams. The practical outcome is better coverage for protocol-aware logic and fewer gaps between unit tests and live-network behaviour.

What this signals

Test reproducibility becomes a security control when captures cannot be shared. Teams that can recreate event-driven behaviour without exposing raw traffic are less likely to stall analysis because of privacy or collaboration constraints. That matters in detection engineering as much as in application testing, because the workflow needs to survive sensitive inputs.

Manual input construction and replayable traces solve different governance problems. One is about precision, the other about scale. Security teams should decide which one governs the test, then standardise the sanitisation and baseline process around that choice.

For practitioners

• 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.
• Preserve the fields that drive package logic Anonymise only what the package does not depend on, because over-sanitising a trace can change the output and make the test validate the wrong behaviour.

Key takeaways

• The article shows that Zeek packages can be tested without a shareable PCAP by either manually firing events or replaying generated event traces.
• The main implementation risk is not the test itself but whether the constructed or traced inputs preserve the fields that drive package behaviour.
• Security teams should treat trace sanitisation and event construction as part of the control design, not as an afterthought.

Related NHI Mgmt Group resources: Penetration Test Scoping Checklist · NDR Guide · MITRE D3FEND Guide

Key terms

• Action Trace: An action trace is the record of what an AI agent or system did during execution, including the sequence of steps, data sources, policy checks, and outcomes. It is the primary evidence used to reconstruct behaviour and prove whether an action stayed within governed scope.
• Manual Event Generation: Manual event generation is the practice of constructing and raising Zeek events directly in a test harness instead of waiting for live traffic. It is useful when only the handler inputs matter, but it requires the tester to understand which fields the package actually consumes.
• Trace Sanitisation: Trace sanitisation is the process of removing or generalising sensitive values from generated test artefacts before they are shared or committed. In network testing, the challenge is to strip identifiers and exposure without altering the data fields that drive the package’s behaviour.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.