14% of Breaches Start With a Web App Vulnerability — Run a Scanner Before Attackers Do

The fastest way to run a vulnerability scanner on your deployed apps is to use a platform that runs it automatically on every deployment. Temps uses Trivy (version 0.58.1) to scan your Docker images for known CVEs immediately after each deploy — no extra tooling, no CI/CD configuration, no external API keys required.

According to Verizon's 2024 Data Breach Investigations Report, exploitation of vulnerabilities as the initial access vector tripled year-over-year, accounting for 14% of all breaches. The median time to exploit a vulnerability after disclosure is now just 5 days. Your deployed app — the one running right now — has attack surface you've never inspected.

This guide covers what vulnerability scanners actually check, which tools are worth your time, how to automate scanning in CI/CD, and how Temps handles the whole process without adding operational overhead.

TL;DR: Most web app breaches exploit known, patchable CVEs. Trivy scans your Docker images for vulnerable OS packages and language dependencies in under 10 minutes. Temps runs Trivy automatically on every deployment and daily at midnight UTC, sends email alerts for critical and high findings, and provides a full CVE breakdown in the project dashboard. Vulnerability exploitation tripled as a breach vector according to the Verizon DBIR.

How Do You Run a Vulnerability Scanner on Deployed Apps?

The most effective approach is scanning your Docker images — the actual artifacts you deploy — rather than running external web probes against a live URL. Image scanning catches CVEs in OS packages (Alpine, Debian, Ubuntu) and language dependencies (npm, pip, Go modules, Rust crates) before or immediately after deployment, while the image is still fresh.

Trivy is the standard tool for this. It pulls the image layers, analyzes them against its CVE database, and returns a structured report with vulnerability IDs, affected packages, installed versions, fixed versions, severity levels, and CVSS scores — in under 10 minutes for most images.

The three practical approaches:

1. CI/CD gate: Run Trivy in your pipeline before deployment and fail the build on critical findings
2. Post-deploy scan: Deploy first, then scan asynchronously and alert the team if critical CVEs are found
3. Platform-managed: Use a deployment platform that runs scans automatically without any pipeline changes

Each approach has tradeoffs. CI gating catches issues before they reach production but adds pipeline latency. Post-deploy scanning is non-blocking but requires you to act quickly on findings. Platform-managed scanning is lowest-friction because there's nothing to configure.

What Does Trivy Actually Check?

Trivy scans Docker images at the layer level and reports findings across four categories:

OS Packages

Alpine, Debian, Ubuntu, CentOS, and other Linux distributions include hundreds of packages in a base image. Each package has a version, and each version has a known CVE status. Trivy checks every installed package against its vulnerability database (sourced from NVD, GitHub Advisory Database, and OS vendor advisories) and reports which ones have known CVEs with available fixes.

Language Packages

Application dependencies bundled into the image — node_modules, Python packages, Go modules, Ruby gems, Rust dependencies — are scanned against language-specific advisory databases. A vulnerability in a transitive npm dependency three levels deep will appear in the report.

Severity Levels

Trivy classifies each finding into one of five severity levels:

What Trivy Skips

Trivy deliberately excludes compiled binary results (Go binaries, Rust binaries embedded in the image) from reports. These produce noisy findings from binaries baked into Docker images — for example, Go stdlib CVEs from a Hugo binary — that are unrelated to your project's own code. Temps uses the same filtering.

How Does Platform-Level Scanning Compare to CI/CD Integration?

The main advantage of platform-managed scanning is that results are co-located with deployment history, so you can see exactly which commit introduced a new vulnerability without switching tools.

How to Set Up Trivy in a GitHub Actions Pipeline

If you're not using Temps, here's how to add container scanning to an existing CI/CD pipeline:

Post-Deploy Scan Workflow

# .github/workflows/security-scan.yml
name: Post-Deploy Security Scan
on:
  workflow_run:
    workflows: ["Deploy"]
    types: [completed]

jobs:
  scan:
    runs-on: ubuntu-latest
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    steps:
      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: 'your-registry/your-app:latest'
          format: 'sarif'
          output: 'trivy-results.sarif'
          severity: 'CRITICAL,HIGH'
          exit-code: '1'

      - name: Upload Trivy scan results to GitHub Security tab
        uses: github/codeql-action/upload-sarif@v3
        if: always()
        with:
          sarif_file: 'trivy-results.sarif'

