Adding Trivy to Tabeer.ai's GitHub Actions — Scoped to What Dependabot Doesn't Cover

I wrote a whole post arguing Trivy wasn't worth adding to Tabeer.ai's repo, given Dependabot was already covering dependency vulnerabilities and the project has no containers or IaC for Trivy's other strengths to attach to. Trivy is now in the repo's CI. Both things are true, and reconciling them is the actual point of this post — the addition is scoped narrowly enough on purpose that the earlier argument still holds for the part it was actually about.

What Changed: Scope, Not the Argument

The earlier post's case was specific: don't run Trivy's dependency vulnerability scanning duplicate to what Dependabot already does continuously, for free, with zero CI cost. That argument is unchanged and this integration doesn't contradict it — dependency scanning is explicitly turned off. What Trivy adds here is the two capabilities it has that Dependabot doesn't touch at all: secret detection and infrastructure misconfiguration scanning.

- name: Run Trivy (secrets + misconfiguration only)
  uses: aquasecurity/trivy-action@0.29.0
  with:
    scan-type: "fs"
    scanners: "secret,misconfig"
    format: "sarif"
    output: "trivy-results.sarif"
    severity: "CRITICAL,HIGH"
    exit-code: "1"

scanners: "secret,misconfig" is the whole decision, in one line — no vuln scanner, so it never touches the dependency-CVE territory Dependabot already owns.

Verify Locally Before It Ever Touches CI

brew install trivy
trivy fs --scanners secret,misconfig --severity CRITICAL,HIGH .

Clean scan, zero findings, on the first run — worth confirming before wiring this into a required CI check, not after. A workflow that immediately fails on pre-existing findings the first time it runs is a bad first impression and a fast way for a team to start ignoring red CI checks generally.

Wiring the Results Into GitHub's Security Tab

Rather than a check that just passes/fails with no detail, results upload as SARIF to GitHub's native Security tab:

- name: Upload results to GitHub Security tab
  if: always()
  uses: github/codeql-action/upload-sarif@v3
  with:
    sarif_file: "trivy-results.sarif"

if: always() matters — upload the results whether the scan passed or failed, so a finding is visible and actionable in one place instead of only in a raw CI log.

Why This Was Worth Adding at All

Two gaps neither Dependabot nor GitHub's native secret scanning fully close for this project:

• Misconfiguration scanning genuinely has no other coverage here — as the infrastructure grows past a single manually-configured nginx box (if this project ever adopts Docker, Terraform, or Kubernetes manifests), Trivy's config scanner is already wired in and ready, rather than something to bolt on later under time pressure.
• A second, independent secret-scanning pass — belt-and-suspenders isn't redundant when the cost is a few seconds of CI time and the downside of a missed credential leak is real. GitHub's own secret scanning is good; having Trivy check independently, with its own detection rules, catches things a single scanner's blind spots might miss.

The Actual Lesson

"We don't need X" and "we added X" aren't automatically in tension — the real question is always which specific capability of a tool is being added, and whether it overlaps with something already in place. Adding Trivy scoped to secret,misconfig only doesn't undo the earlier reasoning about dependency scanning; it's a different, additive decision that happens to use the same binary. Scope the tool to the actual gap, not to everything it's capable of doing, and two apparently-contradictory calls turn out to both be right.

If you're deciding what security scanning actually earns its place in a CI pipeline versus what would just duplicate existing coverage, get in touch.