Ospobox¶

OSPO in a Box. Know what is happening across the open source you depend on, ship on, and answer for.

Ospobox collects activity from the forges your projects live on, scores what it finds, applies rules to the scores, and pushes the result somewhere that can act on it. That loop (collect → score → decide → act) runs today, on a schedule, with signed delivery at the far end.

Who it is for¶

Open Source Program Offices answering "what did we ship, where, and who wrote it". Engineering leaders who need the health of a dependency tree to be a number they can defend. Due-diligence and procurement teams deciding whether a project is safe to adopt. Platform and security teams who want a machine-readable signal that arrives on its own.

What it does¶

Collects¶

Four forges (GitHub, GitLab, Codeberg and SourceHut) through one normalized adapter interface, on a six-hourly schedule or on demand. Commits, pull requests, issues, releases, and the metadata around them.

Beyond forges, anything a plugin can produce: a CycloneDX SBOM becomes components keyed by package URL, an advisory feed becomes advisories against those packages. Evidence is append-only and content-addressed, so collecting the same fact twice adds nothing, and a changed fact keeps its history.

Scores¶

Repositories get a health score with its reasoning attached: every component of every score carries a one-line explanation, rendered as written. Two scorers ship, a five-factor activity composite and dependency exposure over a repository's declared components.

Decides¶

Rules turn scores and activity into alerts: inactivity, low health, a sharp health drop, a week-over-week activity collapse, PR and issue backlogs. They evaluate after every sync, deduplicate against what is still open, and never file the same finding twice.

Acts¶

Alerts leave the system as HMAC-signed webhooks, with retries and a delivery log, so a subscriber can hold a deployment, open a ticket, or refuse to resolve a package. Reports go out as Markdown, HTML or PDF, on a cadence, by email. Everything is available over a REST API.

What makes it unusual¶

Everything domain-shaped is a plugin. Evidence sources, scorers and alert rules are interfaces, loadable from a third-party package's entry points. The in-tree implementations load through the same registry, as worked examples with no privileges of their own. Read Extension points and check the claim.

Scores explain themselves. A number between 0 and 100 is not an answer. Every component states what it counted and in what units, so a score can be argued with, which is how one comes to be trusted.

Evidence is kept. Facts are stored with a content hash and a collection time, so the basis of a decision remains inspectable after the decision.

Reading these docs¶

Everything described in plain prose runs today. Anything not yet built is marked:

Quick start¶

git clone git@git.sr.ht:~sfermigier/ospobox
cd ospobox

make install          # dependencies, via uv
cp .env.example .env  # then edit it

make migrate          # the app does not create tables
make run              # web + worker

Then open http://localhost:8000.

To see the whole loop run end to end (collect, score, alert, signed delivery, actuation) the demo/ directory has a runbook, a receiver that verifies signatures, and a supply-chain script.

Where to go next¶

Stack¶

License¶

Open source. See the LICENSE file.