Setting exit-code: '1' causes the workflow to fail when Critical or High CVEs are found. Remove it if you want non-blocking scans that alert without failing.

Scheduled Weekly Scan

on:
  schedule:
    - cron: '0 6 * * 1'  # Every Monday at 6 AM UTC

Filtering False Positives

Go binary and Rust binary results from embedded binaries in Docker images are typically false positives for your own code:

- name: Run Trivy vulnerability scanner
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: 'your-registry/your-app:latest'
    vuln-type: 'os,library'
    skip-files: '/usr/local/bin/hugo,/usr/bin/some-go-binary'
    severity: 'CRITICAL,HIGH,MEDIUM'

How Does Temps Handle Vulnerability Scanning?

Temps includes a built-in vulnerability scanner as part of its deployment platform. It uses Trivy 0.58.1 running as a Docker container on your Temps server.

Automatic Scans on Every Deployment

When you push code and Temps builds and deploys your application, a vulnerability scan runs automatically as a post-deploy step — alongside screenshot capture and source map upload. No configuration required.

Daily Scheduled Scans

A background service runs daily at midnight UTC, scanning every environment that has a current deployment. New CVEs are published constantly; yesterday's clean image can have a known vulnerability today. Daily scans catch this drift.

Triggering a Manual Scan

# Trigger a scan via the Temps CLI
bunx @temps-sdk/cli scans trigger --project-id <id>

# List recent scans
bunx @temps-sdk/cli scans list --project-id <id>

Or via the REST API:

# Trigger a scan
curl -X POST "https://your-temps-instance.com/api/projects/{project_id}/scans" \
  -H "Authorization: Bearer YOUR_TOKEN"

# View latest scan results
curl "https://your-temps-instance.com/api/projects/{project_id}/scans/latest" \
  -H "Authorization: Bearer YOUR_TOKEN"

# View vulnerabilities for a specific scan
curl "https://your-temps-instance.com/api/projects/{project_id}/scans/{scan_id}/vulnerabilities" \
  -H "Authorization: Bearer YOUR_TOKEN"

Scan Results

Each scan returns a structured breakdown: total vulnerability count, and per-severity counts (critical, high, medium, low, unknown). Click into any scan to see individual CVEs with:

• CVE identifier (e.g., CVE-2024-12345)
• Affected package name and installed version
• Fixed version (if available)
• Severity classification
• CVSS score
• References and primary advisory URL

Email Alerts for Critical and High Findings

Temps sends email notifications automatically when a scan finds Critical or High severity vulnerabilities. The email includes the project name, a summary of critical/high/total counts, scanner type and version, branch and commit hash, and a direct link to the full vulnerability report in the dashboard.

Low and Medium findings are recorded and visible in the dashboard but do not trigger email alerts — reducing noise while ensuring high-severity issues are acted on immediately.

What Temps Does Not Scan

Temps scans Docker image contents — OS packages and language dependencies bundled into the image. It does not perform DAST (web application scanning against a live URL), so it will not check HTTP headers, probe for exposed paths, or test API endpoints for injection vulnerabilities. Use Nuclei or OWASP ZAP for DAST alongside image scanning.

Self-Host: No Data Leaves Your Server

On a self-hosted Temps instance, scans run entirely on your infrastructure. Trivy runs as a Docker container using a read-only socket mount (the container cannot write to the Docker daemon), so scan results never leave your server. No external API calls, no scan quotas, no third-party data handling.

Temps is Apache 2.0 and free to self-host.

Which Open-Source Web Scanning Tools Are Worth Using?

Image scanning and web application scanning are complementary. Image scanning catches CVEs in dependencies before attackers can exploit them. Web application scanning tests your live app from the outside for misconfigurations and injection points.

Trivy (Image Scanning)

Trivy is the standard for container image scanning. It scans OS packages, language packages, infrastructure-as-code files, and Kubernetes manifests. Fast, low resource usage, and accurate.

Best for: Docker image CVE detection in CI/CD and on every deployment.

