Your build passed. The scanner found issues.

When you first add a scanner to a CI pipeline, the temptation is to run it in observation mode — collect findings, publish a report, then decide later which ones to enforce. This is the right first step. The mistake is never moving to the second step.

A scanner running with exit-code: '0' (or its equivalent) always returns success, regardless of what it found. The build turns green. The PR merges. The findings land in a dashboard that nobody checks until something breaks in production.

Enforcement means the scanner returns a non-zero exit code when findings at or above a specified severity are present. The CI runner interprets that as a failed step. The build stops. The PR cannot merge until the issue is resolved or explicitly accepted.

The difference is one character. Setting exit-code: '1' in the Trivy GitHub Action causes the step to fail — and therefore block the workflow — any time a finding at the configured severity is present. The exit-code: '0' default is intentional: Trivy ships conservative defaults so it never breaks a pipeline before a team has had time to triage existing findings. But leaving it at 0 permanently defeats the purpose.

The goal is a threshold that catches real risk without generating enough noise to train engineers to ignore it. A policy that blocks every medium-severity CVE in a typical Node.js app will produce dozens of daily failures — most of them unfixed upstream. Teams respond by disabling the gate or adding blanket suppressions, which is worse than no gate at all.

A practical starting point: gate on CRITICAL only first. Most teams have a backlog of HIGH-severity findings in their existing images that have no fix available yet — blocking on HIGH on day one means an immediate CI failure storm and the first team bypass within a week. Start with CRITICAL, clear the backlog, then expand the gate to HIGH. This is an incremental ratchet, not a cliff edge.

One additional filter: set ignore-unfixed: true in tools that support it. This skips findings where no patched version exists yet — findings you cannot resolve regardless of effort. They should be tracked separately and re-evaluated when a fix ships, but blocking a deployment on an unfixed vulnerability achieves nothing except friction.

A CVE-only gate covers the image layer — known vulnerabilities in OS packages and language dependencies that have been assigned a CVE number and a severity score. It does not cover:

• Host and kernel configuration — a container running as root with --privileged, a Docker daemon API exposed on port 2375, or a host with automatic updates disabled does not have a CVE. It has a misconfiguration. A misconfiguration that gives an attacker the same access as a CRITICAL CVE.
• Internet exposure — a container with a CVE-free image bound to 0.0.0.0 is reachable from the internet. A container with a critical CVE bound to 127.0.0.1 is not. Exposure context is not in the CVE database.
• AI agent and MCP server configuration — an MCP server running with auto-approval enabled, a plaintext API key in .mcp.json, or an unvetted MCP server that has not been audited before being installed will not appear in any vulnerability feed. These are posture findings, not CVEs.

A CVE gate is necessary. It is not sufficient. A server that passes Trivy with zero CRITICAL findings can still be one misconfigured port binding away from full compromise.

Keelix adds a second gate layer built around the whole-box posture score — a 0–100 number that aggregates host configuration, container security settings, internet exposure, and AI/MCP agent posture alongside CVE counts. The gate is an exit-code check: if the score falls below a configured threshold, the process exits non-zero and the CI step fails.

This is the pattern described as the monitoring-vs-enforcement two-step: run Keelix in audit mode first to establish a baseline score for your server, then set the threshold just below that baseline and gate on it. The threshold rises incrementally as the team resolves findings — continuous improvement, not a cliff edge on day one.

The fail-on: critical flag mirrors the CVE-gate pattern — any CRITICAL finding fails the step. The min-score: 70 adds the posture dimension: a server with no critical CVEs but a collapsed score (exposed Docker API, privileged containers, auto-approved MCP servers) will still fail the gate. Raise the threshold as your team ships fixes.

An MCP server configured for auto-approval, a plaintext secret in the agent config file, or a container running as root are not vulnerabilities in the CVE sense — they carry no CVE ID, no CVSS score, and no NVD entry. They will not appear in Trivy, Grype, or Docker Scout results. They will still compromise your server.

The posture gate catches them because it operates at the level of running configuration, not image content. The Keelix scan runs on the box itself, inspects the live state — which MCP servers are running, what permissions they have, what secrets are stored unencrypted — and rolls that into the posture score. When the gate fires on a score below threshold, the reason might be a CVE. It might also be a misconfigured AI agent that no image scanner would ever find.

Every security scanner that supports CI gating uses the same Unix convention: exit code 0 = success (no findings at threshold); exit code 1 = findings found (fail the step); exit code 2 = scan error (configuration, network, or auth failure — also fails the step, for different reasons). Your CI runner — GitHub Actions, GitLab CI, CircleCI, or any POSIX shell — interprets any non-zero exit code as a failed step and halts the pipeline at that point.

If your scanner is returning exit code 0 every time, either there are genuinely no findings at the configured severity, or you have explicitly configured it to always return 0 (the Trivy default). Check the exit-code / exit-on-severity /fail-build parameter for your specific tool. The parameter name varies; the behaviour is universal.