lotor

SBOM · vulnerabilities · open source

A CVE drops. You know who is affected.

Every day, lotor inventories the software on your servers, their containers and your git repositories, matches it against the Grype vulnerability database and tells you, in a single search, which projects to fix first.

Sign in Getting started

  • 3 Go binaries
  • 1 PostgreSQL database
  • 0 third-party service dependencies
Organization dashboard: open findings by severity, KEV vulnerabilities, policy alerts and 90-day trend.
  • CycloneDX 1.5 to 1.7
  • SPDX 2.3
  • Syft JSON
  • Grype · EPSS · KEV
  • OpenVEX
  • GitHub and GitLab
  • Docker and Podman
  • Debian · Ubuntu · RHEL · Alpine

Friday, 5:42 pm: “are we affected?”

Without an inventory, the answer takes days: emails to every team, scripts run by hand on each server, dependency files searched one by one. And next week, it all starts again.

With lotor

  1. Type the CVE into the search box.
  2. Read the list: projects, components, versions, fixed version.
  3. Export it as CSV for the teams concerned.

Under 50 ms across 1,000 projects and a million components. See the benchmarks

Features

From inventory to remediation, no spreadsheet needed

  • Automatic inventory

    A lightweight agent per Linux server (deb, rpm and apk packages, Java archives, Python…) and a repository agent hooked to your forges that scans every push. Docker and Podman containers become child projects of their host.

  • Daily rescans

    The Grype database is refreshed every day and the whole estate is rescanned: a new CVE shows up on your projects without agents sending anything. CVSS, EPSS and the KEV catalog rank the risks.

  • Cross-project search

    By name, purl, vers version range, CVE, GHSA or SHA-256 digest, across every project at once. Filter by team, label, severity, KEV; shareable URL, CSV or JSON export, API.

  • Triage and VEX

    Affected, not affected, false positive, risk accepted until a date: every decision is justified, logged and applied to future findings. OpenVEX and CycloneDX export, import of your vendors' VEX.

  • Policies and alerts

    CEL rules, dated violations, delivery by email, signed webhook, Matrix, Mattermost or Slack, and blocking commit statuses on GitHub and GitLab.

  • History and comparison

    Every SBOM received becomes a dated snapshot. Compare two: components added, removed, upgraded, and the effect on security.

  • Dashboards

    Open findings and their trend, median time to fix, most exposed projects and components, silent agents: your estate at a glance.

  • AI that proves what it finds

    Optionally, a local model (Ollama) or Anthropic, when allowed, looks for dependencies no manifest declares. Every finding is verified and comes with its proof.

Guided tour

What your teams see

Who is affected? One search.

The HTTP/2 “Rapid Reset” vulnerability is actively exploited: lotor finds it in the nghttp2 and nginx packages of four servers, with the fixing version and the triage status of each occurrence.

  • CVE, GHSA, purl, vers range or digest
  • Results grouped by project, ranked by risk
  • Full CSV or JSON export
Search for CVE-2023-44487: nine occurrences on four servers, with component, version, fixed version and risk.

Every upgrade, measured.

Between two snapshots of a repository, lotor lists the components that changed and what security gained: here, 24 upgrades resolving 26 findings.

  • Snapshot timeline per branch or tag
  • Additions, removals, upgrades and downgrades
  • Findings resolved and introduced
Comparison of two snapshots of the Portail client repository: 24 components upgraded and 26 findings resolved.

One finding, one decision, one trail.

Spring4Shell on the payment API: severity, 99.6% EPSS, listed in the KEV catalog, fixed version. The analyst marks it “affected” and plans the fix; the decision goes to the log and the VEX export.

  • Decision per project or for the whole organization
  • Standard VEX justifications
  • Risk accepted with an expiry date
Finding CVE-2022-22965 on spring-beans 5.3.17: critical, KEV, 99.6% EPSS, triage status affected.

Your rules, enforced every day.

Start from the bundled templates or write your own rules. A blocking violation marks the commit as failing on the forge: no regression reaches production unnoticed.

  • Checked CEL expressions, with preview
  • Immediate delivery or daily digest
  • Verdict API for your pipelines
Policies screen: three active rules, two of them blocking, with their open violations and the bundled templates.

Every server, its trajectory.

A host's page shows its findings by severity, their trend over 90 days or 12 months, and its containers, each with its own inventory.

  • OS, kernel, architecture, labels
  • “Scan now” at the next heartbeat
  • SBOM downloads as CycloneDX 1.6 and SPDX 2.3
Server srv-web-01: open findings by severity and their decrease over 90 days.

Screenshots taken on a demo instance: real Debian 12 and Ubuntu 24.04 packages, npm, Maven, PyPI and Go dependencies, current Grype database.

How it works

Three pieces, a single server to run

  1. Agents take the inventory

    lotor-host-agent on every server, lotor-repo-agent next to your forges. They produce SBOMs with Syft and only send what changed.

  2. The server keeps history and analyzes

    lotor-server receives SBOMs, stores them as snapshots, scans them with Grype and re-evaluates your policies. One dependency: PostgreSQL.

  3. You decide

    Web interface in French and English, REST API described in OpenAPI, notifications: each team sees its projects and triages its findings.

Security and sovereignty

Your inventory never leaves your infrastructure

  • Self-hosted

    No online account, no telemetry. Air-gapped sites import the vulnerability database by hand.

  • Sealed organizations

    Isolation enforced by PostgreSQL itself (row-level security), tested route by route.

  • Per-team permissions

    Reader, analyst, administrator: everyone sees only their teams' projects. Audit log of every sensitive action.

  • Mandatory second factor

    TOTP for every local account, single-use recovery codes, account lockout after wrong codes.

  • Agents under control

    Revocable tokens, optional mTLS, per-token rate limiting, secrets encrypted at rest.

  • Accessible

    Interface audited against the RGAA, usable with a keyboard and a screen reader, light and dark themes.

Install

One package and you're off

On Debian 13 or Ubuntu 24.04, the server package creates the local PostgreSQL database, the secrets, the first administrator and the nginx or Apache site. The host agent comes as deb and rpm packages, for amd64 and arm64.

Download Operations guide 

# the server
sudo apt install ./lotor-server_0.2.1_amd64.deb

# on every server to inventory
sudo apt install ./lotor-host-agent_0.2.1_amd64.deb
# server address in /etc/lotor-host-agent/config.yaml,
# enrollment token shown by the web interface
printf '%s' "$TOKEN" | sudo install -m 0600 -o lotor-agent \
  -g lotor-agent /dev/stdin /etc/lotor-host-agent/enrollment-token
sudo systemctl enable --now lotor-host-agent.service

Free, for real.

lotor is released under the WTFPL: use it, change it, share it, no strings attached.

Sign in Source code on GitHub