The cui-registry-* crates in this workspace are consumed at build time by Marque (and any other Rust project doing codegen from CUI registry data). If tampered registry data slips into that path, codegen produces backdoored Rust that mishandles CUI category validation, markings, or dissemination controls. The blast radius is broad, so the crate is hardened on multiple layers — and because this workspace (unlike ism-data) automates re-vendoring monthly, that automation is itself in the threat model. monthly-vendor.yml only ever opens a PR; a human merging it is the sole trigger for tagging and release (see vendor-pr-merged.yml), so a compromised or wrong upstream fetch stops at an open PR rather than a shipped crate.

• Every file under crates/dod/data/ has its SHA-256 recorded in data/_provenance/manifest.txt.
• build.rs (always-on by default) refuses to compile if any file's hash doesn't match the manifest.
• The manifest is itself hashed: manifest.sha256 carries the digest, and MANIFEST_DIGEST in src/lib.rs carries the same value. A tampered on-disk manifest also fails the build.
• The crate API surface is small: path helpers and two integrity functions. No I/O on path-helper calls, no lazy initialization, no global state.
• Every automated re-vendor records, per source page, the fetch strategy (direct vs. Wayback), the resolved Wayback timestamp when applicable, and a SHA-256 of the raw fetched HTML, in vendor/sources.json — so a disputed vendor can be traced back to exactly what was fetched from where and when.

• That www.dodcui.mil's published content is itself correct or authoritative at the moment of fetch. The workspace proves that what's on your disk matches what was vendored; it cannot prove the vendored content matches DoD's actual intent, especially for a Wayback-fallback fetch (see threat #4).
• That a malicious actor with commit access to this repo, or write access to the monthly-vendor.yml/release.yml workflows, cannot publish tampered crates. Defenses there are operational: signed tags, protected branches, mandatory review on workflow/tooling changes.

1. Pin to commit SHA or an exact crates.io version, not a movable tag.

2. Commit Cargo.lock.

3. Re-run verify_integrity() in CI:

   #[test]
   fn registry_intact() {
       cui_registry_dod::verify_integrity().expect("CUI registry data intact");
   }

4. Don't disable verify-on-build lightly.

5. Audit MANIFEST_DIGEST changes when bumping versions. A re-vendor with no real upstream change should reproduce the same category text; if the diff looks unrelated to what change-log.yaml/the commit message describes, stop and investigate before adopting the new version.

6. Compile in a sandboxed environment when bumping. A compromised build.rs can run arbitrary code during cargo build.

1. Sign release tags (git tag -s vX.Y.Z).
2. Protect the default branch for changes to tools/vendor*.py, .github/workflows/monthly-vendor.yml, .github/workflows/vendor-pr-merged.yml, and crates/dod/build.rs — these are exactly where a supply-chain attack on the automation itself would land. automated-vendor-labeled PRs (data + manifest + provenance only) are lower-risk and diff-visible, but still require at least one human merge before anything tags or releases — don't enable auto-merge for that label.
3. CI rejects manifest skew — integrity.yml runs tools/rederive_manifest.py and fails on any drift.
4. Use cargo vet or cargo crev for sha2.
5. Avoid adding new dependencies unless widely audited.

Report security issues privately to security@knitli.com. Do not file public GitHub issues for vulnerabilities. We aim to acknowledge within 72 hours and to ship a fix for confirmed issues within 14 days.