Home

ORES

Deterministic risk scoring engine. Feed it signals from any source — CVSS, EPSS, threat intel, asset context — get a single auditable score.

Get Started GitHub

The Problem¶

Your scanner says CVSS 9.8. But which 9.8 do you fix first — the one on your internet-facing payment service with an active exploit and no patch, or the one on an internal dev box that was patched last week?

CVSS can't tell you. ORES can.

# Same CVE, same CVSS 9.8 — different context, different score
ores evaluate -f payment-service.json   # → 88 (high)
ores evaluate -f dev-box.json           # → 58 (medium)

How It Works¶

1

Ingest¶

JSON, YAML, or protobuf. Any combination of the 8 signal types.

2

Normalize¶

Every signal mapped to [0, 1]. Frameworks become directly comparable.

3

Score¶

Weighted composite across 5 dimensions. Output: [0, 100].

4

Explain¶

Factor-by-factor breakdown. Every point accounted for.

Why ORES¶

Deterministic¶

Same inputs, same score. Always. Suitable for automated pipelines, audit logs, and compliance workflows.

Graceful Degradation¶

Feed it 2 signals or 8. Missing signals fall back to neutral defaults. Confidence tells you how much of the model is data-driven.

Explainable¶

Every score includes a factor-by-factor breakdown. Trace which signals drove the result and by how much. No black boxes.

Universal Input¶

CVSS, EPSS, threat intel feeds, asset inventories, patch systems, compliance frameworks — all through a single typed signal interface.

CLI, Daemon, or WASM¶

Run as a one-shot CLI, a long-running gRPC/HTTP service, or embed as a WASM module. All three produce bit-identical scores.

Apache 2.0¶

Security infrastructure should be open and auditable. No vendor lock-in. Contribute signal parsers, challenge the model, or embed it in your stack.

See It in Action¶

Crown Jewel — 88 (high)Internal Dev Box — 58 (medium)

echo '{
  "apiVersion": "ores.dev/v1",
  "kind": "EvaluationRequest",
  "signals": {
    "cvss":         {"base_score": 9.8},
    "epss":         {"probability": 0.92, "percentile": 0.98},
    "threat_intel": {"actively_exploited": true, "ransomware_associated": true},
    "asset":        {"criticality": "crown_jewel", "network_exposure": true, "data_classification": "pii"},
    "blast_radius": {"affected_systems": 340, "lateral_movement_possible": true},
    "patch":        {"patch_available": false}
  }
}' | ores evaluate -o table

Score:         88 (high)      Confidence: 0.93
Signals used:  6 / 6

FACTOR                 CONTRIBUTION  REASONING
base_vulnerability     30            High impact: 99%
exploitability         24            High impact: 96%
environmental_context  19            High impact: 95%
remediation_gap        6             Moderate impact: 38%
lateral_risk           9             High impact: 94%

echo '{
  "apiVersion": "ores.dev/v1",
  "kind": "EvaluationRequest",
  "signals": {
    "cvss":         {"base_score": 9.8},
    "epss":         {"probability": 0.92, "percentile": 0.98},
    "threat_intel": {"actively_exploited": true, "ransomware_associated": true},
    "asset":        {"criticality": "low", "network_exposure": false, "data_classification": "internal"},
    "blast_radius": {"affected_systems": 1, "lateral_movement_possible": false},
    "patch":        {"patch_available": true, "patch_age_days": 3, "compensating_control": true}
  }
}' | ores evaluate -o table

Score:         58 (medium)    Confidence: 0.93
Signals used:  6 / 6

FACTOR                 CONTRIBUTION  REASONING
base_vulnerability     30            High impact: 99%
exploitability         24            High impact: 96%
environmental_context  2             Low impact: 11%
remediation_gap        2             Low impact: 16%
lateral_risk           0             Low impact: 0%

Same CVE. Same CVSS. The payment service scores 88. The dev box scores 58. Every point is accounted for — factors sum to the final score.

8 Signal Types¶

`cvss`¶

Severity score (0–10) and attack vector string

`epss`¶

Exploit prediction probability and percentile

`nist`¶

NVD severity classification and CWE

`threat_intel`¶

Active exploitation and ransomware flags

`asset`¶

Criticality, network exposure, data classification

`blast_radius`¶

Affected systems and lateral movement

`patch`¶

Patch availability, age, compensating controls

`compliance`¶

Affected frameworks and regulatory impact

Don't have all 8? That's fine. ORES scores what it gets and adjusts confidence accordingly.

Full signal reference

Three Ways to Deploy¶

CLI¶

ores

One-shot evaluations from the terminal, scripts, and CI pipelines.

CLI Guide

Daemon¶

oresd

Long-running HTTP + gRPC service for SIEM, SOAR, and ticketing integrations.

Daemon Guide

WASM¶

ores.wasm

Embed in browsers, edge runtimes, Node.js, Python, or Rust.

WASM Guide

All three use the same engine. Same input = same score.

ORES vs. The Status Quo¶

	Status Quo	ORES
Inputs	One framework at a time	All signals, together
Consistency	Depends on the vendor	Deterministic, always
Explainability	A number	Factor-by-factor breakdown
Context	Vulnerability in a vacuum	Asset, blast radius, remediation, compliance
Confidence	Implicit	Mathematically derived from signal coverage
Deployment	Vendor lock-in	CLI, daemon, WASM

Install¶

GoDockerSource

go install github.com/rigsecurity/ores/cmd/ores@latest

docker run -p 8080:8080 ghcr.io/rigsecurity/oresd:latest

git clone https://github.com/rigsecurity/ores.git && cd ores
go build ./cmd/ores

Installation guide Quickstart

Status¶

ORES is in preview (v0.1.0-preview). The architecture and API surface are stable. Scoring model weights are being refined through ML research.

Shipping: 8 signal types, CLI + daemon + WASM, full test suite, CI/CD with multi-platform releases and Cosign signing.

Next: Finalized weights, additional signals (KEV, cloud posture), language SDKs (Python, TypeScript, Rust).

Built by Rig Security