Skip to content

Security: alpibrusl/lex-soft

Security

SECURITY.md

Security policy

lex-soft is the engine behind cross-organisation agent coordination and evidence-gated settlement — it can gate the movement of money between counterparties. Security reports are taken seriously.

Reporting a vulnerability

Please report privately, not via a public issue:

  • Email security@alpibru.com (or alfonso@alpibru.com), or
  • Open a GitHub private security advisory on this repository.

Include what you found, how to reproduce it, and the impact. We aim to acknowledge within a few working days and to agree a disclosure timeline with you. Please give us reasonable time to fix before any public disclosure.

Supported versions

Only the current main is supported. Pin to a reviewed commit for production.

Scope and known limitations

  • Load-bearing dependencies are out of scope of this repo's guarantees. The actual proof, spend-cap, and cryptographic logic live in lex-trail, lex-guard, and lex-crypto. A signature-verification or spend-cap bug there would undercut guarantees this repo appears to provide. Those deserve their own review before production settlement.
  • Builds are not yet fully reproducible. Dependencies are declared as git refs; the flat layout plus unpinned transitive deps means a lockfile (pinning the whole closure) is required for true reproducibility, and that is an upstream tooling gap. CI verifies the toolchain download's checksum.
  • Some routes assume an authenticating gateway in front. Onboarding and discovery endpoints must be gated (signup token / proof-of-org) before being exposed to the internet — see FederationConfig.
  • Partner key binding is trust-on-first-use, not proof of identity. Binding an Ed25519 key to an org requires signing a server-issued, single-use challenge, and replacing an existing key additionally requires a signature from the key being replaced. That proves possession of a key and continuity of whoever bound it first. It does not prove the caller is the real-world organisation whose name it claims: that needs a binding from the org id to something externally verifiable — a domain serving /.well-known/agent-key.json — and org ids here are opaque slugs, not domains. Until then, who may claim a new org name is governed only by the signup token, so treat that token as the org-namespace admission control it is.

Hardening status

Active remediation (from the 2026-07 audit) is tracked in the issue tracker: fail-closed verdicts, authenticated onboarding, dispatch-path revocation, indexed tenant scoping. Do not run this against real value until the before-deployment tier is complete.

There aren't any published security advisories