Aqua's built-in reports are too generic for tracking SLA breaches. I needed a custom vulnerability aging report for compliance. Here's how to pull the data via their API and structure it.
First, get a list of images with vulnerabilities older than your threshold (e.g., 30 days). Use the `/risks/vulnerabilities` endpoint with a filter.
```bash
curl -X GET "https:///api/v2/risks/vulnerabilities"
-H "Authorization: Bearer $TOKEN"
-H "Content-Type: application/json"
--data-raw '{
"filters": [
{"field": "date", "operator": ">", "value": "30d"},
{"field": "resource_type", "operator": "=", "value": "image"}
]
}'
```
Parse the response, then for each image, fetch its details and the specific vulnerability history. Key fields:
* Image name & registry
* CVE ID
* Severity
* First discovered date (`discovered_date`)
* Fix status
I pipe this into a simple script that calculates the age and outputs CSV. The API paginates, so handle `next_page` tokens. This gives you a clear list to pressure engineering teams with. -dk
Trust but verify, then don't trust.
Nice! I've been wrestling with similar compliance reports and the `discovered_date` field is a lifesaver for aging. One thing I ran into: that filter you wrote for `"field": "date"` might actually be pulling the *detection* date in your current scan, not the *first* discovered date in Aqua's history. I had to cross-reference with the `/images` endpoint to get the accurate timeline.
Also, when handling pagination, watch out for rate limits if you have a big backlog. I ended up adding a small sleep in my script between page requests. What's your typical batch size for these reports?
Data nerd out
You're absolutely right about that date field - I made the same mistake initially. The detection date resets on every scan, which completely throws off aging calculations for vulnerabilities that were previously fixed and reappeared. I ended up building a small lookup table from the audit logs to track the true first discovery timeline.
For pagination, I keep batches at 100 items and throttle to one request per second. Even then, we occasionally hit limits during monthly compliance runs because our registry is huge. The API team suggested using the async export endpoints for datasets over 10k records, but that adds complexity with job polling.
The right tool saves a thousand meetings.
Ah, the audit log workaround. Clever. I tried something similar but ran into retention issues - our logs only go back 90 days, which makes "true first discovery" a bit of a guessing game for older images.
The async export is a double-edged sword. Sure, it handles volume, but you're trading rate limits for job status hell and eventual consistency. I've had exports finish with data that's already 20 minutes stale, which is just fantastic for compliance deadlines.
Data over dogma.