🛡️ BootShield

A Spring Boot dependency and configuration risk scanner.

Upload a project's pom.xml and get back a risk report: known CVEs in your dependencies (via OSV.dev), and Spring Boot-specific misconfiguration patterns — like the exact combination behind the critical CVE-2026-40976 advisory.

Screenshot

(Scan of the included sample pom.xml, which deliberately reproduces the CVE-2026-40976 pattern.)

Why this exists

Most dependency scanners stop at "this package has a vulnerability." That's useful, but it misses a second, quieter class of risk: Spring Boot config combinations that silently disable security, even when every individual dependency version is fine.

The clearest real example: in April 2026, Spring disclosed CVE-2026-40976 (CVSS 9.1) — a critical flaw where Spring Boot 4.0's default web security filter chain becomes completely ineffective if a project depends on spring-boot-actuator-autoconfigure but not on spring-boot-health. No code bug, no bad version — just a dependency combination that quietly turns off authorization on every endpoint.

BootShield checks for that pattern directly, plus a handful of other common Spring Boot risks (exposed DevTools, missing security starter, etc.), alongside a standard CVE lookup for every dependency.

What it does

1. Parses the <dependencies> section of an uploaded pom.xml (plain DOM parsing, no external Maven libraries)
2. Looks up each dependency against the free OSV.dev vulnerability database
3. Runs a set of Spring Boot-specific configuration checks:
   • spring-boot-actuator-autoconfigure present without spring-boot-health (the CVE-2026-40976 pattern)
   • spring-boot-devtools present (risk of exposing a remote restart secret in production)
   • Actuator present without spring-boot-starter-security (unauthenticated actuator endpoints)
   • No spring-boot-starter-security dependency at all
4. Combines everything into a single 0–100 risk score and CRITICAL / HIGH / MEDIUM / LOW rating
5. Displays it in a React dashboard: drag-and-drop upload, an animated risk gauge, summary stat cards, a configuration findings feed, and a per-dependency vulnerability list

Tech stack

• Backend: Java 17, Spring Boot 3.3 (Spring Web + Spring WebFlux's WebClient for the OSV.dev calls)
• Frontend: React + Vite dashboard (frontend/) — drag-and-drop upload, animated SVG risk gauge, summary cards, findings feed. Built output is served directly from Spring Boot's static resources, so the whole app runs as a single service.
• Vulnerability data: OSV.dev API (free, no API key)

Running it

Requires Java 17+, Maven (or Docker, which bundles Maven — see below), and Node.js 18+ for the frontend.

1. Build the frontend

cd frontend
npm install
npm run build
cd ..

This builds the React app directly into src/main/resources/static (configured in frontend/vite.config.js), so no manual copying is needed.

2. Run the backend

Either with Maven directly:

mvn spring-boot:run

Or with Docker (recommended if you don't have Maven installed locally — the Dockerfile handles the Java build too):

docker build -t bootshield .
docker run -p 8080:8080 bootshield

Then open http://localhost:8080.

A sample vulnerable pom.xml is included at sample-pom-files/vulnerable-sample-pom.xml — upload that first to see all the checks fire and reproduce the screenshot above.

Frontend development mode

While actively working on the UI, you can run the frontend and backend separately for hot-reload:

# terminal 1
mvn spring-boot:run

# terminal 2
cd frontend
npm run dev

npm run dev starts Vite's dev server (usually on http://localhost:5173) and proxies /api calls to the backend on port 8080, so you get instant UI updates without rebuilding.

Running tests

mvn test

API

POST /api/analyze — multipart form field pomFile containing a pom.xml. Returns JSON:

{
  "overallScore": 63,
  "overallRisk": "CRITICAL",
  "dependencies": [
    {
      "groupId": "org.springframework.boot",
      "artifactId": "spring-boot-actuator-autoconfigure",
      "version": "4.0.2",
      "vulnerabilities": [],
      "recommendation": "No known vulnerabilities found for this version."
    }
  ],
  "configFindings": [
    {
      "rule": "ACTUATOR_WITHOUT_HEALTH",
      "severity": "CRITICAL",
      "description": "...",
      "recommendation": "..."
    }
  ]
}

Known limitations (v1)

• Only reads directly declared dependencies in pom.xml — it does not resolve the full transitive dependency tree (that would require either invoking Maven itself or a full dependency resolver)
• Versions inherited purely from a parent BOM (e.g. spring-boot-starter-parent) without an explicit <version> can't be resolved and are skipped for CVE lookup (flagged as "unresolved" instead)
• No persistence — each scan is stateless; nothing is stored between runs. The "Scan history" item in the sidebar is a placeholder for this planned feature, not yet functional.
• Config checks are a small, explicit rule set, not a general-purpose model — easy to extend, but only catches what's been encoded

Roadmap

• Persist scan history so the "Scan history" sidebar tab becomes functional, letting a project's risk score be tracked over time
• Parse an actual CycloneDX SBOM (Spring Boot 3.3+ can generate one) instead of relying solely on pom.xml
• Resolve the full transitive dependency tree, not just direct dependencies
• GitHub Action / CI integration to fail a build on new CRITICAL findings
• More Spring config rules (CORS misconfig, insecure CSRF settings, open management port, etc.)

Background

Built as a portfolio project exploring the "prove trust before use" angle on the software supply-chain problem — most tools scan after the fact; this tries to catch both known-CVE risk and Spring-specific structural risk before a project ships.