Security controls, testing, and responsibilities
MessageFoundry uses encryption, access controls, and audit records to help protect patient data. This page documents its security standards, testing scope, and deployment responsibilities. The engine is self-hosted.
Development and assessment frameworks
The references below cover development practices, security testing, control mappings, and application security assessment.
NIST SSDF — built securely
Development follows NIST SP 800-218, the Secure Software Development Framework (SSDF). It covers four practice groups: prepare, protect, produce, and respond. Practices include threat modeling per interface, automated review, and secure defaults.
NIST 800-115 — tested in CI
Security testing follows NIST SP 800-115. Each build checks code, dependencies, and secrets, then runs functional and integration tests against the engine. Dynamic testing is limited to an automated authorization sweep. Each build probes a live instance over a network socket to check that protected endpoints reject callers without the required access. This excludes non-HTTP ingress listeners, the browser console, and TLS. No independent dynamic application security testing, external code review, or penetration test has been performed. All are planned after Early Access.
NIST 800-66 Rev. 2 — HIPAA-mapped
Implemented controls are mapped to the HIPAA Security Rule via NIST SP 800-66 Rev. 2 — access control, audit, integrity, and transmission security.
OWASP ASVS 5.0 Level 3 — self-assessed
The project self-assesses all 345 requirements in OWASP ASVS 5.0 Level 3, with scope set chapter by chapter. Every exclusion includes a reason. Partially met requirements remain recorded as partials while work continues to close them.
NIST does not issue certificates for these frameworks. The ASVS result is our self-assessment. External code review and penetration testing are planned after Early Access; ASVS strongly recommends them at Level 3 but does not require them. Releases include the Standards document, ASVS assessment, automated test reports, and a software bill of materials. These support the alignment claims; they do not establish independent certification.
Security controls enabled by default
TLS, encryption, least-privilege accounts, and detailed audit logging are enabled by default. Insecure options require an explicit, documented opt-in. Your organization remains responsible for securing its deployment.
- TLS by default — network connections use TLS 1.2+ (prefer 1.3), including MLLP-over-TLS. When a connected system can't speak TLS, plaintext is supported within your secure network perimeter.
- Encryption at rest, on by default — message bodies encrypted with AES-256-GCM in the store (SQLCipher / database-native).
- Routers and Handlers are version-controlled code stored outside the database. A database breach cannot rewrite those files. The message store uses encryption, role-based access control (RBAC), and audit records.
- The console and other clients access protected health information (PHI) through the authenticated, role-gated application programming interface (API). They have no privileged in-process store access.
- Deny-by-default RBAC — role-based, least-privilege access enforced on every action, with per-channel data-scope confinement.
- Tamper-evident audit — a timestamped, user-attributed audit log; no PHI or secrets in logs, ever.
- Fail-closed — errors fail safe; faults never leak stack traces or sensitive data.
- Secrets stay out of code — sourced from an environment / secret store, enforced by pre-commit and CI secret scanning; the git history is kept clean.
Authenticate operators and system connections
People sign in to the console and API; system connections carry their own credentials. Each uses the strongest mechanism available, recorded in the connection definition.
Operators (people)
- Local accounts — with built-in, required multi-factor authentication (MFA) — or Active Directory sign-in (LDAP), with opaque, revocable sessions and timeouts.
- Roles mapped to AD groups; deny-by-default, least-privilege RBAC on every action.
Connections (systems)
- Per-connection credentials — HTTP Basic over TLS or per-connection API keys — vaulted, scoped, rotated, and recorded.
- Mutual TLS (mTLS) client-certificate auth for connections that require it.
- An optional group-Managed Service Account (gMSA) can run the Windows service in Active Directory deployments. Active Directory rotates its password without storing it in config. That identity can also authenticate to the database. SQL authentication with a vaulted secret remains an alternative.
- TLS by default, including MLLP-over-TLS — with plaintext supported for endpoints that can't do TLS, inside your secure network perimeter.
- Per-connection IP allow-listing and network segmentation as defense-in-depth.
On the roadmap
- Passwordless Windows SSO — Kerberos / Integrated Windows Auth, so domain users sign in without a separate password.
- SSO federation via AD FS / Entra ID (OIDC / SAML) — so enterprise sign-in, and the MFA your organization's identity provider already enforces, flows through your existing IdP.
- OAuth 2.0 client-credentials and SMART on FHIR (Backend Services) for connections that require them.
Credentials and keys belong in a secret store, never in code or config. Apply per-connection least privilege, IP allow-listing, and network segmentation. TLS is the default; plaintext exceptions require a secure network perimeter.
Clear about who owns what
The project maintains the software and its security practices. Your organization manages the deployment, access, keys, and compliance program.
MessageFoundry (the project)
- Secure development practices and secure-by-default configuration.
- Security testing and self-attestation of the software.
- Vulnerability response and coordinated disclosure.
- Documentation, evidence, and published self-attestations.
Your organization (the deployer)
- Your environment, host, and network security.
- Identity, credential, and key management in your environment.
- Backups, disaster recovery, and availability.
- Your HIPAA program — risk analysis, Business Associate Agreements, and the deployment's compliance.
The software supports a HIPAA-compliant deployment; it does not make your organization compliant on its own. Use our security self-attestation as evidence in your own assessment. It does not replace that assessment.
Safeguards, mapped to what the software does
Technical safeguards from the HIPAA Security Rule (via NIST SP 800-66 Rev. 2), and how MessageFoundry implements them.
| HIPAA safeguard | How MessageFoundry implements it |
|---|---|
| Access control — unique ID, authn, auto-logoff | Authenticated, role-based, least-privilege access with session controls and timeouts |
| Audit controls | Tamper-evident, timestamped audit log; no sensitive data in logs |
| Integrity | Input validation; durable, ordered processing of messages |
| Transmission security | TLS by default for network transport (including MLLP-over-TLS) |
| Encryption (at rest & in transit) | Encryption at rest on by default, and TLS in transit |
| Administrative & physical | The deployer's environment and program — supported with evidence, not replaced |
Provenance you can verify
Releases include versioned, Sigstore-signed wheels, build provenance, and a software bill of materials (SBOM). Use these records to verify the package source and build.
- Each release is an immutable
messagefoundry==X.Y.Zwheel. The build fails unless its version matches the release tag. - Every wheel includes SLSA build provenance, Sigstore keyless signatures, and a CycloneDX SBOM, plus PEP 740 attestations on PyPI. These bind the package to its source commit and build system. Verify them before installing, for example with
gh attestation verify. - Token-less publishing — releases are published to PyPI through OIDC-based Trusted Publishing, with no long-lived token to steal.
- Reproducible installs — pin a fully hash-locked dependency set and install with
--require-hashes. - CI security gates — SAST, software-composition analysis, and secret scanning run on every change; builds fail on new high / critical findings.
- Reviewed, protected code — branch protection, blocking automated review, signed commits, and no direct commits to main; a published
SECURITY.mdwith a private reporting channel feeds tracked, coordinated disclosure. - No real PHI in development — synthetic or de-identified data only, on disk-encrypted developer machines.
Found a vulnerability? Report it privately.
Use the private reporting channel for security flaws. The response targets below cover acknowledgement, triage, and remediation.
How to report
Please don't open a public issue for a vulnerability. Use the private channel below — a report there stays visible only to maintainers until a fix ships.
- What to include — the affected component (MLLP or file transport, store, API and auth, console), the impact, and reproduction steps or a proof of concept.
- No real PHI, ever — use synthetic HL7; the
messagefoundry generatecorpus is ideal. - Check it against current
main— the project is pre-1.0 and moving quickly, so the latestmainis what we support and fix against. - No GitHub account? Email security@messagefoundry.org. Plain email isn't encrypted end-to-end — send a short notice and we'll open a private channel for the detail.
What happens next
We aim to acknowledge reports within a few business days, then triage by severity. Remediation targets below start at triage. We verify fixes before closing reports.
- Critical — remediated within 7 days.
- High — within 30 days.
- Medium — within 90 days.
- Low — best-effort.
For third-party dependencies, remediation targets start when an upstream fix exists. Priority follows active exploitation and likelihood: CISA KEV first, then EPSS, rather than CVSS severity scores alone.
We ask for time to ship a fix before public disclosure and agree the timing with you. Once a fix is available, we publish details and credit you by name if you wish.
Send ordinary bugs, questions, and feature requests to GitHub Issues or the contact form.
Review the published evidence
Review the Secure Development Standards, assessment records, and release evidence. The source code is also public.
- Each release includes SSDF self-attestation, testing evidence for NIST 800-115, the ASVS 5.0 Level 3 assessment of all 345 requirements, and HIPAA control mappings.
- Independent external code review and penetration test — planned after Early Access; Early Access has not yet been externally audited.
- A claims register records each published claim, its wording, and the evidence behind it.
- Not a NIST certificate — displayable certifications (SOC 2, ISO 27001, HITRUST) are a separate, organization-level track.
The assurance roadmap
The current assessment is internal. Independent review and organization-level assurance work are planned as the project develops.
Independent validation
ASVS strongly recommends external review at Level 3.
- External code review — a third-party security firm reviews the source against the same standard we self-assessed.
- Penetration test — an independent test of a real deployment, with the results summarized for adopters.
Both are planned after Early Access. The current release has not been externally audited. Sponsorship funds this work.
Why not SOC 2 or HITRUST yet?
Because those certify an organization, not a piece of software. SOC 2 Type II and HITRUST attest that an operating company ran a defined set of controls over a period of time — they presume a staffed company, an audit window, and a recurring budget.
MessageFoundry is an open-source project in Early Access. Current evidence covers software controls, the ASVS Level 3 self-assessment, and signed builds. SOC 2, HITRUST, and ISO 27001 are on a separate organization-level track, funded through sponsorship.
Frequently asked questions
Is MessageFoundry HIPAA compliant?
HIPAA compliance depends on your whole deployment. MessageFoundry provides authenticated access, audit records, TLS transport, and AES-256-GCM encryption for stored message bodies. Controls map to the HIPAA Security Rule through NIST 800-66. Your organization manages the environment, destinations, and compliance program. Plaintext transport exceptions require a secure network perimeter.
Is MessageFoundry PHI-safe — where does patient data live?
The engine and message store run on your servers or in your private cloud. You control the destinations your interfaces send data to. The engine does not send message contents as telemetry.
Is MessageFoundry self-hosted and on-premises?
Yes. Install the engine on your servers or in your private cloud. It starts with SQLite and also supports PostgreSQL and SQL Server. You control its network connections and message destinations.
How does MessageFoundry encrypt data?
Network connections default to TLS 1.2+, with TLS 1.3 preferred, including MLLP-over-TLS. Older endpoints can use plaintext within your secure network perimeter. Stored message bodies use AES-256-GCM encryption. These controls support your deployment's security assessment.
Has MessageFoundry been independently security audited?
MessageFoundry publishes an OWASP ASVS 5.0 Level 3 self-assessment covering all 345 requirements. Partially met requirements are recorded as partials. Independent code review and penetration testing are planned after Early Access.
How do I report a security vulnerability?
Use a GitHub private security advisory, not a public issue. Reports stay visible only to maintainers until a fix ships. Include the affected component, impact, and reproduction steps using synthetic HL7. Never include real PHI. We aim to acknowledge within a few business days and remediate critical issues within 7 days of triage.
Evaluating MessageFoundry for PHI?
Start with the Standards, the code, and the evidence — then bring us your security team's questions.