By Shahid MalikSetting up Dependabot on Tabeer.ai's repo led to the obvious next question: what about Trivy? It's a well-regarded, genuinely capable open-source scanner, and it comes up constantly in "security tooling for your CI pipeline" lists. I didn't add it. Not because it's bad — because almost everything it's actually good at doesn't apply to this specific server, and the part that does overlaps with what Dependabot already covers for free.
What Each Tool Actually Does
Dependabot is GitHub-native, zero infrastructure: a config file (dependabot.yml) telling
it which package ecosystems to watch, and it opens pull requests when a dependency has a known
vulnerability or a new version available. No CI step, no scanning job, no container, nothing
to maintain beyond reviewing the PRs it opens.
Trivy is a scanner you run — typically as a CI step — that checks for vulnerabilities across several different surfaces: container images, filesystem dependencies, Infrastructure-as-Code misconfigurations (Terraform, CloudFormation, Kubernetes manifests), and secrets accidentally committed to a repo. It's broader in scope than Dependabot, and it's the right call for a lot of setups.
Where They Actually Overlap
Filesystem/dependency scanning — Trivy can scan a requirements.txt or package.json for
known-vulnerable versions, which is the exact same job Dependabot is already doing,
continuously, without a CI step. Running Trivy for this specific capability on a repo that
already has Dependabot configured is duplicate coverage of the one thing they're both actually
built to catch, at the cost of a CI job that has to run, has to be maintained, and can fail a
build if a threshold is set wrong.
Where Trivy's Real Value Lives — and Doesn't Apply Here
Trivy's strongest, most differentiated use case is container image scanning: checking a
Docker image for OS-package and application-layer vulnerabilities baked into the image itself,
not just what's declared in a manifest file. That's genuinely valuable — and genuinely
irrelevant to a project with zero Dockerfiles, deploying straight to an EC2 instance via
rsync and systemd units. There's no image to scan. Half of Trivy's actual differentiated
value has nothing to attach to on this kind of setup.
Its second strongest use case is IaC misconfiguration scanning — catching an S3 bucket set
to public, an overly permissive security group, that kind of thing, in Terraform or
CloudFormation before it's ever applied. Tabeer.ai's infrastructure is one manually-configured
EC2 instance with an nginx config and a handful of systemd units — no IaC layer exists for
Trivy to scan, because there's no IaC at all yet.
Its third use case, secret scanning, is already covered natively — GitHub's own secret
scanning does this without adding a separate tool, and the actual practice on this project
(every credential in a chmod 600 env file referenced via EnvironmentFile=, never committed)
is the thing that actually prevents secret leaks, not a scanner that catches them after the
fact.
The Actual Decision Rule
Add a security scanner when it covers a surface you actually have, not because it's a good tool in the abstract. Concretely:
- Just dependency vulnerabilities, no containers, no IaC → Dependabot alone is the right amount of tooling. This is where Tabeer.ai is right now.
- You've containerized (even one service) → Trivy's image scanning becomes genuinely additive, not duplicate, coverage — add it then.
- You've adopted Terraform/CloudFormation/K8s manifests → same logic, add Trivy's IaC scanning at that point, not before.
Running a scanner that duplicates existing coverage isn't neutral — it's a CI job someone has to maintain, a build step that can flake or slow the pipeline, and one more tool's config to keep current, for a category of finding you're already catching. On a small project, that cost is more real than the marginal security benefit. Match the tooling to the actual attack surface, not to what a "recommended security stack" checklist says you should be running.
If you're deciding what security tooling actually earns its place in your CI pipeline versus what's there out of habit, get in touch.