Quick Answer
CVE scanning checks your installed npm dependencies against the National Vulnerability Database (NVD) and other advisory sources to find packages with documented security flaws. Trivy is a fast, free, open-source scanner that works on JavaScript apps, Docker images, and filesystems. Running it takes under 60 seconds and can reveal critical vulnerabilities your app is shipping today.
What Is a CVE and Why Should You Care?
A CVE (Common Vulnerabilities and Exposures) is a publicly disclosed security flaw in software. When a vulnerability is found in an npm package - say, a path traversal bug in a file upload library or a prototype pollution issue in a utility package - it gets assigned a CVE identifier like CVE-2024-21538 and a severity score (CVSS) from 0 to 10.
The problem for vibe-coded apps is scale. When Bolt, Lovable, or Cursor scaffolds your project, it installs dozens of packages - each of which has its own dependency tree of sub-dependencies. A typical Next.js app has over 1,000 packages in node_modules once you count all transitive dependencies. Any one of them could have a known CVE.
According to Snyk's 2024 Open Source Security report, 84% of all codebases contain at least one vulnerable open-source dependency. Veracode's 2024 State of Software Security report found that 70% of applications have at least one security flaw in an open-source component. For AI-generated apps that install more packages than handwritten apps, the exposure is higher.
GitHub's Dependabot has flagged over 1.5 billion vulnerable dependencies across repositories it monitors. The sheer volume means manual tracking is impossible - automated scanning is the only practical approach.
Why npm audit Isn't Enough
Most developers know about npm audit. It's built into npm, it's fast, and it checks against the npm advisory database. But it has a significant limitation: it only covers vulnerabilities that have been reported to and accepted by the npm security team. The National Vulnerability Database (NVD) and OSV (Open Source Vulnerabilities) database contain CVEs that haven't yet propagated into npm's advisory feed.
Trivy checks against multiple advisory sources simultaneously:
| Source | npm audit | Trivy |
|---|---|---|
| npm Advisory Database | Yes | Yes |
| National Vulnerability Database (NVD) | No | Yes |
| OSV (Google) | No | Yes |
| GitHub Advisory Database | Partial | Yes |
| Docker image scanning | No | Yes |
| Filesystem scanning | No | Yes |
The result: Trivy frequently finds vulnerabilities that npm audit misses, especially recently disclosed CVEs and vulnerabilities in transitive (indirect) dependencies.
Installing and Running Trivy
# Install Trivy (macOS)
brew install trivy
# Install Trivy (Linux / WSL)
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin
# Scan a JavaScript project directory
trivy fs --scanners vuln .
# Scan with more detail (show all severities)
trivy fs --scanners vuln --severity LOW,MEDIUM,HIGH,CRITICAL .
# Scan only HIGH and CRITICAL (for CI pipelines)
trivy fs --scanners vuln --severity HIGH,CRITICAL --exit-code 1 .
# Scan your package-lock.json directly (faster)
trivy fs --scanners vuln package-lock.json
# Output as JSON for integration with other tools
trivy fs --scanners vuln --format json --output trivy-report.json .
The --exit-code 1 flag makes Trivy return a non-zero exit code when vulnerabilities are found, which fails a CI build. This is how you enforce a policy of "no HIGH or CRITICAL CVEs reach production."
What a Trivy Report Looks Like
A typical Trivy scan output for an AI-generated Next.js app looks something like this:
package-lock.json (npm)
Total: 23 (LOW: 4, MEDIUM: 11, HIGH: 6, CRITICAL: 2)
┌──────────────────────┬────────────────┬──────────┬────────┬──────────────────────────────────────────────────────┐
│ Library │ Vulnerability │ Severity │ Status │ Title │
├──────────────────────┼────────────────┼──────────┼────────┼──────────────────────────────────────────────────────┤
│ axios │ CVE-2024-39338 │ MEDIUM │ fixed │ axios: Server-Side Request Forgery (SSRF) via ... │
│ next │ CVE-2024-46982 │ HIGH │ fixed │ next.js: Cache Poisoning vulnerability in ... │
│ path-to-regexp │ CVE-2024-45296 │ HIGH │ fixed │ path-to-regexp: Backtracking regex can cause ReDoS │
│ cross-spawn │ CVE-2024-21538 │ HIGH │ fixed │ cross-spawn: Regular expression denial of service │
└──────────────────────┴────────────────┴──────────┴────────┴──────────────────────────────────────────────────────┘
The "Status: fixed" column tells you a patched version exists - which means the fix is a package update away. This is the most actionable output from a security scan.
How to Fix CVEs Found by Trivy
Most CVEs found in npm dependencies are fixed by updating the affected package. Here's the workflow:
# See what version fixes a specific CVE
# (check the Trivy output or the NVD page for the CVE)
# Update a specific package to its patched version
npm update axios
# Force-update a nested (transitive) dependency
# that you don't control directly
npm audit fix
# For breaking changes in major versions, update manually
npm install next@latest
# After updates, re-scan to verify CVEs are resolved
trivy fs --scanners vuln --severity HIGH,CRITICAL .
For transitive dependencies (packages installed by packages you depend on), npm audit fix can often resolve them automatically. When it can't - usually because fixing requires a major version bump in a direct dependency - you'll see a "fix available via --force" message. Review the changelog before using --force, as it may involve breaking API changes.
Adding Trivy to Your CI/CD Pipeline
# GitHub Actions workflow snippet
# .github/workflows/security.yml
name: Security Scan
on: [push, pull_request]
jobs:
trivy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run Trivy vulnerability scanner
uses: aquasecurity/trivy-action@master
with:
scan-type: 'fs'
scan-ref: '.'
scanners: 'vuln'
severity: 'HIGH,CRITICAL'
exit-code: '1'
This workflow fails any pull request that introduces a HIGH or CRITICAL vulnerability into the dependency tree. For Vercel deployments, you can add a pre-deploy script in your Vercel project settings that runs the scan before each deployment promotes to production.
How VibeDoctor Scans for CVEs
Tools like VibeDoctor (vibedoctor.io) automatically scan your codebase using Trivy against your package-lock.json and flag CVEs by severity, affected package, and available fix version. Free to sign up.
The key advantage of integrated scanning over running Trivy manually is context: VibeDoctor correlates CVEs with the rest of your security scan - so a CRITICAL CVE in an authentication library is flagged alongside the missing rate limiting and insecure cookies that compound the risk. You see the full picture, not just an isolated vulnerability list.
FAQ
How is Trivy different from npm audit?
Trivy checks more advisory databases (NVD, OSV, GitHub Advisory Database) and scans more artifact types (Docker images, filesystems, container registries). It catches vulnerabilities that haven't yet propagated into the npm advisory feed. For JavaScript apps, using both npm audit and Trivy gives better coverage than either alone.
Should I fix every CVE Trivy reports?
Focus on HIGH and CRITICAL first. LOW and MEDIUM CVEs in dev-only packages or in code paths not reachable from your app are lower priority. Check whether the vulnerable function is actually called in your app - a parsing library with a DoS vulnerability that you never call with untrusted input is lower risk than an authentication library with an auth bypass.
What if there's no fix available for a CVE?
If Trivy shows "will_not_fix" or "affected" (no patched version), your options are: find an alternative package, implement a workaround, or accept the risk if the vulnerable code path is unreachable. Monitor the advisory for when a patch is released and set a calendar reminder to upgrade.
Do Next.js and Supabase have known CVEs?
Both have had CVEs in the past and will have more - as will every active open-source project. Next.js has had multiple CVEs including path traversal and cache poisoning issues. The important thing is to stay on current patch versions. Running Next.js 13.x in 2025 while 14.x is available means missing security patches.
How often should I run CVE scans?
At minimum: on every pull request and before every production deployment. Ideally also on a daily schedule against your main branch, because new CVEs are published constantly - a package that was clean yesterday might have a new CVE today. The GitHub Actions workflow above covers the PR gate; add a scheduled trigger (schedule: cron) for the daily baseline check.