CVE-Guard

CVE-Guard posts native GitLab MR comments showing source confidence and database disagreement between NVD, OSV, and GitHub Advisory.

Inspiration

Modern software teams merge dependency changes every day, but security review still happens too late. Existing scanners usually tell developers, “this package has a CVE,” but they often do not answer the questions that matter most during a merge request:

Is the vulnerable method actually invoked in this codebase?
Do NVD, OSV, and GitHub Advisory agree, or is one source lagging?
Could this be a supply-chain attack that does not have a CVE yet?
Does this MR comply with our organization’s dependency security policy?

Incidents like Log4Shell showed how quickly a vulnerable dependency can spread through production systems. Recent npm supply-chain attacks also showed that malicious packages can be dangerous before any CVE exists. That inspired us to build CVE-Guard: an AI-powered software supply-chain compliance gate that lives directly inside GitLab merge requests.

What it does

CVE-Guard watches dependency-changing GitLab Merge Requests and posts an actionable security verdict directly on the MR.

It supports four main verdicts:

🚨 BLOCK — confirmed critical CVE and vulnerable invocation found
✅ CLEAR — dependency appears safe across checked sources
⚠️ CONFLICTING SOURCES — vulnerability databases disagree, manual review required
🚨 SUPPLY_CHAIN_RISK — npm-style supply-chain risk detected, even without a CVE

CVE-Guard checks:

Maven dependencies from pom.xml
npm dependencies from package.json
CVEs from NVD, OSV, and GitHub Advisory
vulnerable method invocation in source code
npm typosquatting risks
unpinned versions like latest, ^, and ~
missing lockfiles
dangerous lifecycle scripts like postinstall
compliance rules mapped to NIST SSDF, SOC 2, and ISO 27001

The result is an auditable compliance report inside the GitLab MR, showing policy, status, severity, evidence, and remediation.

How we built it

We built CVE-Guard as a modular Python and FastAPI security agent.

The core pipeline is:

GitLab MR
  → DependencyParser
  → CrossValidator
  → InvocationChecker
  → npm Supply Chain Checker
  → ComplianceChecker
  → VerdictFormatter
  → GitLab MR Comment
The main modules are:

DependencyParser — extracts dependency changes from pom.xml and package.json
CrossValidator — checks NVD, OSV, and GitHub Advisory
GeminiEngine — uses Gemini for vulnerable method reasoning and developer-friendly analysis
InvocationChecker — checks whether vulnerable methods are actually used in source code
NPMSupplyChainChecker — detects npm supply-chain attack signals
ComplianceChecker — produces PASS/WARN/FAIL compliance findings
VerdictFormatter — generates rich GitLab MR comments
GitLab MCP Adapter — supports GitLab MCP as the primary integration path, with REST fallback for deterministic demos
Agent Builder OpenAPI Tool — exposes /scan/gitlab-mr for Google Cloud Agent Builder orchestration
We also added a deterministic demo with four scenarios:

Log4j vulnerable version → BLOCK
Log4j patched version → CLEAR
Commons Text with source disagreement → CONFLICTING SOURCES
npm typosquat package → SUPPLY_CHAIN_RISK
Challenges we ran into
The biggest challenge was balancing real security accuracy with a fast merge-request workflow.

A normal CVE scanner can simply check package versions, but CVE-Guard needed to go deeper:

Cross-checking multiple vulnerability databases
Handling cases where NVD lags behind OSV or GitHub Advisory
Extracting the vulnerable method from CVE descriptions
Scanning source code for actual invocation
Detecting npm supply-chain signals that may not have CVEs
Producing a compliance decision that developers can understand quickly
Another challenge was making the GitLab integration honest and hackathon-ready. We separated the GitLab REST fallback from the GitLab MCP adapter so the project does not pretend REST calls are MCP tools. MCP is documented as the primary integration path, while REST remains available for reliable local demos and CI testing.

We also had to clean the repo heavily so the final submission looked like one focused project rather than a mix of old experiments.

Accomplishments that we're proud of
We are proud that CVE-Guard goes beyond traditional dependency scanning.

The most important accomplishments are:

Building a working end-to-end GitLab MR security agent
Cross-validating vulnerabilities across NVD, OSV, and GitHub Advisory
Surfacing source disagreement instead of hiding uncertainty
Using Gemini to reason about vulnerable methods and exploitability
Checking whether the vulnerable method is actually invoked
Adding npm supply-chain risk detection for typosquatting, lifecycle scripts, lockfile issues, and unpinned versions
Creating an auditable compliance gate with NIST SSDF, SOC 2, and ISO 27001 mappings
Producing four clear verdict types: BLOCK, CLEAR, CONFLICTING SOURCES, and SUPPLY_CHAIN_RISK
Exposing the scan pipeline as a Google Cloud Agent Builder-compatible OpenAPI tool
The CONFLICTING SOURCES verdict is especially important because most tools hide uncertainty. CVE-Guard makes that uncertainty visible and actionable.

What we learned
We learned that useful security automation is not just about finding vulnerabilities. It is about making the right decision at the right time, with enough evidence for developers to act.

We also learned that CVE data is messy. Different sources can disagree, update at different speeds, or provide different patched versions. A strong security agent needs confidence scoring and source transparency.

On the supply-chain side, we learned that CVE-only detection is not enough. npm-style attacks can happen through malicious package publishing, install scripts, typosquatting, and missing lockfiles before a CVE is created. That pushed us to add supply-chain compliance checks alongside traditional CVE checks.

Finally, we learned the importance of making AI agents practical. The best UI for this project is not another dashboard. It is the GitLab merge request comment, because that is where developers already make merge decisions.

What's next for CVE-Guard
Next, we want to make CVE-Guard production-ready by adding:

Full live GitLab MCP validation across more GitLab tools
Deeper Google Cloud Agent Builder orchestration
Cloud Run deployment with a public hosted demo
EPSS and CISA KEV exploit intelligence scoring
More ecosystems such as Python requirements.txt, pyproject.toml, Gradle, and Cargo
Auto-fix merge requests that upgrade vulnerable dependencies automatically
SBOM generation using CycloneDX
Policy-as-code customization through .cve-guard.yml
Historical audit reports for security teams
More advanced Gemini-based reachability reasoning
Our goal is to turn CVE-Guard into a practical AI security reviewer that every GitLab project can use to stop vulnerable and suspicious dependencies before they reach production.