-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathsecurity.html
More file actions
512 lines (494 loc) · 37.1 KB
/
Copy pathsecurity.html
File metadata and controls
512 lines (494 loc) · 37.1 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Security, standards & HIPAA — MessageFoundry</title>
<meta name="description" content="Secure by default — TLS in transit, AES-256-GCM at rest, MFA, RBAC and audit, mapped to the HIPAA Security Rule, with an OWASP ASVS 5.0 L3 self-assessment.">
<link rel="canonical" href="https://messagefoundry.org/security.html">
<link rel="icon" href="/assets/img/favicon.svg" type="image/svg+xml">
<meta name="theme-color" content="#0b1220">
<meta property="og:type" content="website">
<meta property="og:site_name" content="MessageFoundry">
<meta property="og:title" content="Security, standards & HIPAA — MessageFoundry">
<meta property="og:description" content="Built to NIST SSDF, security testing per 800-115, controls mapped to the HIPAA Security Rule (800-66), and self-assessed against OWASP ASVS 5.0 Level 3 — secure by default. Early Access; external audit planned.">
<meta property="og:url" content="https://messagefoundry.org/security.html">
<meta property="og:image" content="https://messagefoundry.org/assets/img/og.png">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:type" content="image/png">
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:image" content="https://messagefoundry.org/assets/img/og.png">
<link rel="stylesheet" href="/assets/css/styles.css">
</head>
<body>
<a class="skip-link" href="#main">Skip to content</a>
<div class="eabar" role="region" aria-label="Project status">
<div class="container">
<p><strong>Early Access · beta.</strong> We're building toward 1.0 — and we want people involved now, while it can still be shaped. <a href="/status.html">Where the project stands →</a></p>
</div>
</div>
<header class="site-header">
<div class="container header-inner">
<a class="brand" href="/" aria-label="MessageFoundry home">
<img class="brand-mark" src="/assets/img/logo.svg" alt="" width="28" height="28">
<span class="brand-name">Message<span class="brand-accent">Foundry</span><span class="brand-tm">™</span></span>
</a>
<button class="nav-toggle" aria-expanded="false" aria-controls="site-nav" aria-label="Toggle navigation"><span></span><span></span><span></span></button>
<nav class="site-nav" id="site-nav">
<div class="nav-group">
<button type="button" class="nav-group__btn" aria-expanded="false" aria-haspopup="true" aria-controls="nav-product">Product</button>
<div class="nav-group__menu" id="nav-product">
<a href="/overview.html">Overview</a>
<a href="/features.html">Features</a>
<a href="/features-table.html">Feature list</a>
<a href="/architecture.html">Architecture</a>
<a href="/reliability.html">Reliability (CI)</a>
<a href="/tools.html">Tools</a>
<a href="/editor.html">Editor</a>
<a href="/console.html">Console</a>
<a href="/ai.html">AI assist</a>
</div>
</div>
<a href="/security.html" class="active" aria-current="page">Security</a>
<a href="/comparison.html">Comparison</a>
<div class="nav-group">
<button type="button" class="nav-group__btn" aria-expanded="false" aria-haspopup="true" aria-controls="nav-getstarted">Get started</button>
<div class="nav-group__menu" id="nav-getstarted">
<a href="/getting-started.html">Quickstart</a>
<a href="/guides/">Guides</a>
<a href="/documents.html">Documents</a>
</div>
</div>
<div class="nav-group">
<button type="button" class="nav-group__btn" aria-expanded="false" aria-haspopup="true" aria-controls="nav-company">About Us</button>
<div class="nav-group__menu" id="nav-company">
<a href="/about.html">About</a>
<a href="/status.html">Project status</a>
<a href="/licensing.html">Licensing</a>
<a href="/contact.html">Contact</a>
<a href="/sponsor.html">Sponsor</a>
</div>
</div>
<a class="btn btn-ghost" href="/pypi.html">PyPI<svg width="15" height="15" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.8" stroke-linecap="round" stroke-linejoin="round" aria-hidden="true"><path d="M12 3l8 4.5l0 9l-8 4.5l-8 -4.5l0 -9l8 -4.5"/><path d="M12 12l8 -4.5"/><path d="M12 12l0 9"/><path d="M12 12l-8 -4.5"/><path d="M16 5.25l-8 4.5"/></svg></a>
<a class="btn btn-ghost" href="https://github.com/MEFORORG/MessageFoundry" target="_blank" rel="noopener">GitHub ↗</a>
</nav>
</div>
</header>
<main id="main">
<!-- hero -->
<section class="section section--dark section--tight">
<div class="container center">
<span class="eyebrow">Security & PHI</span>
<h1 style="max-width:24ch;margin-inline:auto">Engineered for PHI — and built to recognized standards</h1>
<p class="lead">For a healthcare interface engine, security isn't a feature — it's the foundation. MessageFoundry is built to a published <b>Secure Development Standard</b> and aligned with the frameworks a CISO already trusts: <b>NIST SSDF</b>, <b>NIST 800-66 Rev. 2</b> (the HIPAA Security Rule), and <b>OWASP ASVS 5.0 Level 3</b>. It's secure by default, encrypted in transit and at rest, and clear about who's responsible for what. MessageFoundry is <a href="/self-hosted/">self-hosted and PHI-safe</a>.</p>
<div class="btn-row">
<a class="btn btn-primary" href="/assets/MessageFoundry-Secure-Development-Standards.pdf" target="_blank" rel="noopener">Read the Secure Development Standards (PDF)</a>
<a class="btn btn-secondary" href="#controls">See the controls →</a>
</div>
</div>
</section>
<!-- standards -->
<section class="section">
<div class="container">
<div class="center" style="margin-bottom:40px">
<span class="eyebrow">Built to recognized standards</span>
<h2>Mapped to the frameworks your auditors use</h2>
<p class="lead center">Four bodies of work answer four questions — how it's built, how it's tested, what controls it implements, and the application-security bar it's built to.</p>
</div>
<div class="grid grid-2 grid--top">
<div class="card">
<h3>NIST SSDF — built securely</h3>
<p>The secure software development lifecycle follows <b>NIST SP 800-218 (SSDF)</b> across all four practice groups — prepare, protect, produce, and respond — with threat modeling per interface, automated review, and secure-by-default design.</p>
</div>
<div class="card">
<h3>NIST 800-115 — tested in CI</h3>
<p>Security testing follows <b>NIST SP 800-115</b>: automated SAST, software-composition analysis, and secret-scanning on every build, plus a full functional and integration suite exercised against the running engine. Dynamic testing is <b>limited to an automated authorization sweep</b> — on every build, a live instance is probed over a real network socket to confirm that gated endpoints refuse unauthenticated and under-privileged callers. It does not cover the non-HTTP ingress listeners, the browser console, or TLS, and <b>no independent DAST, external code review, or penetration test has been performed</b> — all planned after Early Access.</p>
</div>
<div class="card">
<h3>NIST 800-66 Rev. 2 — HIPAA-mapped</h3>
<p>Implemented controls are mapped to the <b>HIPAA Security Rule via NIST SP 800-66 Rev. 2</b> — access control, audit, integrity, and transmission security.</p>
</div>
<div class="card">
<h3>OWASP ASVS 5.0 Level 3 — self-assessed</h3>
<p>Scoped chapter-by-chapter against <b>OWASP ASVS 5.0 Level 3</b> — the highest assurance level, for applications that handle the most sensitive data — with every exclusion documented and justified. All <b>345</b> Level 3 requirements are assessed. Where a requirement is still only partially met we record it as a partial and ship a control to close it, rather than writing a justification that reclassifies it as passed or not-applicable.</p>
</div>
</div>
<div class="callout" style="margin-top:26px">
<p><strong>Honest by design.</strong> NIST doesn't issue certificates for these frameworks, so we don't claim one — and the ASVS Level 3 result is our own <b>self-assessment</b>, not a third-party audit. In Early Access the software hasn't yet had an external code review or penetration test — which ASVS strongly recommends at Level 3 but does not require. These are <b>alignment claims backed by evidence</b> — the Standards document, that ASVS self-assessment, CI test reports, and an SBOM, published with our releases. "Built to," "self-assessed," "mapped to" — never "certified."</p>
</div>
</div>
</section>
<!-- secure by default -->
<section class="section section--alt" id="controls">
<div class="container grid grid-2" style="align-items:center">
<div>
<span class="eyebrow">Secure by default</span>
<h2>The safe configuration is the default one</h2>
<p class="lead">You don't have to harden it — it ships hardened. TLS is on, encryption is on, accounts are least-privilege, and audit logging is verbose out of the box. Insecure options require an explicit, documented opt-in.</p>
</div>
<ul class="feature-list">
<li><b>TLS by default</b> — network connections use TLS 1.2+ (prefer 1.3), including <b>MLLP-over-TLS</b>. When a connected system can't speak TLS, plaintext is supported within your secure network perimeter.</li>
<li><b>Encryption at rest, on by default</b> — message bodies encrypted with <b>AES-256-GCM</b> in the store (SQLCipher / database-native).</li>
<li><b>Logic can't be injected through the data layer</b> — Routers and Handlers are version-controlled code, never stored in the database. A data-layer breach (SQL injection, stolen DB credentials) reaches data that's already encrypted, RBAC-gated, and audited — but it can't change what the engine does.</li>
<li><b>One audited door</b> — the console and every other client reach the engine and its PHI only through the authenticated, RBAC-gated API; nothing holds a privileged in-process backdoor to the store.</li>
<li><b>Deny-by-default RBAC</b> — role-based, least-privilege access enforced on every action, with per-channel data-scope confinement.</li>
<li><b>Tamper-evident audit</b> — a timestamped, user-attributed audit log; <b>no PHI or secrets in logs</b>, ever.</li>
<li><b>Fail-closed</b> — errors fail safe; faults never leak stack traces or sensitive data.</li>
<li><b>Secrets stay out of code</b> — sourced from an environment / secret store, enforced by pre-commit and CI secret scanning; the git history is kept clean.</li>
</ul>
</div>
</section>
<!-- interface auth -->
<section class="section">
<div class="container">
<div class="center" style="margin-bottom:38px">
<span class="eyebrow">Authentication</span>
<h2>Real auth for operators and connections — not a shared password</h2>
<p class="lead center">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.</p>
</div>
<div class="grid grid-3 grid--top">
<div class="card">
<h3>Operators (people)</h3>
<ul class="feature-list" style="margin-top:12px">
<li><b>Local accounts</b> — with <b>built-in, required multi-factor authentication (MFA)</b> — or <b>Active Directory</b> sign-in (LDAP), with opaque, revocable sessions and timeouts.</li>
<li>Roles mapped to AD groups; deny-by-default, least-privilege RBAC on every action.</li>
</ul>
</div>
<div class="card">
<h3>Connections (systems)</h3>
<ul class="feature-list" style="margin-top:12px">
<li>Per-connection credentials — HTTP Basic over TLS or per-connection API keys — vaulted, scoped, rotated, and recorded.</li>
<li><b>Mutual TLS (mTLS)</b> client-certificate auth for connections that require it.</li>
<li><b>group-Managed Service Account (gMSA) — optional.</b> For Active Directory deployments, run the engine's Windows service under a gMSA so its password is AD-rotated and never stored in config, and use that identity for integrated database authentication. Not required — SQL authentication with a vaulted secret also works.</li>
<li><b>TLS by default</b>, including MLLP-over-TLS — with plaintext supported for endpoints that can't do TLS, inside your secure network perimeter.</li>
<li>Per-connection IP allow-listing and network segmentation as defense-in-depth.</li>
</ul>
</div>
<div class="card">
<h3>On the roadmap</h3>
<ul class="feature-list" style="margin-top:12px">
<li><b>Passwordless Windows SSO</b> — Kerberos / Integrated Windows Auth, so domain users sign in without a separate password.</li>
<li>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.</li>
<li><b>OAuth 2.0</b> client-credentials and <b>SMART on FHIR</b> (Backend Services) for connections that require them.</li>
</ul>
</div>
</div>
<div class="callout" style="margin-top:26px">
<p><strong>Across every mechanism:</strong> TLS by default, credentials and keys in a secret store (never in code or config), per-connection least privilege, and per-connection IP allow-listing / network segmentation as defense-in-depth.</p>
</div>
</div>
</section>
<!-- shared responsibility -->
<section class="section section--dark">
<div class="container">
<div class="center" style="margin-bottom:34px">
<span class="eyebrow">Shared responsibility</span>
<h2>Clear about who owns what</h2>
<p class="lead center">The software is built by one party and deployed by another. Stating the split plainly is itself a security control — neither side assumes the other has it covered.</p>
</div>
<div class="grid grid-2 grid--top">
<div class="card">
<h3>Message<span class="wordmark-accent">Foundry</span> (the project)</h3>
<ul class="feature-list" style="margin-top:12px">
<li>Secure development practices and secure-by-default configuration.</li>
<li>Security testing and self-attestation of the software.</li>
<li>Vulnerability response and coordinated disclosure.</li>
<li>Documentation, evidence, and published self-attestations.</li>
</ul>
</div>
<div class="card">
<h3>Your organization (the deployer)</h3>
<ul class="feature-list" style="margin-top:12px">
<li>Your environment, host, and network security.</li>
<li>Identity, credential, and key management in your environment.</li>
<li>Backups, disaster recovery, and availability.</li>
<li>Your HIPAA program — risk analysis, Business Associate Agreements, and the deployment's compliance.</li>
</ul>
</div>
</div>
<div class="callout callout--on-dark" style="margin-top:28px;background:rgba(245,158,11,.07);border-color:rgba(245,158,11,.28);color:var(--muted-dk)">
<p><strong style="color:var(--accent)">Said plainly.</strong> The software <b>supports a HIPAA-compliant deployment</b> — it doesn't make you compliant on its own. Our self-attestation that the software was built securely is evidence for <em>your</em> assessment, not a substitute for it.</p>
</div>
</div>
</section>
<!-- hipaa mapping -->
<section class="section section--alt">
<div class="container">
<div class="center" style="margin-bottom:30px">
<span class="eyebrow">HIPAA Security Rule</span>
<h2>Safeguards, mapped to what the software does</h2>
<p class="lead center">Technical safeguards from the HIPAA Security Rule (via NIST SP 800-66 Rev. 2), and how MessageFoundry implements them.</p>
</div>
<div class="table-wrap">
<table class="cmp">
<thead>
<tr><th scope="col">HIPAA safeguard</th><th scope="col">How MessageFoundry implements it</th></tr>
</thead>
<tbody>
<tr><th scope="row">Access control — unique ID, authn, auto-logoff</th><td>Authenticated, role-based, least-privilege access with session controls and timeouts</td></tr>
<tr><th scope="row">Audit controls</th><td>Tamper-evident, timestamped audit log; no sensitive data in logs</td></tr>
<tr><th scope="row">Integrity</th><td>Input validation; durable, ordered processing of messages</td></tr>
<tr><th scope="row">Transmission security</th><td>TLS by default for network transport (including MLLP-over-TLS)</td></tr>
<tr><th scope="row">Encryption (at rest & in transit)</th><td>Encryption at rest on by default, and TLS in transit</td></tr>
<tr><th scope="row">Administrative & physical</th><td><em>The deployer's environment and program</em> — supported with evidence, not replaced</td></tr>
</tbody>
</table>
</div>
</div>
</section>
<!-- secure sdlc -->
<section class="section">
<div class="container grid grid-2" style="align-items:center">
<div>
<span class="eyebrow">Secure SDLC & supply chain</span>
<h2>Provenance you can verify</h2>
<p class="lead">Open-source software is only as trustworthy as the pipeline that builds it. MessageFoundry ships as <b>versioned, Sigstore-signed wheels</b> with attested build provenance and an SBOM — integrity-verifiable releases that implement <b>NIST SSDF</b> and <b>SLSA</b> build-integrity controls, going beyond what <b>OWASP ASVS L3</b> requires.</p>
</div>
<ul class="feature-list">
<li><b>Versioned & immutable</b> — each release is a frozen <code>messagefoundry==X.Y.Z</code> wheel; the build fails unless the built version matches the release tag — not a branch that can be force-pushed under you.</li>
<li><b>Signed & attested</b> — every wheel ships with <b>SLSA build provenance</b>, <b>Sigstore</b> keyless signatures, and a <b>CycloneDX SBOM</b> (plus <b>PEP 740</b> attestations on PyPI), binding the artifact to the exact source commit and CI builder — so adopters can verify it (e.g. <code>gh attestation verify</code>) before installing.</li>
<li><b>Token-less publishing</b> — releases are published to PyPI through OIDC-based <b>Trusted Publishing</b>, with no long-lived token to steal.</li>
<li><b>Reproducible installs</b> — pin a fully hash-locked dependency set and install with <code>--require-hashes</code>.</li>
<li><b>CI security gates</b> — SAST, software-composition analysis, and secret scanning run on every change; builds fail on new high / critical findings.</li>
<li><b>Reviewed, protected code</b> — branch protection, blocking automated review, signed commits, and no direct commits to main; a published <a href="https://github.com/MEFORORG/MessageFoundry/security/policy" target="_blank" rel="noopener"><code>SECURITY.md</code></a> with a <a href="#report">private reporting channel</a> feeds tracked, coordinated disclosure.</li>
<li><b>No real PHI in development</b> — synthetic or de-identified data only, on disk-encrypted developer machines.</li>
</ul>
</div>
</section>
<!-- coordinated disclosure / report a vulnerability -->
<section class="section section--alt" id="report">
<div class="container">
<div class="center" style="margin-bottom:34px">
<span class="eyebrow">Coordinated disclosure</span>
<h2>Found a vulnerability? Report it privately.</h2>
<p class="lead center">A security flaw shouldn't have to be posted in public to reach us. MessageFoundry runs a private reporting channel with published response targets — report it confidentially, and we aim to have a fix out before any detail is public.</p>
</div>
<div class="grid grid-2 grid--top">
<div class="card">
<h3>How to report</h3>
<p><b>Please don't open a public issue for a vulnerability.</b> Use the private channel below — a report there stays visible only to maintainers until a fix ships.</p>
<ul class="feature-list" style="margin-top:18px">
<li><b>What to include</b> — the affected component (MLLP or file transport, store, API and auth, console), the impact, and reproduction steps or a proof of concept.</li>
<li><b>No real PHI, ever</b> — use synthetic HL7; the <code>messagefoundry generate</code> corpus is ideal.</li>
<li><b>Check it against current <code>main</code></b> — the project is pre-1.0 and moving quickly, so the latest <code>main</code> is what we support and fix against.</li>
<li><b>No GitHub account?</b> Email <a href="mailto:security@messagefoundry.org">security@messagefoundry.org</a>. Plain email isn't encrypted end-to-end — send a short notice and we'll open a private channel for the detail.</li>
</ul>
</div>
<div class="card">
<h3>What happens next</h3>
<p>We aim to acknowledge within a few business days, then triage by severity. These are our targets to remediate, measured from triage — and fixes are verified before a report is closed.</p>
<ul class="feature-list" style="margin-top:18px">
<li><b>Critical</b> — remediated within 7 days.</li>
<li><b>High</b> — within 30 days.</li>
<li><b>Medium</b> — within 90 days.</li>
<li><b>Low</b> — best-effort.</li>
</ul>
<p style="margin-top:18px">Vulnerabilities in <b>third-party dependencies</b> run on their own clock — measured from when an upstream fix exists — and are prioritized by real exploitation pressure (CISA KEV first, then EPSS) rather than CVSS alone.</p>
<p style="margin-top:18px"><b>Then we disclose together.</b> We ask for a reasonable window to ship a fix before any public detail, and we agree the timing with you. Details are published once a fix is available — with credit to you by name, if you want it.</p>
</div>
</div>
<div class="btn-row" style="margin-top:30px;justify-content:center">
<a class="btn btn-primary" href="https://github.com/MEFORORG/MessageFoundry/security/advisories/new" target="_blank" rel="noopener">Report a vulnerability ↗</a>
<a class="btn btn-ghost" href="https://github.com/MEFORORG/MessageFoundry/security/policy" target="_blank" rel="noopener">Read the policy ↗</a>
</div>
<div class="callout" style="margin-top:28px;background:rgba(245,158,11,.07);border-color:rgba(245,158,11,.28)">
<p><strong>Not a vulnerability?</strong> Ordinary bugs, questions, and feature requests are the opposite — they belong in the open, in <a href="https://github.com/MEFORORG/MessageFoundry/issues" target="_blank" rel="noopener">GitHub Issues</a> or via the <a href="/contact.html">contact form</a>. Keeping the private channel for genuine security flaws is what lets us hit the windows above.</p>
</div>
</div>
</section>
<!-- evidence / verify -->
<section class="section section--dark" id="evidence">
<div class="container grid grid-2" style="align-items:center">
<div>
<span class="eyebrow">Evidence & attestation</span>
<h2>Don't take our word — review the evidence</h2>
<p class="lead">We publish our Secure Development Standards and the evidence behind every claim, so your security team can review it directly. MessageFoundry is open source, so you can also read the code.</p>
<div class="btn-row">
<a class="btn btn-primary" href="/assets/MessageFoundry-Secure-Development-Standards.pdf" target="_blank" rel="noopener">Download the Standards (PDF) ↓</a>
<a class="btn btn-ghost" href="/documents.html#security">Security guides (PDFs) →</a>
<a class="btn btn-ghost" href="https://github.com/MEFORORG/MessageFoundry" target="_blank" rel="noopener">Read the source ↗</a>
</div>
</div>
<div>
<ul class="feature-list">
<li><b>Self-attested</b> SSDF-aligned, security-tested per 800-115, self-assessed against ASVS 5.0 Level 3 across all 345 requirements, and controls mapped to the HIPAA Security Rule (800-66) — published with each release.</li>
<li><b>Independent external code review and penetration test</b> — planned after Early Access; Early Access has not yet been externally audited.</li>
<li><b>A claims register</b> records each published claim, its wording, and the evidence behind it.</li>
<li><b>Not a NIST certificate</b> — displayable certifications (SOC 2, ISO 27001, HITRUST) are a separate, organization-level track.</li>
</ul>
</div>
</div>
</section>
<!-- assurance roadmap / what's next -->
<section class="section">
<div class="container">
<div class="center" style="margin-bottom:34px">
<span class="eyebrow">What's next</span>
<h2>The assurance roadmap</h2>
<p class="lead center">An OWASP ASVS Level 3 self-assessment is a high bar to hold ourselves to — but it's still <em>our</em> assessment. The next steps are independent validation and the formal, organization-level certifications a mature vendor carries. Here's where each stands, plainly.</p>
</div>
<div class="grid grid-2 grid--top">
<div class="card">
<h3>Independent validation</h3>
<p>ASVS strongly recommends an external review at Level 3 — and we agree it's the right next step.</p>
<ul class="feature-list" style="margin-top:12px">
<li><b>External code review</b> — a third-party security firm reviews the source against the same standard we self-assessed.</li>
<li><b>Penetration test</b> — an independent test of a real deployment, with the results summarized for adopters.</li>
</ul>
<p style="margin-top:12px">Both are <b>planned after Early Access</b> — today's release has not yet been externally audited. Sponsorship, not license fees, is what brings them forward.</p>
</div>
<div class="card">
<h3>Why not SOC 2 or HITRUST yet?</h3>
<p>Because those certify an <b>organization</b>, 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.</p>
<p style="margin-top:10px">MessageFoundry is an open-source project in Early Access. We've put the <em>software's</em> security on the record now — secure-by-default controls, the ASVS L3 self-assessment, and signed, attested builds — and the company-level marks come as the project matures. <b>SOC 2</b>, <b>HITRUST</b>, and <b>ISO 27001</b> sit on that organization-level track — funded, like the reviews, through sponsorship rather than license fees.</p>
</div>
</div>
<div class="center" style="margin-top:30px">
<a class="btn btn-primary" href="/sponsor.html">Sponsor MessageFoundry</a>
</div>
</div>
</section>
<!-- faq -->
<section class="section">
<div class="container">
<div class="center" style="margin-bottom:28px"><span class="eyebrow">FAQ</span><h2>Frequently asked questions</h2></div>
<div class="faq">
<div class="faq-item"><h3>Is MessageFoundry HIPAA compliant?</h3><p>HIPAA compliance is a property of your whole deployment, not any single product. MessageFoundry is built to support it: PHI stays on your own infrastructure, every operator is authenticated, access to patient data is audited, traffic is encrypted with TLS and message bodies with AES-256-GCM, and controls map to the HIPAA Security Rule (NIST 800-66).</p></div>
<div class="faq-item"><h3>Is MessageFoundry PHI-safe — where does patient data live?</h3><p>Yes. MessageFoundry is self-hosted, so PHI never leaves your infrastructure. There is no vendor cloud, no third-party processor, and no telemetry of message contents — you run the engine on your own servers, on-premises or in your own private cloud.</p></div>
<div class="faq-item"><h3>Is MessageFoundry self-hosted and on-premises?</h3><p>Yes. MessageFoundry runs entirely on your own servers, on-premises or in your private cloud. It installs from PyPI, starts zero-config on SQLite, and scales to PostgreSQL or SQL Server. Nothing is sent to a vendor service.</p></div>
<div class="faq-item"><h3>How does MessageFoundry encrypt data?</h3><p>TLS is enabled by default — network connections use TLS 1.2+ (TLS 1.3 preferred), including MLLP-over-TLS. Some older ancillary systems can't speak TLS; MessageFoundry also supports plaintext transport for those, which can still support a HIPAA-compliant deployment inside your organization's secure network perimeter. At rest, message bodies are encrypted with AES-256-GCM.</p></div>
<div class="faq-item"><h3>Has MessageFoundry been independently security audited?</h3><p>MessageFoundry publishes a self-assessment against OWASP ASVS 5.0 Level 3, covering all 345 requirements, plus its Secure Development Standards. Requirements that are still only partially met are recorded as partials and closed by shipping controls, not reclassified away. It has not yet had an independent external code review or penetration test — both are planned after Early Access.</p></div>
<div class="faq-item"><h3>How do I report a security vulnerability?</h3><p>Report it privately — please don't open a public issue. The preferred channel is a <a href="https://github.com/MEFORORG/MessageFoundry/security/advisories/new" target="_blank" rel="noopener">GitHub private security advisory</a> on the MessageFoundry repository, which stays visible only to maintainers until a fix is released. Include the affected component, the impact, and reproduction steps, using synthetic HL7 rather than real PHI. We aim to acknowledge within a few business days, and we target 7 days to remediate a critical issue.</p></div>
</div>
</div>
</section>
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Is MessageFoundry HIPAA compliant?",
"acceptedAnswer": {
"@type": "Answer",
"text": "HIPAA compliance is a property of your whole deployment, not any single product. MessageFoundry is built to support it: PHI stays on your own infrastructure, every operator is authenticated, access to patient data is audited, traffic is encrypted with TLS and message bodies with AES-256-GCM, and controls map to the HIPAA Security Rule (NIST 800-66)."
}
},
{
"@type": "Question",
"name": "Is MessageFoundry PHI-safe — where does patient data live?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Yes. MessageFoundry is self-hosted, so PHI never leaves your infrastructure. There is no vendor cloud, no third-party processor, and no telemetry of message contents — you run the engine on your own servers, on-premises or in your own private cloud."
}
},
{
"@type": "Question",
"name": "Is MessageFoundry self-hosted and on-premises?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Yes. MessageFoundry runs entirely on your own servers, on-premises or in your private cloud. It installs from PyPI, starts zero-config on SQLite, and scales to PostgreSQL or SQL Server. Nothing is sent to a vendor service."
}
},
{
"@type": "Question",
"name": "How does MessageFoundry encrypt data?",
"acceptedAnswer": {
"@type": "Answer",
"text": "TLS is enabled by default — network connections use TLS 1.2+ (TLS 1.3 preferred), including MLLP-over-TLS. Some older ancillary systems can't speak TLS; MessageFoundry also supports plaintext transport for those, which can still support a HIPAA-compliant deployment inside your organization's secure network perimeter. At rest, message bodies are encrypted with AES-256-GCM."
}
},
{
"@type": "Question",
"name": "Has MessageFoundry been independently security audited?",
"acceptedAnswer": {
"@type": "Answer",
"text": "MessageFoundry publishes a self-assessment against OWASP ASVS 5.0 Level 3, covering all 345 requirements, plus its Secure Development Standards. Requirements that are still only partially met are recorded as partials and closed by shipping controls, not reclassified away. It has not yet had an independent external code review or penetration test — both are planned after Early Access."
}
},
{
"@type": "Question",
"name": "How do I report a security vulnerability?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Report it privately — please don't open a public issue. The preferred channel is a GitHub private security advisory on the MessageFoundry repository, which stays visible only to maintainers until a fix is released. Include the affected component, the impact, and reproduction steps, using synthetic HL7 rather than real PHI. We aim to acknowledge within a few business days, and we target 7 days to remediate a critical issue."
}
}
]
}
</script>
<!-- cta -->
<section class="section section--tight">
<div class="container">
<div class="cta-band">
<h2>Evaluating Message<span class="wordmark-accent">Foundry</span> for PHI?</h2>
<p class="lead center" style="color:var(--muted-dk)">Start with the Standards, the code, and the evidence — then bring us your security team's questions.</p>
<div class="btn-row center">
<a class="btn btn-primary" href="/getting-started.html">Get started</a>
<a class="btn btn-ghost" href="/contact.html">Ask a question</a>
</div>
</div>
</div>
</section>
</main>
<footer class="site-footer">
<div class="container">
<div class="footer-grid">
<div class="footer-brand">
<a class="brand" href="/" aria-label="MessageFoundry home">
<img class="brand-mark" src="/assets/img/logo.svg" alt="" width="28" height="28">
<span class="brand-name">Message<span class="brand-accent">Foundry</span><span class="brand-tm">™</span></span>
</a>
<p class="footer-tagline"><b>More</b> Than an HL7 Interface Engine</p>
<p>Open-source healthcare interface engine — secure by default, built to recognized standards, connecting a wide range of protocols and message types.</p>
<div class="badge-row" style="margin-top:16px">
<span class="badge">Open source</span>
<span class="badge">No lock-in</span>
<span class="badge">Self-hosted</span>
</div>
</div>
<div class="footer-col">
<h4>Product</h4>
<a href="/overview.html">Overview</a>
<a href="/features.html">Features</a>
<a href="/architecture.html">Architecture</a>
<a href="/reliability.html">Reliability</a>
<a href="/dicom.html">DICOM</a>
<a href="/security.html">Security & PHI</a>
<a href="/documents.html">Documents</a>
</div>
<div class="footer-col">
<h4>Tools</h4>
<a href="/tools.html">Tools</a>
<a href="/editor.html">Editor</a>
<a href="/console.html">Console</a>
<a href="/ai.html">AI assist</a>
</div>
<div class="footer-col">
<h4>Get started</h4>
<a href="/getting-started.html">Quickstart</a>
<a href="/guides/">Guides</a>
<a href="/comparison.html">Comparison</a>
</div>
<div class="footer-col">
<h4>Project</h4>
<a href="/status.html">Project status</a>
<a href="https://github.com/MEFORORG/MessageFoundry" target="_blank" rel="noopener">GitHub</a>
<a href="https://github.com/MEFORORG/MessageFoundry/issues" target="_blank" rel="noopener">Issues</a>
<a href="/contact.html">Contact</a>
<a href="/licensing.html">License</a>
<a href="/about.html">About</a>
<a href="/sponsor.html">Sponsor</a>
</div>
</div>
<div class="footer-bottom">
<span>© 2026 MEFOR-ORG, a non-profit — this website and its content, all rights reserved. The MessageFoundry engine is separately open source, licensed under AGPL-3.0-or-later.</span>
<span>MessageFoundry and the MessageFoundry word mark are trademarks of MEFOR-ORG. Mirth Connect, Cloverleaf, Rhapsody, Corepoint, and Ensemble are trademarks of their respective owners; MessageFoundry is independent and unaffiliated.</span>
</div>
</div>
</footer>
<script src="/assets/js/nav.js" defer></script>
</body>
</html>