What this prompt does
This prompt makes the AI build a container image vulnerability management workflow for an organization running [image_count] images across [environment_count] environments. It defines a scanning strategy with [scanner] at [scan_frequency], a prioritization matrix weighing CVSS, exploit availability, exposure, and [business_context], a base-image update policy with [rebuild_triggers] automated via [automation_tool], a remediation issue template with [sla_rules], an exception process requiring [approval_chain] sign-off, a compliance dashboard, and registry retention deleting images older than [retention_days].
The structure works because a scan is only useful if it feeds a real workflow with owners and deadlines. By layering prioritization on top of raw scanning, the prompt focuses remediation on exploitable, exposed vulnerabilities rather than every CVSS-high finding. Tying severity to concrete [sla_rules] and a documented [approval_chain] for exceptions turns scanning from a noisy report into an accountable process. Scaling the workflow to [image_count] images across [environment_count] environments also forces you to think about scanning at build, registry, and runtime rather than a single point-in-time check.
When to use it
- You have scanning in place but no real remediation workflow with owners and SLAs behind it.
- You want to prioritize by exploitability and exposure, not just raw CVSS scores.
- You need a documented base-image update policy with automation for routine rebuilds.
- You need a remediation issue template with severity-based
[sla_rules]for Jira or GitHub. - You require an auditable exception process for vulnerabilities that genuinely cannot be patched.
- You want a compliance dashboard tracking mean-time-to-remediate and SLA adherence.
Example output
Expect a documented workflow rather than a single config file: a scanning strategy across build/registry/runtime, a scoring matrix that ranks findings by CVSS plus exploitability, exposure, and [business_context], a base-image rebuild policy tied to [rebuild_triggers] and [automation_tool], a remediation issue template, an exception-acceptance process gated by [approval_chain], Grafana panel definitions for trends and SLA compliance, and registry retention rules using [retention_days].
Pro tips
- Prioritize by exploitability and network exposure, not CVSS alone; a high-CVSS bug with no exploit and no exposure rarely deserves emergency patching.
- Encode
[business_context]into the matrix — an image handling PII or financial data should outrank an internal tool with the same CVE. - Set
[sla_rules]you can actually meet; aggressive SLAs you routinely miss erode the whole process more than slightly looser ones you hit. - Automate routine base-image rebuilds with
[automation_tool]so the boring updates happen without a human, freeing attention for real triage. - Make the exception process genuinely auditable: require
[approval_chain]sign-off and an expiry on every accepted risk so exceptions do not become permanent. - Use
[retention_days]and untagged-manifest cleanup to keep the registry small, which also shrinks the surface you have to scan. - Scan at every stage your
[scan_frequency]defines — on push, on the registry, and at runtime — because a clean build-time scan does not mean a CVE disclosed afterward is caught. - Track mean-time-to-remediate on the compliance dashboard, not just open-vulnerability counts; the trend tells you whether the workflow is actually working.
