TL;DR: Zeek package authors can use BTest and assert statements to test auxiliary functions, floating-point comparisons, and vector equality when PCAP-based testing is impractical, according to Corelight. The pattern matters because deterministic script-level tests reduce blind spots in security tooling before event-driven packages reach production.
At a glance
What this is: Corelight explains how to unit test Zeek packages with BTest by using assert statements, helper comparisons for floating point values, and vector checks when PCAP-based tests are not practical.
Why it matters: This matters to security practitioners because package reliability depends on deterministic tests for edge cases, especially when detection logic, logging behaviour, or event handling cannot be exercised safely with real traffic.
Context
Zeek package testing gets harder when a small packet capture is not available, cannot be shared, or cannot reproduce the behaviour you need to validate. In those cases, script-level tests become the practical way to verify logic before it reaches production.
The article focuses on a software testing problem rather than an identity governance issue, but the governance lesson still applies: detection logic needs repeatable validation, not just ad hoc manual checks. For teams that rely on network telemetry, network detection and response depends on tests that confirm parsing and event handling behave as expected.
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: Why do floating-point checks fail in security analytics tests?
A: Floating-point checks fail because computed values are often approximate, so exact equality can break even when the result is correct. Security analytics tests should compare values within a tolerance, especially when the code calculates distances, scores, or thresholds that are not mathematically exact.
Q: What should security teams do when a test returns structured output instead of a single value?
A: They should validate each element of the structure and then reduce the result to a single pass or fail decision. That avoids false confidence from partial matches and helps ensure that complex outputs, such as vectors or per-field comparisons, are completely correct.
Q: When is a script-level test better than manual inspection for security tooling?
A: A script-level test is better when the behaviour is deterministic and the goal is to confirm correctness repeatedly across changes. Manual inspection is useful for exploration, but assertions and automated runs are stronger when the code will affect logging, detection, or downstream operational decisions.
Technical breakdown
How BTest supports Zeek package testing
BTest is Zeek’s generic test driver, and the article uses it to run script-based checks without requiring a live packet trace. The key pattern is to place assertions inside zeek_init so the package executes under test at startup, then let BTest surface any failure as a test failure with a clear exit code. This is not a full unit test framework in the Python sense, but it is enough to validate deterministic behaviour in Zeek scripts. Practical implication: use BTest to turn script logic into repeatable checks instead of relying on manual inspection.
Practical implication: Use BTest-driven assertions to make Zeek package behaviour reproducible and fail fast on logic regressions.
Why floating-point comparisons need helper functions
The article highlights a common testing problem: direct equality checks on floating-point values can fail because of precision limits, even when the underlying calculation is correct. The double_equal helper compares the absolute difference between two values against a tolerance, which is a standard way to test approximate numeric output. In a security analytics context, this matters whenever a package computes scores, thresholds, or distances where tiny rounding differences should not break the test. Practical implication: write tolerance-based comparisons for numeric logic instead of asserting exact equality on doubles.
Practical implication: Use tolerance-based comparisons for computed values so precision noise does not mask correct behaviour.
How vector equality is validated in Zeek tests
Zeek returns a vector of bool when two vectors are compared with ==, so equality is not a single boolean result. The article’s every_T helper reduces that vector to a single pass or fail decision by confirming every element is true. That pattern is useful anywhere a script emits structured values such as arrays or per-field comparisons, because it gives a clean assertion model for complex outputs. Practical implication: wrap vector comparisons in a helper that checks every element before deciding the test outcome.
Practical implication: Validate each element of structured outputs so your test fails only when the data truly differs.
Breaches seen in the wild
- LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Deterministic package testing is a governance control, not a developer convenience. Security tooling that cannot be tested repeatably will drift between intended behaviour and runtime behaviour, especially when logic is hidden in scripts and event handlers. The article shows that Zeek packages can be exercised at the script layer with BTest, which is exactly the kind of control a detection engineering team needs before shipping logic into production. The practitioner conclusion is simple: treat package tests as part of operational assurance, not as optional developer hygiene.
Floating-point test hygiene is a signal of mature detection engineering. When detection logic depends on calculations such as distances, scores, or thresholds, exact equality is often the wrong test. The tolerance helper in the article is a small example of a larger point: analytic systems need tests that match their numeric behaviour, not tests that pretend all computations are exact. The practitioner conclusion is to align test design with the mathematical properties of the code, or risk false failures that erode trust in the pipeline.
Structured-output validation needs explicit helpers because complex return types rarely fail cleanly. Vector comparisons in Zeek do not collapse to a single boolean, so the every_T pattern gives a clear pass or fail result from a compound structure. That is relevant well beyond this example: any security script that emits arrays, field lists, or per-item results needs a consistent way to verify completeness. The practitioner conclusion is to build small validation helpers around structured outputs rather than relying on ad hoc comparisons.
Serviceable detection logic is only as reliable as the test harness around it. The article’s core lesson is that packages used for telemetry and logging need tests even when a PCAP is unavailable or impractical to share. That is a useful reminder for teams running NDR pipelines: assurance has to cover both the parsing logic and the downstream event generation. The practitioner conclusion is to make testability a requirement for any security package that will influence operational decisions.
What this signals
Testability belongs in the security engineering contract. When detection logic can only be verified with a live capture, teams inherit unnecessary operational risk because edge cases are harder to reproduce and harder to defend. The better pattern is to make script-level validation part of the package lifecycle from the start.
Precision-aware testing reduces false confidence in analytic code. Numeric logic in security tooling often looks simple until rounding and representation issues appear at the boundaries. Teams that adopt tolerance-based comparisons early are less likely to mistake a brittle test for a correct control.
Structured validation is the right response to richer telemetry logic. As packages produce more compound outputs, validation helpers need to reflect that complexity rather than flatten it away. That is especially true in detection pipelines where a partial pass can still hide a broken control path.
For practitioners
- Build assertion-based Zeek tests Place deterministic checks in zeek_init and use BTest to execute them on every package change so logic regressions fail immediately.
- Use tolerance helpers for numeric logic Wrap floating-point comparisons in a helper that accepts small precision variance, especially for scoring, distance, and threshold calculations.
- Validate structured outputs element by element Reduce vector or list comparisons to a single pass or fail outcome only after every element has been checked for equality.
- Test package behaviour without relying on PCAPs Create script-level drivers for cases where packet captures are unavailable, sensitive, or too large to keep in test fixtures.
Key takeaways
- Zeek package testing becomes much more reliable when teams replace manual inspection with assertion-driven checks that run automatically.
- Floating-point and vector comparisons need specialised helpers because exact equality is often the wrong test for computed security logic.
- Test harness design matters because detection and logging packages are operational controls, not just code artefacts.
Related NHI Mgmt Group resources: NDR Guide · Log Management and Retention Guide · Windows Forensic Artefacts Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Anomalies and Events | The article is about validating detection and event generation logic in a security tool. |
| Recommendation — Use DE.CM-01 to verify that telemetry and detection logic are producing the events you expect. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | The post centres on testing log and event output from security tooling. |
| Recommendation — Test audit-log generation paths so log-producing code fails fast when expected events do not appear. | ||
| MITRE ATT&CK | TA0007 — Discovery | The examples are about validating telemetry that supports event detection and analysis. |
| Recommendation — Map the testing workflow to discovery coverage and confirm your sensors still emit usable signals. | ||
Key terms
- BTest: BTest is Zeek’s test driver for running scripted checks against package or script behaviour. It lets authors execute test inputs, compare expected outcomes, and surface failures in a repeatable way without depending on manual inspection or ad hoc validation.
- Assertion Testing: Assertion testing is a method of verifying behaviour by stating conditions that must be true during execution. In security engineering, it is useful for deterministic logic because it turns expected outputs into explicit pass or fail checks that can be automated.
- Floating-point Tolerance: Floating-point tolerance is the permitted difference between two calculated numbers when exact equality is too strict. It is commonly used in tests for scores, distances, or thresholds where representation limits can create tiny differences without indicating a real error.
- Structured Output Validation: Structured output validation is the practice of checking multi-value results such as vectors, lists, or per-field records instead of single booleans. It matters in detection and analytics code because complex outputs need element-level verification before a test can be considered reliable.
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.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org