DEV Community: Fahed dorgaa

vens-action: reranking Trivy/Grype CVEs by real risk in CI

Fahed dorgaa — Thu, 28 May 2026 09:06:12 +0000

If you run Trivy or Grype in CI and triage the output by CVSS, this is the thing I wish I'd had two years ago.

Quick recap. Trivy and Grype hand you a list of CVEs. CVSS is a score in a vacuum — it doesn't know whether a service runs in a private subnet behind mTLS, or sits on the open internet handling payment cards. vens reads your scan output plus a YAML describing the service (exposure, data sensitivity, business criticality, controls, compliance, …), runs every CVE through an LLM with that context, and emits a CycloneDX VEX with OWASP Risk Rating scores. You gate the build on those instead.

vens-action is the GitHub Action wrapper — install, invocation, build gate, packaged as a composite. Here's the minimum to drop it in.

What you need

A Trivy or Grype JSON report (you're probably running one of these already).
A .vens/config.yaml. Three context fields are the floor; the full annotated reference is in examples/quickstart/config.yaml.
An LLM API key — OpenAI, Anthropic, Google, or a self-hosted Ollama.
The serialNumber of your CycloneDX SBOM (or an ad-hoc one — see below).

The config

The bare minimum:

project:
  name: "checkout-api"
context:
  exposure: "internet"
  data_sensitivity: "high"
  business_criticality: "critical"

For scoring that actually reflects your service, fill in the rest — security controls (WAF, IDS, segmentation, …), compliance requirements, availability target, free-form notes. The annotated reference lives in examples/quickstart/config.yaml. Wrong values → wrong scores, so this file deserves the same review process as the rest of your code (CODEOWNERS, PR review, the works).

The SBOM serial number

vens writes a CycloneDX VEX whose vulnerabilities[].affects[].ref entries are BOM-Link references — they must point back to the serialNumber of the SBOM the scan was produced from.

If you already have a CycloneDX SBOM for the artifact, pull the serial from it:

SBOM_UUID=$(jq -r .serialNumber sbom.cdx.json)

If you don't have one yet, generate an ad-hoc serial and reuse it across rescans of the same service so the BOM-Link stays stable:

SBOM_UUID="urn:uuid:$(uuidgen | tr '[:upper:]' '[:lower:]')"

Store the value as a repo variable, say vars.SBOM_SERIAL. Flag reference: vens generate --sbom-serial-number.

The workflow

.github/workflows/scan.yml:

name: scan
on: [push]
permissions:
  contents: read
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Trivy scan
        run: trivy image python:3.11-slim --format json --output report.json

      - name: vens
        id: vens
        uses: venslabs/vens-action@v0.1.0
        with:
          version: v0.3.2
          config-file: .vens/config.yaml
          input-report: report.json
          sbom-serial-number: ${{ vars.SBOM_SERIAL }}
          llm-provider: openai
          llm-model: gpt-4o
          llm-api-key: ${{ secrets.OPENAI_API_KEY }}
          fail-on-severity: critical
          enrich: "true"

      - uses: actions/upload-artifact@v4
        with:
          name: vens
          path: |
            ${{ steps.vens.outputs.vex-file }}
            ${{ steps.vens.outputs.enriched-report }}

Each run gives you a CycloneDX VEX (vex-file), your original Trivy report annotated with Custom.owasp_score (enriched-report, when enrich: true), and per-severity counts as step outputs (count-critical, count-high, …). Pipe the counts into dashboards, PR comments, whatever you already do with scan metrics.

fail-on-severity: critical makes the step fail if any CVE comes out CRITICAL by OWASP (score ≥ 60). Drop the line if you just want artifacts and a manual review.

Things you'll probably want to tweak

Self-hosted models. llm-provider: ollama + llm-base-url: http://ollama.corp:11434.
Air-gapped runners. Build vens yourself and pass bin-path instead of version. Skips the download + checksum step entirely.
Pin by SHA. uses: venslabs/vens-action@<commit-sha>. Renovate and Dependabot both follow SHA-pinned actions.

Why I bothered building it

CVSS sorts vulnerabilities like a smoke detector that can't tell if you're cooking or your kitchen is on fire. A 9.8 on an internal service with no PII and no internet exposure is rarely your urgent problem. A 5.4 on the auth path with cleartext token logging probably is. Your team knows the difference — but a spreadsheet per service doesn't scale, and most tools that do contextual scoring are paid SaaS with their own opinions.

vens is OSS, Apache 2.0. The action is a thin composite around the CLI. Issues, feedback, PRs — I read them.

[Boost]

Fahed dorgaa — Sat, 14 Feb 2026 13:14:30 +0000

Vens: Stop Patching Vulnerabilities That Don't Matter to You - DEV Community

Monday Morning Nightmare Monday 9 AM. Coffee in hand. You open the Trivy report: 107...

dev.to

Vens: Stop Patching Vulnerabilities That Don't Matter to You

Fahed dorgaa — Sat, 14 Feb 2026 12:57:53 +0000

Monday Morning Nightmare

Monday 9 AM. Coffee in hand. You open the Trivy report: 107 vulnerabilities.

You sort by CVSS. A 9.8 CRITICAL CVE at the top. Emergency meeting. Everyone panics.

Except… this vulnerability targets a feature you don't even use. 2 days wasted for nothing.

Meanwhile, a 5.3 MEDIUM CVE sits quietly in the list. It exposes customer data. Your company is under GDPR. That was the real problem.

CVSS tells you the technical severity. Not the real risk for YOUR system.

Vens: Context, Finally

vens is a tool that analyzes your vulnerabilities with your system's context (exposure, sensitive data, compliance, security controls) and calculates a realistic OWASP score using an LLM.

Real Example

Result: You finally know what to patch first.

How Does It Work?

1. Install vens

vens is an official Trivy plugin 🎉

go install github.com/venslabs/vens/cmd/vens@latest

# or as Trivy plugin
trivy plugin install github.com/venslabs/vens

2. Scan as usual

trivy image python:3.11-slim --format json --output report.json

3. Create context with `config.yaml`:

project:
  name: "my-api"
  description: "Customer-facing REST API"

context:
  exposure: "internet"              # Internet-accessible
  data_sensitivity: "high"          # Customer PII data
  business_criticality: "high"      # Business-critical service
  compliance_requirements: ["GDPR", "SOC2"]
  controls:
    waf: true                       # Cloudflare WAF active
    ids: true                       # IDS in place

4. Run contextual analysis

export OPENAI_API_KEY="sk-..."
export OPENAI_MODEL="gpt-4o"

trivy vens generate --config-file config.yaml report.json output.vex.json

Result: A VEX That Speaks Your Language

Here's what vens generates (extract from a real VEX):

{
  "$schema": "http://cyclonedx.org/schema/bom-1.6.schema.json",
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "version": 1,
  "vulnerabilities": [
    {
      "id": "CVE-2026-0915",
      "ratings": [
        {
          "score": 45.5,
          "severity": "high",
          "method": "OWASP",
          "vector": "SL:7/M:7/O:7/S:7/ED:6/EE:6/A:6/ID:3/LC:7/LI:7/LAV:7/LAC:7/FD:7/RD:7/NC:7/PV:7"
        }
      ]
    },
    {
      "id": "CVE-2019-1010023",
      "ratings": [
        {
          "score": 10,
          "severity": "low",
          "method": "OWASP",
          "vector": "SL:3/M:3/O:3/S:3/ED:2/EE:2/A:2/ID:7/LC:4/LI:4/LAV:4/LAC:4/FD:4/RD:4/NC:4/PV:4"
        }
      ]
    }
  ]
}

See the difference?

Each vulnerability has a human explanation of the real risk. No more guessing!

No more guessing!

The Flow

Trivy Scan → 107 CVEs with CVSS scores
    ↓
vens + LLM → Analyzes each CVE with YOUR context
    ↓
OWASP Scores → Risk = Likelihood × Impact
    ↓
Prioritized List → Fix what matters for YOU

Try vens Now

📦 GitHub: https://github.com/venslabs/vens
📖 Full example: https://github.com/venslabs/vens/tree/main/examples/quickstart
📄 License: Apache License 2.0 — Open source, contributions welcome
🤖 LLM support: OpenAI, Anthropic, Ollama (local), Google AI

Originally published on Medium