VARASYS/ZDDC-website
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs: federal compliance page (federal.html) + home-page cross-links

Browse source 
A non-technical entry point for federal evaluators answering "can this
go in our environment, and what would need to be added during ATO?" —
the question that today only has an answer buried in the engineering
README.

Six sections, written for the procurement / decision-maker audience
with engineers as the secondary reader:

  1. Hero: ZDDC is designed to be deployed in regulated environments.
  2. What's already in place — hardened TLS posture, pluggable OPA
     policy engine, federal-mode strict-least-privilege Rego, audit
     logging, vulnerability-disclosure policy, documented access-
     control model with a 5-minute verify-it recipe.
  3. Supported deployment shape — diagram showing zddc-server on
     loopback behind a TLS-terminating proxy on a RHEL/UBI base.
  4. What you'd add for full ATO — table of five integration items
     (FIPS-validated crypto, authenticated proxy↔server channel, RBAC,
     policy export, code-signed tool fetches) with plain-language
     summaries.
  5. The two-track build plan — explains why the standard binary
     stays pure-Go and a parallel zddc-server-fips build is the right
     answer for federal customers.
  6. Engineering reference — links into the in-repo gap analysis,
     ARCHITECTURE.md security section, and access-control reference
     for implementors.

Linked from index.html in two places: a new feature bullet on the
zddc-server (optional) section pointing at the page, and a "For
federal evaluators" entry in the Learn-more list at the bottom.

No engineering content here — federal.html is the procurement entry
point. The deeper detail (NIST control numbers, library choices,
effort estimates) lives in zddc/README.md § Federal-readiness gap
analysis where engineers will look for it.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
ZDDC 2026-05-04 21:33:16 -05:00
parent d2e8a913d1
commit 90aca07539
2 changed files with 165 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

163
federal.html Normal file
View file

