Describe the bug
detections/cloud/aws_ecr_container_scanning_findings_low_informational_unknown.yml returns zero results even against its own attack data, which genuinely contains matching LOW/INFORMATIONAL severity findings.
Root cause: the final stats command groups by several CIM-aliased field names that nothing in the search actually creates:
| stats count min(_time) as firstTime max(_time) as lastTime
BY signature dest user user_agent src vendor_account vendor_region vendor_product finding_name finding_description imageDigest repository
signature, dest, user, user_agent, src, vendor_account, vendor_region, and vendor_product are only populated if the Splunk Add-on for AWS's CIM field aliasing is applied on top of aws:cloudtrail events - nothing in this search's own pipeline extracts them (unlike finding_name/repository/etc., which are properly renamed earlier in the same search). Since stats BY drops any row where a groupby field is completely undefined, every row gets silently dropped even though the severity filter matched real findings.
Verified directly: I replayed the search's own attack data (aws_ecr_scanning_findings_events.json) into a bare Splunk instance and confirmed:
- The
mvexpand/spath/severity-filter chain alone correctly returns matching LOW findings.
- After the
rename/stats stages, all 8 of the fields above (signature, dest, user, user_agent, src, vendor_account, vendor_region, vendor_product) are completely undefined - confirmed via fillnull value="MISSING" on those fields.
- This is exactly why
contentctl test reports 0 results / test failure for this detection.
Expected behavior
The detection should return the matching low/informational/unknown severity ECR scan findings that are genuinely present in its own test data.
Screenshots
N/A
App Version:
- ESCU: current
develop as of this report (detection version: 13)
Additional context
Suggested fix - extract the actual raw CloudTrail fields instead of relying on unavailable CIM aliases:
| search severity IN ("LOW", "INFORMATIONAL", "UNKNOWN")
| rename name as finding_name, description as finding_description, requestParameters.imageId.imageDigest as imageDigest, requestParameters.repositoryName as repository
- | rename user_name as user
+ | rename userIdentity.arn as user, userAgent as user_agent, sourceIPAddress as src, awsRegion as vendor_region, userIdentity.accountId as vendor_account, eventName as signature, responseElements.registryId as dest
+ | eval vendor_product="Amazon Web Services"
| stats count min(_time) as firstTime max(_time) as lastTime
BY signature dest user
user_agent src vendor_account
vendor_region vendor_product finding_name
finding_description imageDigest repositoryI verified this fix produces the expected results against the detection's own attack data (multiple LOW/INFORMATIONAL CVE findings correctly returned, with user, src, vendor_region, etc. all populated). Happy to open a PR with this fix once my CLA is processed - filed as an issue in the meantime so the bug is tracked and the fix is available for maintainers if useful sooner.
Describe the bug
detections/cloud/aws_ecr_container_scanning_findings_low_informational_unknown.ymlreturns zero results even against its own attack data, which genuinely contains matchingLOW/INFORMATIONALseverity findings.Root cause: the final
statscommand groups by several CIM-aliased field names that nothing in the search actually creates:signature,dest,user,user_agent,src,vendor_account,vendor_region, andvendor_productare only populated if the Splunk Add-on for AWS's CIM field aliasing is applied on top ofaws:cloudtrailevents - nothing in this search's own pipeline extracts them (unlikefinding_name/repository/etc., which are properlyrenamed earlier in the same search). Sincestats BYdrops any row where a groupby field is completely undefined, every row gets silently dropped even though the severity filter matched real findings.Verified directly: I replayed the search's own attack data (
aws_ecr_scanning_findings_events.json) into a bare Splunk instance and confirmed:mvexpand/spath/severity-filter chain alone correctly returns matchingLOWfindings.rename/statsstages, all 8 of the fields above (signature,dest,user,user_agent,src,vendor_account,vendor_region,vendor_product) are completely undefined - confirmed viafillnull value="MISSING"on those fields.contentctl testreports 0 results / test failure for this detection.Expected behavior
The detection should return the matching low/informational/unknown severity ECR scan findings that are genuinely present in its own test data.
Screenshots
N/A
App Version:
developas of this report (detectionversion: 13)Additional context
Suggested fix - extract the actual raw CloudTrail fields instead of relying on unavailable CIM aliases:
| search severity IN ("LOW", "INFORMATIONAL", "UNKNOWN") | rename name as finding_name, description as finding_description, requestParameters.imageId.imageDigest as imageDigest, requestParameters.repositoryName as repository - | rename user_name as user + | rename userIdentity.arn as user, userAgent as user_agent, sourceIPAddress as src, awsRegion as vendor_region, userIdentity.accountId as vendor_account, eventName as signature, responseElements.registryId as dest + | eval vendor_product="Amazon Web Services" | stats count min(_time) as firstTime max(_time) as lastTime BY signature dest user user_agent src vendor_account vendor_region vendor_product finding_name finding_description imageDigest repositoryI verified this fix produces the expected results against the detection's own attack data (multiple
LOW/INFORMATIONALCVE findings correctly returned, withuser,src,vendor_region, etc. all populated). Happy to open a PR with this fix once my CLA is processed - filed as an issue in the meantime so the bug is tracked and the fix is available for maintainers if useful sooner.