Nuclei (Web App Scanning)

Nuclei from ProjectDiscovery runs community-maintained YAML templates — over 9,000 of them — that check for specific, known issues in live HTTP endpoints.

Best for: Fast, repeatable checks in CI/CD pipelines immediately after deployment.

OWASP ZAP (Dynamic App Scanning)

OWASP ZAP is the most comprehensive open-source DAST tool. It runs as a proxy between your browser and the target app, intercepting and analyzing every request. Resource-heavy — plan for 1–2 GB RAM — but thorough for staging environment scans.

Best for: Deep, thorough scans of staging environments before production deployment.

Mozilla Observatory (Header Check)

Not a scanner you install — it's a free web service that grades your site's security headers and TLS configuration. Focused entirely on HTTP response headers with letter grades and specific fix recommendations.

Best for: Quick header audit on any public URL.

Scanner Comparison

How Do You Integrate Scanning into Your Deploy Pipeline?

The Recommended Stack

1. Trivy in CI — scan your Docker image before pushing to registry, fail on Critical findings
2. Nuclei post-deploy — run template checks against the live URL after deployment
3. Scheduled weekly scans — catch newly disclosed CVEs in your deployed images

Alert on Regression, Not Every Finding

The critical pattern: track your security baseline. If Monday's scan found 3 issues and Tuesday's found 5, something regressed. Store results, diff them, and alert only on new findings. Alerting on every finding on every scan causes teams to ignore the scanner after the first week.

Preview Environment Scanning

If you deploy preview environments for pull requests, scan those too. Catching a security regression before it hits production is far cheaper than patching it after. Run a lightweight Nuclei template check — headers and exposed paths — on every preview deployment. Save the full image scan for the main branch.

Frequently Asked Questions

How often should you run vulnerability scans on production apps?

Run image scans after every deployment and at least daily on a schedule. New CVEs are published constantly; a clean image today can have a known exploit tomorrow. Temps runs scans daily at midnight UTC automatically. According to Qualys, exploitable vulnerabilities remain unpatched for an average of 30.6 days — daily scanning shortens that window significantly.

Do vulnerability scanners cause downtime or break production?

Image scanning (Trivy) is entirely offline — it analyzes image layers without sending any traffic to your running application, so there is zero production impact. DAST tools like OWASP ZAP in active scan mode can cause issues by sending malicious payloads to form inputs and API endpoints. Run active DAST scans against staging environments, not production.

Are free scanners good enough or do you need paid tools?

Free tools cover the essentials well. Trivy is used by major cloud providers and security teams worldwide. Paid tools like Snyk Container and Qualys Web Application Scanning add compliance reporting, SLA-backed support, and proprietary intelligence. For most teams, Trivy plus scheduled automation provides solid baseline coverage at zero cost.

What's the difference between SAST, DAST, and SCA?

SAST (Static Application Security Testing) analyzes source code before deployment. DAST (Dynamic Application Security Testing) tests running applications — tools like Nuclei and ZAP. SCA (Software Composition Analysis) checks your dependencies for known CVEs — Trivy and Snyk do this. For deployed apps, SCA via image scanning gives you the most immediate value because it tests what an attacker would actually exploit.

Does Temps scan automatically or do I need to configure it?

Temps scans automatically — there is nothing to configure. Every deployment triggers a post-deploy Trivy scan. A background service also runs daily at midnight UTC against all deployed environments. Manual scans can be triggered from the dashboard or via the CLI and REST API. Email alerts are sent automatically for Critical and High findings.

Start Scanning Before Attackers Do

The gap between "deployed" and "secure" is where breaches happen. Vulnerability exploitation tripled as a breach vector according to the Verizon DBIR, and the median time to exploit dropped to 5 days after disclosure.

The minimal viable setup: add Trivy to your CI pipeline, fail on Critical findings, and run a weekly scheduled scan. That alone closes the window on the most commonly exploited CVEs.

If you want scanning built into your deployment workflow — running automatically on every push, reporting in the same dashboard as your deploy logs, with email alerts for high-severity findings — Temps includes it out of the box. Free to self-host (Apache 2.0), or ~$6/mo on Temps Cloud.