fix(expectations): tolerate null inject_expectation_signatures#315
Merged
Conversation
The platform serializes inject_expectation_signatures as null when an expectation has no computed signatures. The model required a list, so parsing raised a ValidationError that aborted the entire expectation batch fetch in collectors, leaving detection/prevention expectations unprocessed (no alerts matched). Coerce null to an empty list via a before-validator and default the field to an empty list, so a signature-less expectation is parsed instead of crashing the whole batch. Refs: OpenAEV-Platform/collectors#490
|
Thank you for your contribution. This PR is but one step away from being ready for merging: all commits must be PGP-signed. To get started, please see https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits |
There was a problem hiding this comment.
Pull request overview
This PR makes the inject expectation models resilient to inject_expectation_signatures being serialized as null by coercing None → [], preventing a single malformed expectation from aborting batch expectation fetches (per collectors#490).
Changes:
- Default
Expectation.inject_expectation_signaturesto an empty list viadefault_factory=list. - Add a Pydantic
mode="before"field validator to coerceNonesignatures to[]. - Add regression tests covering
null → [], missing key defaulting to[], and preserving provided signatures.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| test/apis/expectation/test_expectation.py | Adds regression tests ensuring inject_expectation_signatures tolerates None/missing and preserves provided values. |
| pyoaev/apis/inject_expectation/model/expectation.py | Implements None → [] coercion and defaults signatures to an empty list to prevent batch parsing failures. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The SentinelOne collector (and any collector polling detection/prevention expectations) stops processing with:
The collector logs
Fetched 0 expectationsand never matches any alert.Ref: OpenAEV-Platform/collectors#490
Root cause
Expectation.inject_expectation_signatureswas declared as a required, non-nullableList[ExpectationSignature]. The platform serializes this field asnullwhen an expectation has no computed signatures. Becauseexpectations_models_for_sourcebuilds every model in a single loop, one such expectation raises aValidationErrorthat aborts the entire batch fetch — so even valid expectations are never returned.Fix
inject_expectation_signaturesnow defaults to an empty list and amode="before"validator coercesnull→[].Tests
null→[], missing key →[], provided signatures preserved.169 passed),black/isortclean, no newmypyerrors on the changed file.Note
This makes the client resilient to
nullsignatures (stops the crash / batch abort). It does not by itself make alerts validate when signatures are genuinely empty — matching requires non-empty signatures, which is a platform-side concern (why signatures are null on the affected environment is being investigated separately).