Know what your
build just pulled in.
Xenguard is an auditable proxy for software repositories. It sits between your developers and the public registries, analyzes every artifact before it is served, and turns your security and compliance requirements into policies that are actually enforced.
Runs on a single laptop or as a shared service. No vendor lock-in, no telemetry, no licence fees.
$ npm config set registry http://npm.xenguard.localhost:8888
$ npm login
10:24:01 fetch left-pad@1.3.0 user=alice
10:24:01 report sbom ok · licence MIT
10:24:01 allow policy=default → 200, intel stored
10:24:07 fetch chalk@5.6.2 user=alice
10:24:07 report sbom ok · licence MIT
10:24:07 deny policy=min-age, published 4h ago → 403The client just sees a 403. Xenguard records which identity asked for what, and which policy decided.
A single install can pull in hundreds of strangers.
Modern projects are assembled, not written. Every transitive dependency is code you ship, license terms you inherit, and an attack surface you did not review. Checking that by hand is a tedious, cross-team exercise, and the tools that automate it are usually proprietary.
Nobody looks first
Packages are fetched straight from the public registry into the build. Whatever arrives is trusted by default, and inspection happens, if at all, long after the fact.
Requirements live in documents
Security and legal teams hand out rules about licences, provenance, and vulnerabilities. Those rules sit in wikis and PDFs instead of in the path that actually serves the artifact.
No answer after the incident
When a package turns out to be compromised, the question is simple: who pulled it, when, and into which project? Without a record, the answer is guesswork.
Inspect, decide, serve — then remember.
Xenguard speaks the protocols your package managers already use. Point a client at it instead of the upstream registry and every request runs through the same four stages.
Intercept
The proxy implements the repository interface and authenticates the requesting user or machine.
Analyze
Analyzers inspect the artifact and produce reports: an SBOM, extracted licence terms, and whatever else you plug in. Known results come straight from the intel server.
Evaluate
The policy engine, embedded in the authentication engine, evaluates your Rego policies against the request context and the analysis results, and returns allow or deny.
Serve & record
Allowed artifacts are served, and their analysis results kept for next time. Every decision, with its context, lands in the audit log.
Your rules, in a language built for rules.
Hardcoded checks never survive contact with a second project. Xenguard uses the Rego policy language from Open Policy Agent, so policies are versioned, reviewed, and tested like the rest of your code.
- Deny by default. Nothing is served unless a policy says so.
- Rich context. Decide on the user, the target, the request stage, and the analysis results.
- Readable intent. A quarantine window or a licence blocklist is a handful of lines, not a plugin.
package proxy
default allow := false
# Only serve packages that have been
# public for at least seven days.
allow if {
input.target == "PROXY_TARGET_DOWNLOAD"
input.stage == "PROXY_STAGE_PREHANDLER"
age := time.now_ns() - input.package.published_ns
age > (7 * 24 * 60 * 60 * 1000000000)
}Composable parts behind one entry point.
Xenguard is built as self-contained containers that talk over well-defined interfaces, modelled with the C4 model. Every one of them is documented; run only what you need.
Proxy
The entry point. Implements repository interfaces over HTTP and coordinates every other component.
Analyzers
Self-contained inspectors that generate SBOMs, extract licence terms, or run your own checks. Today they ship as Go libraries embedded in the proxy.
Authentication & policy engine
Handles identities (local or from your provider, LDAP and friends), and evaluates the Rego policies that allow or deny each artifact.
Audit engine
Records which identity requested which artifact from which repository and when, correlated with the analysis data.
Intel server
Keeps the analyzer results, so the same artifact is never inspected twice and later requests are decided from what is already known.
Monitoring service
Events and activity, sourced from the audit engine. Admins get the bird's-eye view; developers see their own requests.
Same tool, two scales.
On a developer machine
Run Xenguard locally, point your package manager at it, and get a personal quarantine and audit trail for everything you install. Identity management stays out of the way.
Single binaryAs a shared service
Run it centrally for a team or an organisation. Plug into your identity provider, let administrators own the policies, and give developers and admins their own view of the monitoring data.
Multi-tenantBuilt in the open, one component at a time.
Xenguard is a prototype under active development, funded by the Prototype Fund. The architecture is documented with the C4 model and the design decisions are written down as ADRs — so you can follow, disagree, and contribute.
npm repository interfaceSponsored by
Xenguard is funded by the German Federal Ministry of Research, Technology and Space through the Prototype Fund.
Curious? Start with the architecture.
The documentation explains every component and how they fit together. The blog covers the reasoning behind the decisions. Both are a good place to start a discussion.