JSON key paths longer than 30 characters are silently truncated

[NRGLine4Sec]

The key names come from the log formats (AWS CloudTrail, Entra, Confluent, Okta), so no change to the rules can shorten them. The defect is in the engine, and the report below belongs on quadrantsec/sagan. The 14 affected rules in quadrantsec/sagan-rules cannot match until it is fixed.

A rules-side workaround exists and is deliberately not proposed: naming the key truncated to its first 30 characters does match, because that is what the parser stored. Writing that into the rules would encode the bug and break them the day it is fixed.

---

Issue title

JSON key paths over 30 characters are truncated, so rules naming them never match

Issue body

JSON_MAX_KEY_SIZE is 32 in src/sagan-defs.h, and src/parsers/json.c builds each nested path with:

snprintf(JSON_LOCAL->json_key[json_count], JSON_MAX_KEY_SIZE, "%s.%s",
         JSON_LOCAL->json_key[i], key);
JSON_LOCAL->json_key[json_count][JSON_MAX_KEY_SIZE - 1] = '\0';

so a path longer than that is stored truncated. A rule naming the full path then compares against a name the parser never produced, and the condition can never be satisfied. Nothing is logged: the rule loads, runs, and quietly matches nothing.

Reproduction, against Sagan built from 3b9b0fa:

alert any any any -> any any (msg:"t"; program: test; \
    json_content:".data.authorizationInfo.operation","CreateCloudCluster"; \
    classtype: misc-activity; sid:1; rev:1;)

fed the event

{"data":{"authorizationInfo":{"operation":"CreateCloudCluster"}}}

does not alert. Shortening the path in the rule to its first 30 characters, .data.authorizationInfo.operati, does alert, which shows the stored key is that prefix.

The boundary is exact: a 30-character path matches, a 31-character one does not.
Nesting does not change it, since the whole dotted path counts.

Affected rules in quadrantsec/sagan-rules. Fourteen rules across five products name a key the parser cannot store:

File	Line	SID	Key	Length
aws-cloudtrail.rules	76	5015096	userIdentity.sessionContext.sessionIssuer.userName	50
azure-eventhub-ad.rules	54	5004773	properties.riskLevelDuringSignIn	32
azureEventHub_entra.rules	55	5017933	properties.deviceDetail.isManaged	33
azureEventHub_entra.rules	55	5017933	properties.originalTransferMethod	33
confluent.rules	32, 58, 60, 62	5005921, 5005934, 5005935, 5005936	data.authorizationInfo.operation	32
confluent.rules	36, 38, 42, 44	5005923, 5005924, 5005926, 5005927	data.authenticationInfo.metadata.mechanism	42
confluent.rules	62, 76, 78	5005936, 5005943, 5005944	data.authorizationInfo.superUserAuthorization	45
confluent.rules	78	5005944	data.authorizationInfo.aclAuthorization.permissionType	54
okta.rules	2	5006600	debugContext.debugData.threatSuspected	38

Fifty characters is not an unusual CloudTrail path, so the limit is likely to be met again as cloud rules are added.

Suggested fix
Raising JSON_MAX_KEY_SIZE would cover the paths above; JSON_MAX_OBJECTS is 256 and each entry holds a key and a value pointer, so the cost of a larger bound is modest. Failing that, logging when a key is truncated would at least make the failure visible, since today the only symptom is a rule that never fires.

[NRGLine4Sec]

Following up on this with a measurement, because the workaround in 6211ab5 ("truncate json_content/json_map keys over 31 chars to match engine-stored keys", 2026-08-27) holds for most of the rules it touched but not for all of them, and the six where it does not are still dead.

The distinction

The workaround names the clipped path so the engine's exact strcmp against its own clipped copy succeeds. That works when the clip lands inside the last segment, because the clipped name still addresses the same leaf:

• .data.authorizationInfo.operation is 32 characters, clips to .data.authorizationInfo.operati, and the value is still one lookup away.

It does not work when the clip lands above a further level, because the part of the path that names the value is below the point where the stored key stops:

• .data.authenticationInfo.metadata.mechanism is 43 characters and clips to .data.authenticationInfo.metada, which addresses a point inside metadata. mechanism lives underneath it and nothing reaches it.

Measured

Sagan built from quadrantsec/sagan@3b9b0fa, one reduced rule and one event per row, the event carrying the full nested document as the producer emits it:

Rule names	Event carries	Result
.data.authorizationInfo.operati (clipped, leaf)	data.authorizationInfo.operation	alert
.data.authenticationInfo.metada (clipped, above a level)	data.authenticationInfo.metadata.mechanism	no alert
.data.authenticationInfo.metadata.mechanism (full)	same	no alert

Neither spelling reaches it. Nesting depth on its own is not the cause, so this is about where the clip falls rather than how deep the document goes:

Rule names	Event carries	Result
.a.b	{"a":{"b":"V"}}	alert
.a.b.c	3 levels	alert
.a.b.c.d	4 levels	alert
.a.b.c.d.e	5 levels	alert

Five short levels match; a four-level path whose name exceeds the limit does not.

The six rules

All six use the key as a json_content detection condition, so the condition can never be satisfied and the rule cannot fire.

File	Line	SID	Full path	Length	Clipped to
aws-cloudtrail.rules	77	5015096	.userIdentity.sessionContext.sessionIssuer.userName	51	.userIdentity.sessionContext.se
confluent.rules	38	5005923	.data.authenticationInfo.metadata.mechanism	43	.data.authenticationInfo.metada
confluent.rules	41	5005924	.data.authenticationInfo.metadata.mechanism	43	.data.authenticationInfo.metada
confluent.rules	46	5005926	.data.authenticationInfo.metadata.mechanism	43	.data.authenticationInfo.metada
confluent.rules	49	5005927	.data.authenticationInfo.metadata.mechanism	43	.data.authenticationInfo.metada
confluent.rules	88	5005944	.data.authorizationInfo.aclAuthorization.permissionType	55	.data.authorizationInfo.aclAuth

Lengths count the leading dot, matching the "31 chars" of the commit message.

5005944 also carries .data.authorizationInfo.superUserAuthorization, which is 46 characters but clips inside its last segment, so that one is fine and only the aclAuthorization.permissionType key is unreachable.

Rules at ddr.rules, gcp-cloud-audit.rules and oracle_oci.rules carry clipped paths in the same shape, but only under json_map. Those bind an internal value and nothing else, so the binding is lost while the rule still fires on its remaining conditions. They are a different severity and are not listed above.

Why the corpus cannot fix these

For the other rules the workaround is a rewrite of the key. Here there is no string to write: no spelling of the path addresses a value that sits below where the engine stops storing. They need JSON_MAX_KEY_SIZE raised, or the full path stored and compared on, which is what this issue asks for.

Commenting them out would at least stop them from being counted as coverage they do not provide, but that is a call for the maintainers rather than a change worth proposing here.