Do small teams need SonarQube and Trivy in their CI pipeline?
By the Keel team · Last checked · 4 min read
Short answer
A small team does not strictly need SonarQube and Trivy, but each catches a different class of problem cheaply before release. Trivy scans container images, repositories and infrastructure files for vulnerabilities, misconfigurations and secrets. SonarQube applies a quality gate to new code, covering issues, coverage and duplication. Add them in a way that blocks only what matters, so they protect releases instead of slowing them.
80%
New-code coverage the built-in SonarQube quality gate requires
Source: SonarQube docs, Oct 2026
3%
Maximum duplication on new code in the built-in quality gate
Source: SonarQube docs, Oct 2026
What does Trivy check in a CI pipeline?
Trivy checks what you ship for known problems: vulnerabilities, misconfigurations, secrets, licence issues and cryptographic assets.
Its documented targets include container images, filesystems, code repositories, virtual machine images, Kubernetes clusters and SBOMs, and it reads infrastructure files such as Terraform, CloudFormation, Docker and Helm.
For a small team the container image scan is the quickest win. Running trivy image on your image scans for vulnerabilities by default, and you can limit it to that scanner with the --scanners vuln option.
What does SonarQube check in a CI pipeline?
SonarQube measures your code against a quality gate and reports whether it passes or fails.
The SonarQube documentation describes a quality gate as a set of conditions that answers whether your project is ready for release, using measures such as issue counts and ratings, test coverage and duplication.
Its built-in gate looks at new code: no new issues, all new security hotspots reviewed, at least 80% coverage on new code and no more than 3% duplication. On a pull request, only the new-code conditions are evaluated, and the result can be used to block the merge or fail your CI pipeline.
Which of the two catches problems a small team is most likely to have?
Trivy is usually the first to pay off, because every team ships containers built on third-party base images and libraries that pick up known vulnerabilities over time.
SonarQube pays off more as the codebase and team grow, because its value is keeping new code clean as many people change it.
| Trivy | SonarQube | |
|---|---|---|
| Looks at | Images, repositories, infrastructure files, secrets | Your own source code, on new code |
| Finds | Known vulnerabilities and misconfigurations | Code issues, coverage and duplication gaps |
| Best first use | Scan the image on every build | Quality gate on pull requests |
| Pays off most when | You depend on many libraries and base images | More people are changing the code |
How do you add them without slowing releases?
Add them without slowing releases by failing the build only on findings you have agreed matter, and showing everything else as information.
A scanner that blocks every release on low-severity noise will be switched off within a week.
- Start with Trivy on the image your pipeline builds, and fix or accept what it finds first.
- Set the failing threshold by severity, and check Trivy's documentation for how to apply it in your CI tool.
- Add SonarQube's quality gate to pull requests once the team is used to the scan.
- Keep the rest of the pipeline fast so the checks do not become the slowest step.
- Review the settings each month, as in how often to patch AWS production.
Do these tools replace testing and monitoring?
These tools do not replace testing and monitoring.
Scanners catch known classes of problem before release; they do not prove your product works or tell you when it stops working. You still need automated tests, health checks and a way to undo a bad release.
On Amazon ECS the deployment circuit breaker can roll a failed deployment back, and automatic ECS rollback from GitHub Actions shows the setup. Pair that with monitoring that reaches a person so what scanners miss is still caught.
What should you do with the findings?
Fix what is critical or actively exploitable straight away, schedule the rest and accept the remainder in writing with a reason.
A finding with no owner and no date is the same as no scan.
Keep a short record of what was found, what was fixed and what was accepted. It helps in customer security reviews, as in how to answer an enterprise security questionnaire, and in investor due diligence, where evidence of routine checks counts for a lot.
Can a very small team get this set up without hiring?
A very small team can get this set up without hiring through Keel's Startup programme, a foundation-level service for small teams already live with paying customers.
It includes a deploy pipeline with rollback, tested backups, monitoring and monthly patching in your own AWS account, and it connects with Slack, Trivy, SonarQube and Grafana.
It is for teams of fewer than 5 at pre-seed to Series A, live in production with at least one paying customer, on AWS with code on GitHub or GitLab. Places are limited and awarded on merit. If that sounds like you, apply for a place in the pricing section.
Is your pipeline checking what you ship?
Tick each item that is true today.
- Container images are scanned on every build.
- The build fails only on findings you have agreed matter.
- Pull requests get a quality check on new code.
- Every finding has an owner and a date.
- Scans sit alongside tests, health checks and rollback.
- A short record shows what was found, fixed and accepted.
Decision point: Five or six ticks: the pipeline is a real safety net. Three or fewer: start with an image scan on every build.
Sources
- SonarQube Server docs, Introduction to quality gates (checked October 2026)
- Trivy docs, Scanner coverage (checked October 2026)
- Trivy docs, Container image scanning (checked October 2026)
- AWS docs, How the Amazon ECS deployment circuit breaker detects failures (checked October 2026)
Keep reading
Keel is an AWS release and recovery operations service for SaaS teams of 3 to 15 developers, provided by Bargainn Services Ltd, a UK company registered at Companies House (16497746). Registered office: 3rd Floor, 86-90 Paul Street, London, EC2A 4NE, United Kingdom.