Security
Security you can inspect, not just read about
The LedgerForge core is open source, so its security model is there to review. This page summarises how it protects keys, money and history, how releases are built, and how to report a vulnerability.
Release artefacts and responsev1.0.0
- checksums.txt over archives, SBOMs and image digestSHA-256
- Source and container SBOMsSPDX
- Image SBOM and provenance attestationsBuildKit
- Publication gated on vulnerability scanninggovulncheck
- Acknowledgement of private reports3 business days
- Initial assessment7 business days
- Updates while an issue is openevery 14 days
Response times are targets from SECURITY.md, not guarantees. Releases are not separately signed.
Security model
Least authority for every key, enforced by the server
Summarised from the security guide and the repository's architecture and trust boundaries.
Keys and authentication
- Requests authenticate with X-LedgerForge-Key. Keys are stored as bcrypt hashes and shown in plaintext only once, at creation.
- Every request checks hash, scope, expiry and revocation against PostgreSQL, so a stale cache entry can't restore a revoked key.
- Legacy-key fallback is capped at two concurrent scans per process, returns 429 under saturation and can be switched off after rotation.
Delegation
- A non-master key creates keys only for its own owner, grants only concrete scopes it already holds and can't extend expiry beyond its own.
- Delegation ancestry is immutable. Descendants inherit and may narrow policies, and share their ancestors' daily budgets.
- Wildcard scopes alone don't grant approval or policy-management authority.
Authority over money
- Spending policies are enforced on the same admission path for HTTP and identity-bound MCP requests, with usage reserved in PostgreSQL.
- Above an approval threshold the server holds funds; the initiating key and its delegation family can't approve or reject.
- Reserved execution, lineage, policy and recovery keys can't be changed through the metadata API.
Inputs and errors
- Request bodies and uploads have explicit size bounds. Monetary JSON tokens are decoded exactly or rejected.
- Responses keep stable error codes and deliberate validation messages. SQL text, connection strings and driver errors stay in operator logs.
Outbound webhooks
- A dedicated signing secret, with HMAC-SHA256 over the timestamp and exact raw body.
- URL validation, optional blocking of private and special-purpose destinations, no redirects, delivery timeouts and bounded responses.
- Non-2xx responses stay retryable instead of being treated as delivered.
Deployment defaults
- The example configuration explicitly enables authentication. Compose binds published ports to loopback.
- Run with server.secure: true behind TLS. /health is public; /metrics uses its own bearer token.
Verifiable ledger
History you can check independently of the system that wrote it
Limits, stated plainly.Replay can't detect a fully rewritten but mutually consistent database, and database-only hashes can't protect against an administrator who can rewrite both postings and evidence. That is why checkpoints should be anchored under a separate trust boundary. Neither check proves a real-world payment happened; reconcile for that.
Verification guide- Immutable postings
- Corrections and refunds are new, linked transactions. Financial postings and accepted execution controls are preserved.
- Read-only replay
- ledgerforge verify recomputes balances from postings in one REPEATABLE READ snapshot and exits nonzero on any issue. It never repairs data.
- Versioned hash chain
- Canonical v3 commitments cover amounts, precision, status, references, overdraft caps and execution controls, with persistent checkpoint roots.
- External anchors
- audit export prints checkpoint roots. Sign and store them outside the database; audit verify --anchor reports any root the chain no longer matches.
Vulnerability management
Every release is tested, scanned and checksummed before it ships
Release archives and images are not separately signed today. Verify downloads against checksums.txt and pin the image by the digest recorded on the release.
Tested invariants
Exact-amount and allocation fuzz targets, generated PostgreSQL operation sequences, conservation checks and race tests in CI.
Vulnerability scanning
make vuln runs govulncheck on every pull request and push to main, and gates publication. Dependabot keeps Go modules and actions current.
Release artefacts
Test-gated tag builds for Linux, macOS and Windows on amd64 and arm64, with checksums.txt covering archives, SBOMs and the image digest.
SBOMs and provenance
SPDX SBOMs for the source and the container, plus BuildKit SBOM and provenance attestations on the image.
$ curl -LO https://github.com/devaccuracy/ledgerforge/releases/download/v1.0.0/ledgerforge_v1.0.0_linux_amd64.tar.gz$ curl -LO https://github.com/devaccuracy/ledgerforge/releases/download/v1.0.0/checksums.txt$ sha256sum -c checksums.txt --ignore-missingledgerforge_v1.0.0_linux_amd64.tar.gz: OK$ tar -xzf ledgerforge_v1.0.0_linux_amd64.tar.gz$ ./ledgerforge_v1.0.0_linux_amd64/ledgerforge versionledgerforge 1.0.0 (commit 64c7aec, built 2026-10-10T05:53:57+00:00)Responsible disclosure
Report vulnerabilities privately
Email security@ledgerforge.io with the affected version or commit, component, impact and reproduction steps. Don't post exploits, credentials or financial data in public issues.
In scope: authentication, authorisation, monetary correctness, transaction integrity, webhook delivery, deployment exposure and reproducible resource exhaustion. The latest stable release is supported; fixes ship as patch releases. Full details are in the security policy.
- 3 business daysAcknowledgement of your report
- 7 business daysInitial assessment and next steps
- Every 14 daysProgress updates while a confirmed issue is open
- 90 daysTarget for coordinated disclosure from confirmation
These are response targets, not a guarantee of resolution by a particular date. Disclosure timing is agreed with the reporter.
Reviewing LedgerForge for production?
We can walk your security team through the trust model, key and policy design, and verification practice for your deployment.