Federal Control Mapping

This document is an implementation evidence map for customers evaluating paranoid-passwd in FedRAMP High, GovCloud, or DoD IL5-oriented environments. It is not an authorization package, a FedRAMP authorization claim, or a FIPS validation claim.

The product boundary is local-first: vault data, keyslot material, audit JSONL, and release evidence remain under the operator’s endpoint and assessment boundary. The project provides deterministic controls, evidence artifacts, and precise failure modes that customers can map into their own system security plan.

Evidence Artifacts

Artifact

Producer

Purpose

--federal-evidence JSON

CLI / vault CLI

Startup evidence for profile, build id, OS, architecture, audit sink posture, external audit-device posture, cryptographic provider evidence, strict recovery disposition, and policy decision.

--audit-jsonl JSONL

CLI / TUI / GUI adapters

Redacted request/response policy events for security-relevant operations.

Ops trace fixtures

crates/paranoid-ops/tests/fixtures/

Stable CLI/TUI/GUI command-envelope examples for automation compatibility and assessor traceability.

Release checksums and attestations

Release workflow

Artifact integrity and provenance evidence for shipped archives and packages.

SBOM / package manifests

Release workflow

Supply-chain inventory evidence for release artifacts.

make verify-assurance report

Security assurance gate

Deterministic claim inventory with changed surfaces and required local verification commands.

GUI e2e screenshot

make test-gui-e2e-emulate

Visual evidence that the native GUI flow is actionable under Xvfb-backed automation.

NIST SP 800-53 Rev5 Families

Family

Product control contribution

Customer boundary responsibility

Repo evidence

AC - Access Control

Typed ops envelopes identify actor, surface, transport, profile, command, and policy decision before security-relevant vault actions proceed.

Bind local operators, device accounts, and endpoint authorization policy to the customer’s identity and endpoint controls.

paranoid-ops; vault CLI/TUI/GUI audit traces; docs/reference/architecture.md

AU - Audit and Accountability

Redacted JSONL audit events pair each request and response by request id, preserve operation/access metadata, and fail closed when a required local audit sink is unavailable.

Collect, retain, protect, and monitor JSONL/SIEM records according to the customer’s AU control implementation.

paranoid-audit; --audit-jsonl; ops trace fixtures; tests/test_cli.sh; tests/test_vault_cli.sh

CM - Configuration Management

Federal-ready profile and release verification scripts make profile, build id, vendored dependencies, and release payload verification explicit.

Manage approved deployment baselines, endpoint configuration drift, and release promotion.

make ci; make verify-assurance; scripts/release_validate.sh; scripts/verify_published_release.sh

IA - Identification and Authentication

Vault unlock paths are explicit policy inputs: recovery secret, mnemonic recovery, device-bound, and certificate-wrapped keyslots. Strict federal-ready policy disables password, mnemonic, and device-bound unlocks, emits recovery-disposition evidence, and routes CLI/TUI unlock attempts through typed policy before plaintext vault state is loaded.

Decide which unlock methods are allowed in the assessed boundary and bind certificates/devices to organizational identity policy.

paranoid-vault; paranoid-seal; docs/reference/federal-readiness.md

SC - System and Communications Protection

Cryptographic operations stay in Rust crates using OpenSSL-backed primitives where applicable; external audit-device evidence requires mTLS certificate, key, and CA material to be configured and treats readiness as a matching JSONL challenge acknowledgement, not TCP reachability.

Operate validated cryptographic modules in approved mode when required, protect transport endpoints, and manage certificate lifecycles.

paranoid-core; paranoid-audit; federal startup evidence

SI - System and Information Integrity

Local and CI gates run locked/offline builds, linting, tests, supply-chain checks, assurance inventory checks, and GUI automation evidence.

Integrate repo evidence with endpoint monitoring, vulnerability management, and incident response processes.

.github/workflows/; Makefile; scripts/security_assurance_gate.py

SR - Supply Chain Risk Management

Dependencies are vendored, GitHub Actions are SHA-pinned, release artifacts are checksummed/attested, and published releases can be verified after download.

Decide supplier acceptance, mirror artifacts if needed, and retain provenance evidence in the customer’s release process.

.cargo/config.toml; vendor/; scripts/supply_chain_verify.sh; release verification docs

Non-Claims

  • The project is not FedRAMP authorized.

  • The project is not DoD IL5 authorized.

  • The project is not a FIPS validated product.

  • Generic OpenSSL linkage is not by itself evidence of approved-mode operation.

  • TCP reachability to an external audit endpoint is not evidence of durable audit ingestion.

  • A matching mTLS JSONL write acknowledgement is readiness evidence for the configured endpoint; it is not a claim about the customer’s downstream retention, monitoring, or SIEM control operation.

Minimum Federal-Ready Evidence Packet

A customer-oriented evidence packet should include:

  1. the exact release tag, checksums, attestation links, and SBOM/provenance references

  2. the --federal-evidence JSON captured on the target platform

  3. a sample --audit-jsonl trace for the operational flow being assessed

  4. the relevant ops trace fixture name and schema version

  5. the configured cryptographic provider evidence and approved-mode status

  6. the external audit-device posture, including whether readiness came from a matching mTLS JSONL write acknowledgement

  7. the recovery_disposition evidence, plus any customer-owned compensating-control decision for non-federal recovery paths such as Argon2id, BIP39, or device-bound unlock