@ -0,0 +1,163 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Federal Compliance — Zero Day Document Control (ZDDC)</title>
<meta name="description" content="ZDDC is designed to be deployed in regulated environments — including US federal. Here's what's already in place, what we'd add when a customer engages on ATO, and the supported deployment shape.">
<meta property="og:type" content="website">
<meta property="og:url" content="https://zddc.varasys.io/federal.html">
<meta property="og:title" content="Federal Compliance — ZDDC">
<meta property="og:description" content="Federally-deployable design with a clear ATO path.">
<meta name="theme-color" content="#2a5a8a">
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Inter:wght@400;500;600;700;800&display=swap" rel="stylesheet">
<link rel="stylesheet" href="css/style.css">
</head>
<body>
<!-- Header -->
<header class="site-header">
<div class="container header-content">
<a href="/" class="brand">
<svg class="brand-logo" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 64 64" aria-hidden="true">
<rect width="64" height="64" rx="12" fill="#1e3a5f"/>
<g fill="#fff">
<rect x="14" y="18" width="36" height="7"/>
<polygon points="43,25 50,25 21,43 14,43"/>
<rect x="14" y="43" width="36" height="7"/>
</g>
</svg>
<span class="brand-name">ZDDC</span>
</a>
<nav class="header-nav">
<a href="/" class="nav-link">Home</a>
<a href="reference.html" class="nav-link">Docs</a>
<a href="releases/" class="nav-link">Releases</a>
</nav>
</div>
</header>
<!-- Hero -->
<section class="hero">
<div class="container">
<h1>Federal Compliance</h1>
<p class="hero-subtitle">ZDDC is designed to be deployed in regulated environments — including US federal. The system's trust boundaries, configuration model, and audit surface were chosen with ATO in mind. This page walks through what's already in place, what an integrator would add when a customer engages on accreditation, and the supported deployment shape.</p>
</div>
</section>
<main class="container" style="margin-bottom: var(--spacing-2xl);">
<!-- ────────────── What's already in place ────────────── -->
<section class="card" style="background: var(--color-bg-subtle); border: 1px solid var(--color-border); border-radius: var(--radius-md); padding: var(--spacing-lg) var(--spacing-xl); margin-top: var(--spacing-lg);">
<h2 style="margin-top:0;">What's already in place</h2>
<p>These controls ship in every release today. No federal-specific build required to use them.</p>
<ul class="feature-list">
<li><strong>Hardened TLS posture.</strong> The TLS 1.2 cipher suite list, curve preferences, and HSTS header are pinned to the federal TLS guidance (NIST SP 800-52 Rev. 2). Only AEAD ciphers; only forward-secret key exchanges; only modern curves. Weak suites cannot be negotiated even if a client offers them.</li>
<li><strong>Pluggable policy engine.</strong> Access decisions can be delegated to an external <a href="https://www.openpolicyagent.org/" rel="noopener">Open Policy Agent</a> server with the customer's own audited Rego rules. The default in-process engine and the OPA-delegated engine speak the same wire format, so customers swap by setting one environment variable.</li>
<li><strong>Strict-least-privilege policy variant available out of the box.</strong> A parity-tested federal-mode Rego that enforces NIST AC-6 (parent denies are absolute; no leaf-level override) ships embedded in the binary. <code>zddc-server --print-rego=federal</code> emits it for use with the customer's OPA.</li>
<li><strong>Structured audit logging.</strong> Every request is logged with the authenticated email, method, path, status, response size, and duration. Logs are JSON-line, ready for fluentd / Vector / SIEM pipelines.</li>
<li><strong>Documented vulnerability-disclosure process.</strong> A <a href="https://codeberg.org/VARASYS/ZDDC/src/branch/main/SECURITY.md">SECURITY.md</a> covering supported versions, reporting channel, response timeline, embargo workflow, and CVE assignment.</li>
<li><strong>Cascading access control with explicit trust boundaries.</strong> The <code class="inline">.zddc</code> ACL model has documented invariants — root-only admin escalation gate, subtree-author authority limited to their subtree, default-deny when any <code class="inline">.zddc</code> exists. The <a href="https://codeberg.org/VARASYS/ZDDC/src/branch/main/zddc/README.md#access-control-the-zddc-cascade">access-control reference</a> includes a five-minute verify-it recipe a security reviewer can run on their own deployment.</li>
</ul>
</section>
<!-- ────────────── Supported deployment shape ────────────── -->
<section class="card" style="border: 1px solid var(--color-border); border-radius: var(--radius-md); padding: var(--spacing-lg) var(--spacing-xl); margin-top: var(--spacing-xl);">
<h2 style="margin-top:0;">Supported deployment shape</h2>
<p>Federal-track deployments run zddc-server <strong>on loopback only</strong>, fronted by a TLS-terminating proxy. The proxy handles authentication (PIV/CAC via the customer's IdP), terminates TLS using a FIPS-validated module, and forwards plaintext to zddc-server over the local interface. zddc-server stays small, lean, and focused on file-tree access decisions; the proxy is where federal-mandated cryptographic boundaries live.</p>
<pre style="font-family: ui-monospace, SFMono-Regular, monospace; font-size: 0.85rem; background: var(--color-bg); padding: var(--spacing-md); border-radius: var(--radius-sm); overflow-x: auto;">
PIV/CAC user
│
▼
┌──────────────────────┐ (FIPS-validated TLS termination,
│ oauth2-proxy / │ OCSP stapling, MFA, session mgmt)
│ nginx-FIPS / │
│ stunnel-FIPS │
└──────────────────────┘
│ loopback (HTTP, mTLS or signed JWT)
▼
┌──────────────────────┐ (Per-directory ACL via .zddc;
│ zddc-server │ OPA-delegated for AC-6 strict;
│ on 127.0.0.1:8080 │ structured access log to stdout)
└──────────────────────┘
│
▼
/srv/zddc (RHEL/UBI volume, encrypted at rest by the platform)</pre>
<p style="margin-top: var(--spacing-md);">The base image for the federal track is RHEL UBI 9 or equivalent (Rocky 9, Ubuntu Pro 22.04+) with the OS-level FIPS mode enforced kernel-side. Encryption at rest is delegated to the deployment platform (cloud KMS, LUKS, dm-crypt). Audit logs ship from the proxy and zddc-server's stdout to the customer's SIEM via the orchestrator's normal log pipeline.</p>
<p>This isn't a new architecture — it's the standard "small focused service behind a hardened proxy" shape that DoD reference designs already prefer. zddc-server's job is to be the small focused service.</p>
</section>
<!-- ────────────── What you'd add ────────────── -->
<section class="card" style="border: 1px solid var(--color-border); border-radius: var(--radius-md); padding: var(--spacing-lg) var(--spacing-xl); margin-top: var(--spacing-xl);">
<h2 style="margin-top:0;">What you'd add for full ATO</h2>
<p>None of these are forever-open questions; each is a roadmap-able piece of work that an integrator builds when a customer engages on accreditation. Engineering detail for each item lives in the <a href="https://codeberg.org/VARASYS/ZDDC/src/branch/main/zddc/README.md#federal-readiness-gap-analysis">federal-readiness gap analysis</a>.</p>
<table style="width: 100%; border-collapse: collapse; margin-top: var(--spacing-md);">
<thead>
<tr style="border-bottom: 2px solid var(--color-border);">
<th style="text-align: left; padding: var(--spacing-sm); font-weight: 700;">What</th>
<th style="text-align: left; padding: var(--spacing-sm); font-weight: 700;">Plain-language summary</th>
</tr>
</thead>
<tbody>
<tr style="border-bottom: 1px solid var(--color-border);">
<td style="padding: var(--spacing-sm); vertical-align: top;"><strong>FIPS-validated cryptography</strong></td>
<td style="padding: var(--spacing-sm); vertical-align: top;">A separate <code class="inline">zddc-server-fips</code> binary built with Microsoft's FIPS-aware Go toolchain on a RHEL/UBI base. The validated cryptography belongs to the OS-level OpenSSL FIPS module; this binary uses it. See the two-track build plan below.</td>
</tr>
<tr style="border-bottom: 1px solid var(--color-border);">
<td style="padding: var(--spacing-sm); vertical-align: top;"><strong>Authenticated proxy↔server channel</strong></td>
<td style="padding: var(--spacing-sm); vertical-align: top;">Today the proxy and zddc-server trust each other via network isolation. For federal, the recommended path is a signed forwarding token (JWT) — proxy signs each request with its private key, zddc-server verifies with the published public key. mTLS available as an alternative when the customer already operates a private CA.</td>
</tr>
<tr style="border-bottom: 1px solid var(--color-border);">
<td style="padding: var(--spacing-sm); vertical-align: top;"><strong>Role-based access control</strong></td>
<td style="padding: var(--spacing-sm); vertical-align: top;">The current <code class="inline">.zddc</code> model grants access by email pattern. Federal AC-3(7) wants role-based grants populated from the customer's identity provider. The cascade syntax extends to express role allow/deny alongside email allow/deny; roles flow through the same OPA hook so customers running their own Rego pick them up automatically.</td>
</tr>
<tr style="border-bottom: 1px solid var(--color-border);">
<td style="padding: var(--spacing-sm); vertical-align: top;"><strong>Policy export for change control</strong></td>
<td style="padding: var(--spacing-sm); vertical-align: top;">A command that walks the served tree and emits every directory's resolved access policy in JSON / Markdown / CSV. The change-control workflow checks the export into a Git repo; every <code class="inline">.zddc</code> change produces a diff that reviewers approve before deploy. NIST CM-3.</td>
</tr>
<tr>
<td style="padding: var(--spacing-sm); vertical-align: top;"><strong>Code-signed tool fetches</strong></td>
<td style="padding: var(--spacing-sm); vertical-align: top;">When a <code class="inline">.zddc</code> file pins a tool to a URL, zddc-server today fetches and caches it with no integrity check. The federal answer is code signing: the release pipeline signs every published artifact once with a long-lived key; zddc-server verifies signatures before caching. The operator trusts a published public key once and never deals with hashes — no per-artifact tracking burden.</td>
</tr>
</tbody>
</table>
</section>
<!-- ────────────── The two-track build plan ────────────── -->
<section class="card" style="border: 1px solid var(--color-border); border-radius: var(--radius-md); padding: var(--spacing-lg) var(--spacing-xl); margin-top: var(--spacing-xl);">
<h2 style="margin-top:0;">The two-track build plan</h2>
<p>Federal evaluators sometimes ask a perfectly reasonable question: "Does the standard zddc-server binary use FIPS-validated cryptography?" The answer is no, and that's by design.</p>
<p>FIPS validation is a property of the cryptographic module — typically the OS-level OpenSSL FIPS package shipped by Red Hat or Canonical, certified by NIST and tracked by certificate number. Building with the Microsoft FIPS-aware Go toolchain is what lets a Go program use that validated module instead of Go's stdlib crypto. But it requires linking against the host's OpenSSL, which:</p>
<ul class="feature-list">
<li>Eliminates the "single static binary" property of the standard build (validated OpenSSL must be present at runtime)</li>
<li>Ties the deployment to a RHEL/UBI-class OS (validated OpenSSL packages exist there; not on macOS or Windows)</li>
<li>Gains nothing for the ~95% of customers who don't need a FIPS certificate to procure the system</li>
</ul>
<p>So when a federal customer engages, an integrator builds a parallel <code class="inline">zddc-server-fips</code> binary using the FIPS toolchain and ships it alongside the standard one. linux-amd64 only, RHEL/UBI base, validated OpenSSL on the host. Federal customers download the FIPS variant; everyone else downloads the lean pure-Go binary. The application code is identical between tracks — only the toolchain and the host OS configuration differ.</p>
<p>This way every customer gets the deployment shape that fits their environment without paying for ones that don't.</p>
</section>
<!-- ────────────── Where the engineering detail lives ────────────── -->
<section class="card" style="border: 1px solid var(--color-border); border-radius: var(--radius-md); padding: var(--spacing-lg) var(--spacing-xl); margin-top: var(--spacing-xl);">
<h2 style="margin-top:0;">Engineering reference</h2>
<p>For implementors picking up federal-track work, the in-repo references include effort estimates, design trade-offs, library choices, and pointers to the existing code that each piece would build on.</p>
<ul style="line-height: 1.9;">
<li><a href="https://codeberg.org/VARASYS/ZDDC/src/branch/main/zddc/README.md#federal-readiness-gap-analysis">Federal-readiness gap analysis</a> — every NIST control we know is incomplete, with the planned remediation. Per-item subsections cover FIPS, authenticated proxy↔server, policy export, and code-signed app fetches with implementation depth.</li>
<li><a href="https://codeberg.org/VARASYS/ZDDC/src/branch/main/ARCHITECTURE.md">ARCHITECTURE.md § Server security model</a> — commercial-vs-federal trust models side-by-side. Cooperating layers (auth, policy decider, ACL cascade, tool-rooted view, audit log) and what each one's actual job is.</li>
<li><a href="https://codeberg.org/VARASYS/ZDDC/src/branch/main/zddc/README.md#access-control-the-zddc-cascade">Access-control reference</a> — cascade rules, anti-patterns, worked deployment layouts (third-party-vendor folders, paired open/closed projects), and a five-minute verify-it-works recipe. Useful for the security-review reading too.</li>
<li><a href="https://codeberg.org/VARASYS/ZDDC">codeberg.org/VARASYS/ZDDC</a> — source code, issue tracker, contribution docs.</li>
</ul>
</section>
</main>
<footer class="site-footer">
<div class="container footer-content">
<span>ZDDC is open source — <a href="https://codeberg.org/VARASYS/ZDDC">codeberg.org/VARASYS/ZDDC</a></span>
</div>
</footer>
<script src="js/layout.js"></script>
</body>
</html>

2
index.html
View file

@ -177,6 +177,7 @@
<ul class="feature-list">
<li><strong>Access control via <code class="inline">.zddc</code> files.</strong> Behind a reverse proxy that authenticates users and sets an <code class="inline">X-Auth-Request-Email</code> request header, <code class="inline">zddc-server</code> consults YAML <code class="inline">.zddc</code> files in directories — cascading bottom-up; deeper rules override. Common shapes (paired open/closed projects + third-party-restricted vendor folders) are documented with worked examples in the <a href="https://codeberg.org/VARASYS/ZDDC/src/branch/main/zddc/README.md#access-control-the-zddc-cascade">access-control reference</a>. No database, no admin UI.</li>
<li><strong>OPA-compatible policy decider.</strong> Federal and other regulated customers can swap the built-in evaluator for an external <a href="https://www.openpolicyagent.org/" rel="noopener">Open Policy Agent</a> server with their own audited Rego policies — set <code class="inline">ZDDC_OPA_URL</code> and the same <code class="inline">.zddc</code> files become inputs to your engine instead of ours. Wire format is OPA-canonical (<code class="inline">POST /v1/data/zddc/access/allow</code>). Default mode adds zero new dependencies; external mode is a configuration flip.</li>
<li><strong>Designed for regulated environments.</strong> Hardened TLS (NIST SP 800-52 Rev. 2 cipher allowlist + HSTS), pluggable policy engine, federal-mode strict-least-privilege Rego shipping out of the box, structured audit logging, documented vulnerability-disclosure process. Specific federal-track work (FIPS-validated build, signed-token proxy↔server channel, code-signed tool fetches) is on a clear roadmap — see the <a href="federal.html">federal compliance page</a> for the supported deployment shape and what an integrator adds during ATO.</li>
<li><strong>Virtual <code class="inline">.archive</code> URL space.</strong> <code class="inline">GET /Project/.archive/123-XYZ.html</code> resolves to the canonical revision file at request time. Computed from filenames; no cache, no separate index file.</li>
<li><strong>Per-request access logging</strong> keyed to the authenticated user; conservative HTTP timeouts; optional file-tee for offline audit (production deployments typically leave logs on stdout for the orchestrator's pipeline to handle).</li>
<li><strong>TLS, ETags, conditional GET, CORS, autoindex.</strong> The mundane glue.</li>
@ -230,6 +231,7 @@ apps:
<ul style="line-height: 1.9;">
<li><a href="reference.html">Technical Reference</a> — the full ZDDC convention: filename format, tracking numbers, revisions, status codes, folder naming, transmittal workflow.</li>
<li><a href="https://codeberg.org/VARASYS/ZDDC/src/branch/main/zddc/README.md#access-control-the-zddc-cascade">Access control reference</a> — cascade rules, common deployment shapes (paired open/closed projects + third-party-vendor folders), anti-patterns, a five-minute verify-it-works recipe, the federal-readiness gap analysis with NIST control references, and the OPA-compatible decider configuration.</li>
<li><a href="federal.html">For federal evaluators</a> — non-technical walk-through of what's already in place, the supported deployment shape, what an integrator adds during ATO, and the two-track build plan. Procurement-friendly entry point that links back to engineering detail.</li>
<li><a href="releases/">All releases</a> — every version and channel build of every tool, with per-version pin URLs.</li>
<li><a href="https://codeberg.org/VARASYS/ZDDC">codeberg.org/VARASYS/ZDDC</a> — source code, issue tracker, contributor docs.</li>
</ul>