Security and Assurance
Material for the people who have to sign off on running Merlon: security reviewers, vendor-risk assessors, and internal audit.
Merlon is deployed by regulated institutions, which means the question is never only "is this software any good" but "can we evidence that we assessed it". These pages are written for the second question.
| Page | Answers |
|---|---|
| Data Egress | What leaves our network, and what triggers it |
| Supply Chain | How dependencies, images, and releases are controlled and evidenced |
| Accepted Risks | What the project knows it does not do, and why |
Related material
| Where | What |
|---|---|
| SECURITY.md | How to report a vulnerability, and the response commitments |
| Authorization | Role model, segregation of duties, dual control |
| Regulatory Scope | What Merlon does and does not claim to cover |
| FSA Guideline Mapping | Coverage against the FSA AML/CFT guidelines |
| Data Retention | Retention policy enforcement |
| Container Images | What is published, how to verify it |
| Release Checklist | What a release asserts, and what is not yet evidenced |
The short version
If you are assessing Merlon and want the answers without reading further:
- No outbound connections you did not configure. No telemetry, no analytics, no licence check, no update check. See Data Egress.
- All data stays in your PostgreSQL database, in your infrastructure. Direct-PII customer attributes are encrypted at rest with keys held outside the database.
- The container runs as a non-root user and needs no writable filesystem.
- Published images are immutable, multi-architecture, and carry a build
provenance attestation and a CycloneDX SBOM. There is no
latesttag. - Audit records are append-only at the database privilege level, and the application refuses to start in production if that is not enforced.
- One active maintainer, disclosed on the artifact. Independent approval
cannot exist in a single-maintainer repository, so releases state that they do
not assert it — in
release-manifest.json, in the image labels, and above the release notes. Merges require a self-review record enforced by a status check rather than an approval nobody can give. See the release checklist and repository governance.
That last point is the one most vendor questionnaires do not have a field for, and it is the one most likely to matter to your assessment.