Trivy, Semgrep, Checkov, or ZAP: Which Security Gate Fits the Change?

Security review gets messy when every agent-made change is pushed through the same gate. A container image change, a Python code change, a Terraform change, and a new API route do not fail in the same way. They need different evidence, and reviewers need that evidence before a change reaches production.

In Short

Do not ask one scanner to answer every security question. Use Trivy when an agent changes container images, base images, operating system packages, or dependency surfaces. Use Semgrep when the review is about source code patterns. Use Checkov when the change touches infrastructure as code. Use ZAP when you need dynamic evidence from an API or web surface.

The practical rule is simple: match the gate to the failure mode. Trivy’s documentation describes scanning for vulnerabilities and misconfigurations across artifacts such as container images and repositories. Semgrep’s documentation focuses on code scanning with rules. Checkov’s documentation covers infrastructure-as-code policy scanning. ZAP’s documentation covers web application security testing. Those official scopes are a better guide than a generic security checklist.

Who this is for

This is for teams letting agents propose code, dependency, infrastructure, or API changes while humans still own review. It fits small platform teams, DevSecOps teams, and product engineering teams that want evidence packets instead of vague confidence scores.

It also helps when the same pull request contains more than one kind of change. If an agent updates a Dockerfile, edits application logic, and changes Terraform, the review should not collapse into one pass/fail label. Split the review by surface, keep each gate bounded, and make the approval decision explicit.

Decision path

Start with the changed artifact. If the diff changes a container image, base image, package lockfile, Dockerfile, or deployment artifact, run Trivy first. Ask for a short before-and-after note: new critical findings, findings removed, unfixed items, and whether the finding is in a reachable runtime path. Avoid stale severity theater. The useful question is whether this change makes the deployed artifact riskier.

If the diff changes application code, run Semgrep with the team’s normal rules. Ask the agent to separate new findings from pre-existing findings, then explain the changed lines that triggered each rule. Semgrep is most useful when the reviewer can connect a result to a pattern in the patch, such as unsafe deserialization, injection risk, secret handling, auth bypass patterns, or framework-specific misuse.

If the diff changes Terraform, Kubernetes manifests, cloud policies, or other infrastructure definitions, run Checkov before deployment. The review packet should name resource identifiers, changed permissions, network exposure, encryption settings, and skipped checks. A skipped check is not automatically wrong, but it needs a reason that a human can approve.

If the diff changes a live API, authentication path, form flow, or web behavior, add ZAP after a test environment is available. Static checks can miss runtime behavior. Ask for the target URL, scan mode, authenticated or unauthenticated scope, high-confidence alerts, and routes that were not covered. Keep ZAP results tied to a staging target, not a fake screenshot or invented dashboard.

When a change spans surfaces, run more than one gate. The decision path is not a tournament where one tool wins. It is a routing map for getting the right evidence to the reviewer.

Recommended ASE skills

Use the required ASE skills as the first review stack for this topic:

• Trivy Container Image Vulnerability Scanner for image, dependency, and artifact risk checks.
• Semgrep SAST Scanner Skill for source-code rules tied directly to changed lines.
• Checkov Infrastructure Policy Scanner for Terraform, Kubernetes, and cloud policy review.
• OWASP ZAP API Security Auditor for runtime API and web behavior checks in a controlled target.
• Gitleaks Git Repository Secret Scanner for catching credentials introduced in code, configuration, or generated files before the change advances.

What to watch

Watch for agents treating scanner output as the decision. A scanner produces evidence; it does not own the release call. Require the agent to summarize what changed, what the gate found, what stayed uncertain, and what a human must approve.

Watch for noisy inherited findings. If a repository already has a backlog, the review packet should isolate new findings introduced by the current change. Otherwise every review becomes a backlog meeting, and the actual change gets less attention.

Watch for weak scope. ZAP against the wrong environment, Checkov against generated manifests instead of the source Terraform, Semgrep without the team rules, or Trivy without the built image can all create false comfort. The packet should state exactly what was scanned.

FAQ

Should every pull request run all four gates?

No. Run the gates that match the changed surfaces. A documentation-only change does not need a dynamic API scan, while a new authenticated API route probably needs more than a code scan.

What if the tools disagree?

They usually answer different questions. Treat disagreement as a routing clue: identify which artifact each tool inspected and which risk it can actually see.

Can agents fix the findings automatically?

They can propose fixes, but keep approval separate. Ask for the original finding, the changed lines, the rerun result, and any behavior that still needs manual review.

What should block release?

New critical image risk without an approved exception, new high-confidence unsafe code patterns, infrastructure exposure or privilege expansion, and runtime API findings on changed routes should block release until reviewed.