Container AI Analysis
After a container scan, Vygl runs a one-shot AI analysis that produces a markdown summary: overall risk posture, the few CVEs worth fixing first, and base-image guidance when an upgrade would materially reduce inherited vulnerabilities. The result is cached against the image’s open-finding state, so re-scanning the same image with the same findings returns the cached analysis instantly.
What the summary covers
Section titled “What the summary covers”A typical Container AI Analysis has four sections:
| Section | Content |
|---|---|
| Overall risk | A short paragraph framing the image’s posture — high/medium/low risk and why. |
| Priorities | The 3–5 specific CVEs or packages that should be addressed first, with reasoning. |
| Base image guidance | When the base layer carries a meaningful share of the image’s CVEs, a callout describing the impact of upgrading. The summary names the impact, not a specific target image — confirm a concrete upgrade target before swapping. |
| Remediation steps | Practical next steps — base-image upgrade, package upgrade, removal of unused packages, layer reordering. |
Caching
Section titled “Caching”The analysis is keyed on a hash over the image’s open-finding fingerprints. Re-scanning the same image returns the cached sections blob — no LLM call. New findings (or a digest change that brings new findings) invalidate the cache and trigger re-analysis.
Streaming endpoint
Section titled “Streaming endpoint”If you’d rather see the analysis token-by-token (in the AI Consultation chat or programmatically):
GET /containers/images/ai-analysis/stream?image_ref=...&force=falseReturns a Server-Sent Events stream with each section as it generates. Pass force=true to bypass the cache and re-run the LLM unconditionally.
How prioritization is computed
Section titled “How prioritization is computed”Before calling the LLM, Vygl pre-aggregates findings into a structured summary — severity counts, fixable counts, top vulnerable packages, OS vs application split, trend delta from the previous scan. The model works from this summary plus a fingerprint of the worst findings, not from a raw 200-finding table. This keeps the input small enough to fit in token budgets while still giving the model the data it needs to prioritize.