Security
What is Trivy, and How to Deploy It in an Enterprise Data Stack?
Last updated on
May 12, 2026
What is Trivy?
Trivy is a popular open-source container vulnerability scanner that detects vulnerabilities in OS packages and application dependencies for various Linux distributions and package managers. Organizations and enterprises appreciate Trivy for its simplicity, comprehensive scanning capabilities, and ease of integration into CI/CD pipelines. Before using Trivy, teams may have struggled with less effective or more complex security scanners, but after implementation, they find it to be one of the most useful and least cumbersome tools in the space. Trivy's ability to scan running workloads, store vulnerability reports as Custom Resource Definitions (CRDs) in Kubernetes, and provide detailed results has made it a preferred choice for many DevOps professionals seeking to enhance their container security practices.
Why is Trivy better on Shakudo?
While it's an excellent tool on its own, deploying and managing Trivy within your organization can be complex and time-consuming. That's where Shakudo comes in.
Our platform seamlessly integrates Trivy, allowing you to leverage its robust scanning capabilities without the hassle of manual setup and maintenance. By using Trivy on Shakudo, you get the best of both worlds: the flexibility and transparency of open-source software combined with the ease of use and reliability of a managed platform. Unlike proprietary solutions that may lock you into their ecosystem, Shakudo gives you full control over your data and infrastructure while automating the deployment, updates, and integration of Trivy into your workflows. This means you can focus on addressing vulnerabilities rather than managing the tool itself, ultimately leading to improved security posture and efficiency for your organization.
Why is better on Shakudo?
Core Shakudo Features
Own Your AI
Keep data sovereign, protect IP, and avoid vendor lock-in with infra-agnostic deployments.
Faster Time-to-Value
Pre-built templates and automated DevOps accelerate time-to-value.
Flexible with Experts
Operating system and dedicated support ensure seamless adoption of the latest and greatest tools.
Getting Started & Usage
This page walks through the first practical workflow after Trivy Server is live. The goal is to help a customer team run useful scans quickly without needing deep Trivy internals.
Basic Workflow
- Build or identify the container image you want to review
- Run a Trivy scan from your workstation or CI pipeline
- Review HIGH and CRITICAL findings first, especially those with available fixes
- Patch the base image, dependencies, or configuration, then rescan
Step 1 — Set the Server Address
TRIVY_SERVER="http://trivy.<namespace>.svc.cluster.local:4954"
If you are testing locally through port-forward, replace the value with http://127.0.0.1:4954.
Step 2 — Run Your First Image Scan
trivy image --server "$TRIVY_SERVER" --severity HIGH,CRITICAL ghcr.io/<org>/<image>:<tag>
Start with a narrow severity filter so teams focus on the most actionable issues first.
How to Read the Result
- Total counts show how many findings were detected by severity
- Installed Version tells you what is currently in the image
- Fixed Version tells you which package update resolves the issue when one exists
- A clean scan does not guarantee zero risk; it means nothing matched the active advisory database and enabled scanners
Step 3 — Scan a Local Repository or Filesystem
trivy fs --server "$TRIVY_SERVER" --scanners vuln,secret,misconfig --severity HIGH,CRITICAL .
- This is useful before containerization, especially if you want to catch secrets or risky IaC settings early.
Step 4 — Review Deployment Manifests Before Release
trivy config ./helm ./k8s
Use trivy config for Kubernetes YAML, Helm templates, and Terraform-style files. This is a local/client-side workflow, not a server-side one.
Step 5 — Add Trivy to CI/CD
trivy image --server "$TRIVY_SERVER" --severity HIGH,CRITICAL --exit-code 1 ghcr.io/<org>/<image>:<git-sha>
A common rollout pattern is to fail the pipeline only on HIGH or CRITICAL findings, then review lower-severity findings separately.
Simple Real-World Example
A team builds ghcr.io/acme/inference-service:1.4.2 and scans it before rollout. Trivy reports several HIGH issues in the base image and one CRITICAL package with a fixed version available. The team updates the base image, rebuilds, rescans, and promotes the new image only after the blocking issues are removed.
Adoption Tips
- Begin with image scanning in CI/CD; it usually gives the fastest value
- Add filesystem or repo scanning for developer workflows and pre-commit checks
- Treat ignore rules as exceptions with an owner and review date, not as permanent suppression
- Use server mode wherever multiple teams scan often — it saves time and repeated DB downloads
Shakudo SaaS-first quick start
This section is for customers using Trivy as a managed component inside Shakudo. Start from the Shakudo platform instead of installing or exposing Trivy manually.
1. Access the component in Shakudo
- Sign in to your Shakudo workspace with your organization-approved account.
- Open the workspace or environment where this component is enabled.
- Go to the Applications or component catalog area and select Trivy.
- If you cannot see the component, ask your workspace administrator to confirm that it is enabled for your role and environment.
2. Open the component UI
- Use the Shakudo-provided Open, Launch, or Access action for Trivy.
- Let Shakudo handle authentication, networking, and workspace routing. Avoid using internal service URLs unless your administrator explicitly provides them.
- Confirm that the component opens in the expected workspace before creating or changing resources.
3. Complete a first safe use case
Open the Trivy service or job interface exposed in Shakudo and run a first scan against an approved image, repository, or artifact. Review the vulnerability summary before acting on findings.
- Use a small non-production example first, especially when testing credentials, scans, model calls, or data connections.
- Name the test clearly so other workspace users can recognize it as a first-run validation.
4. Monitor and validate the result
- Check the component UI for run status, logs, traces, scan results, job history, or project activity, depending on the component.
- Return to Shakudo if you need platform-level status, access control changes, or administrator support.
- Record any errors, missing permissions, or unexpected results before retrying with production workloads.
5. Next steps
- Review the use cases, administration, and troubleshooting pages in this knowledge base for deeper examples.
- For production usage, follow your team’s Shakudo workspace policies for credentials, data access, resource limits, and approvals.
