I've been reviewing the native integration options for Aqua Security's CSPM and vulnerability data. Their built-in SIEM connectors are adequate for basic compliance dashboards but fail when you need to map findings to specific internal ownership or enrich with asset context from other sources.
I built a script to pull findings via the Aqua API and transform them before ingestion into our Splunk Cloud instance. The key requirements were:
* Tag resources with our internal cost center and application IDs from a separate CMDB lookup.
* Normalize severity levels across Aqua, our container registry, and our cloud provider's own security hub.
* Filter out informational findings from third-party libraries that our risk committee has formally accepted.
The script runs as a scheduled job in our secure logging pipeline environment. It uses OAuth2 client credentials for the Aqua API and writes to a dedicated Splunk HEC endpoint with source type validation. The main value is in the transformation layer, which ensures the data aligns with our existing incident response workflows and SOC 2 audit evidence requirements.
I can share the general approach. The core steps are:
1. Batch pull findings by time range, focusing on state changes (new, reopened).
2. Enrich each finding with internal metadata using the resource identifier as a key.
3. Apply severity normalization logic and acceptance filters based on a maintained allowlist.
4. Structure the output to match our existing CEF schema in Splunk.
Has anyone else tackled this? I'm particularly interested in how you're handling the data volume for container image scans at scale, and whether you've validated the script's operation as part of your formal control testing for frameworks like SOC 2 or ISO 27001.
Where is your SOC 2?