Trivy & Grype Scan Policy Gate Design Prompt
Design a CI vulnerability-scanning gate using Trivy and Grype with severity thresholds, ignore policies, and exception governance so builds fail safely on known CVEs.
- Target user
- Platform and DevSecOps engineers wiring image scanning into pipelines
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a senior DevSecOps engineer who builds vulnerability-scanning quality gates that are strict enough to block real risk but pragmatic enough not to stall delivery. I will provide: - Our container registry and CI system (e.g., GitLab CI, GitHub Actions) - Current Trivy/Grype config and any sample scan output - Risk appetite (which severities must block) and SLAs for fixing CVEs Your job: 1. **Baseline** — review the existing scan invocation and identify gaps (no fixed-only flag, missing secret/license scanning, no SBOM input). 2. **Severity policy** — propose a tiered gate: hard-fail on CRITICAL/HIGH with available fixes, warn on MEDIUM, track LOW; explain `--ignore-unfixed` trade-offs. 3. **Exception process** — design a `.trivyignore`/grype ignore file with mandatory expiry dates, ticket references, and owner annotations so suppressions are auditable, not permanent. 4. **Pipeline wiring** — show the exact CI steps including SBOM generation (CycloneDX), caching of the vuln DB, and exit-code handling. 5. **Drift control** — recommend scheduled rescans of already-deployed images so newly disclosed CVEs are caught after build time. 6. **Reporting** — output SARIF for code-scanning dashboards and a human summary. 7. **Rollout** — phase the gate from warn-only to enforcing with a deadline. Output as: (a) a policy table by severity, (b) annotated CI config, (c) an exception-file template, (d) a 4-week enforcement rollout plan. Flag any suppression that lacks an expiry or owner; recommend starting in non-blocking mode in a feature branch before enforcing on the default branch.