Catch open source vulnerabilities
before they blow up.
Open Source Component Analysis & Response
OSCAR collects an SBOM (software bill of materials) on every build and continuously checks the open source components inside your services for known vulnerabilities. The UI speaks your language, and you can ask an AI in plain words — “Which projects have Critical vulnerabilities?” — and get the answer.
Riskiest projects vulnerable parts by severity
New findings last 12 weeks
- loan-batchCVE-2021-44228 · log4j-core 2.14.1Critical
- payment-apiCVE-2022-22965 · spring-beans 5.3.17Critical
Dashboardrisk across every project on one screen
AI queryjust ask — no menus to learn
Can you say right now what is inside your services?
When an open source vulnerability like Log4Shell breaks, the first question is always “Are we using it?” While each team digs through library lists by hand, time is on the attacker’s side. OSCAR prepares that answer ahead of time.
| Area | Until now | With OSCAR |
|---|---|---|
| Frequency | A manual review once a year — new vulnerabilities in between go unnoticed | An SBOM is uploaded on every build and re-checked when new vulnerabilities are published |
| Method | People check library lists by hand — easy to miss things | Machines match the component list against vulnerability databases (name, version, hash) |
| Response time | Days just to confirm “Do we use this?” | Find every affected project from a single CVE, immediately |
| Interface | English-only tools that business teams struggle to read | Localized UI; full license texts shown with a translation next to the original |
| Asking | Learn menus and filters to get the table you need | Ask an AI in plain language — 47 tools do the lookup |
At a glance
Finding vulnerabilities is only the start: OSCAR makes them readable, records who uploaded what, and traces how a component got in. The screens below use made-up data.
└ spring-boot-starter-log4j2
└ log4j-core 2.14.1
What it does
OSCAR uses a proven open source analysis engine (OWASP Dependency-Track) unmodified, and adds what teams need around it.
Automatic SBOMs — three build types
A pom plugin for Maven, an upload script for npm, and the ssemsbom CLI for Ant or hand-built projects without a pom.xml — the SBOM is uploaded as soon as the build finishes.
Continuous detection
NVD, GitHub Advisory, OSV, Sonatype OSS Index and Trivy together. When a new vulnerability is published, existing component lists are re-checked.
Natural-language AI (MCP)
47 tools over projects, vulnerabilities, components, policies, licenses and SBOMs, exposed through MCP. Ask from an AI client such as Claude, or from an in-house LLM.
Localized UI · license translation
A Korean UI out of the box, and full license texts translated by an LLM next to the original. Pick an in-house LLM (Ollama, LM Studio) or Gemini.
Upload history · standard tags
Records who uploaded each SBOM, when, and for which project. Standard tags — team, service type, technology, build tool, application server — group hundreds of projects.
Identifies messy legacy JARs
Six steps — file name, pom.properties, MANIFEST, group inference, Vendor-Id and (optional) a Maven Central hash lookup — recover names and versions. When unsure, it does not guess.
How teams use it
No new tool for developers to learn: one more step in the build, and results on screen or from the AI.
Install on your servers
The analysis engine and database run in Docker; the gateway and UI run on Tomcat 11. Everything stays inside your network.
Add an SBOM step
A plugin in the pom, a script for npm, one ssemsbom line in the Ant build. From then on every build uploads automatically.
Receive vulnerability data
Vulnerability databases are pulled periodically. In an air-gapped network you only open the inbound direction through the network bridge.
See · ask · fix
Watch risk on the dashboard, ask the AI about impact, and record the analysis state (in triage, not affected).
How it works
Every path goes through one OSCAR gateway. The UI, builds and AI never call the analysis engine directly, so the gateway can add translation and history — and the engine can be upgraded untouched.
- The analysis engine is not modified. OSCAR runs the official OWASP Dependency-Track release and changes responses in the gateway in front of it. Upgrading the engine does not touch OSCAR.
- Translation happens in the gateway, not the UI, so the screen, the AI and API clients all receive the same translated text.
- The MCP server runs on each user’s PC, started by the AI client, and enters the gateway with an issued API key. The AI can do only what that key allows.
- The dashed line is inbound only. Vulnerability data flows into the engine; your component lists never leave your network.
Dependency-Track 4.13
OWASP open source · Docker. SBOM analysis; vulnerability, policy and license evaluation.
Java 21 · Tomcat 11
Request relay, license translation and upload history, served with the localized UI.
MCP server · 47 tools
A single Java jar over STDIO. Works with Claude Desktop, Claude Code and other MCP clients.
CycloneDX 1.5 · PURL
The international SBOM standard (ECMA-424). Components are identified by PURL and matched against vulnerability data.
Security principles
A security tool must not become a new risk, so we drew these lines first.
- Installed on your servers — component lists and results are not handed to an outside cloud.
- What gets uploaded is a component list (SBOM), not source code — names, versions and hashes only.
- The only external connection is pulling in vulnerability data, which eases approval in air-gapped networks.
- With an in-house LLM (Ollama, LM Studio) for license translation, even the text to translate stays inside.
- The AI only calls tools; it does not judge on its own — answers are always grounded in the engine’s data.
- AI access uses a dedicated API key and cannot go beyond that key’s permissions (read, upload, …).
- If translation fails, the original is still shown — nothing disappears because of translation.
- The engine is proven open source used unmodified; OSCAR adds only a thin layer in front of it.
Requirements
What OSCAR needs to run.
- Docker (analysis engine, PostgreSQL) and Tomcat 11 (Java 21) on your servers. The analysis engine needs generous memory (several GB or more).
- An inbound path from the internet to receive vulnerability data. In air-gapped networks, allow only the required addresses through the network bridge.
- SBOMs are produced by builds, so you must be able to add an SBOM step to your pipelines (Maven, npm, Ant, manual builds).
- Commercial or in-house JARs without metadata cannot be identified and may be left out of vulnerability matching.
- AI queries need an MCP-capable client; in-house LLMs must support tool calling.
- License translations are for reference. Legal decisions follow the original text.
Considering OSCAR?
Tell us about your environment — air-gapped or not, number of projects, build tools — and we will plan the setup and schedule with you.
Contact sales