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>
|
||
|---|---|---|
| .forgejo/workflows | ||
| css | ||
| img | ||
| js | ||
| CLAUDE.md | ||
| federal.html | ||
| index.html | ||
| LICENSE | ||
| README.md | ||
| reference.html | ||
ZDDC website
Hand-edited content for zddc.varasys.io. Two files:
index.html— landing page + install snippets.reference.html— the ZDDC file-naming convention specification.
Plus css/, js/, img/ for shared styles and assets.
This repo intentionally does not contain release artifacts. The
ZDDC tools (archive, transmittal, classifier, mdedit,
landing) and the zddc-server binary are built from the source
repo at https://codeberg.org/VARASYS/ZDDC and deployed to the live
site by its build pipeline. They live on the deploy host under
/srv/zddc/releases/, never in this repo's git history.
Preview locally
git clone https://codeberg.org/VARASYS/ZDDC-website
cd ZDDC-website
python3 -m http.server 8000
# open http://localhost:8000/
The preview won't have a /releases/ directory unless you also have
the source repo and run its build pipeline. That's expected — the
two repos are intentionally decoupled.
Publishing
.forgejo/workflows/deploy-content.yml rsyncs the working tree into
/srv/zddc/ on the deploy host on every push to main. The rsync
uses --delete-after and excludes /releases/, /.git*,
/.forgejo*, /README.md, and /LICENSE — anything else added at
the repo root will be published.
Editing notes
js/layout.jsqueries the header for.header-nav,.dropdown,.dropdown-toggle,.dropdown-menu, and.theme-toggle. Both HTML pages need to keep those classes or the theme toggle and Tools dropdown silently break.- Page-specific CSS goes in an inline
<style>in<head>(seeindex.html); only shared rules go incss/style.css. Design tokens (--color-accent, spacing scale, etc.) live at the top ofcss/style.css— prefer those over hardcoded values.
Contributing
Issues + PRs welcome. For changes to the tool source code (not the website), file them at https://codeberg.org/VARASYS/ZDDC.