HypercubsDRC Docs
explanation security public

Security model

DRC protects execution evidence through tenant-scoped authorization, bounded inputs, integrity verification, and explicit storage authorities.

Tenant boundaries

Hosted requests resolve identity from PostgreSQL and require the authenticated tenant to match every execution, project, integration, evidence, and content operation. A missing or cross-tenant reference fails closed.

Evidence integrity

Captured events are written through the selected storage authority. Sealed segments and portable evidence bundles carry digest and signature metadata. Verification reports whether bytes and signer identity were verified; metadata-only records are not presented as verified evidence.

Secrets

Provider credentials are represented by managed credential references. They are not included in public API responses, editorial revisions, issue descriptions, audit details, or support bundles. Store private keys in a secret manager or protected file path, never in a CRD or ConfigMap.

Redaction and retention

Some capture clients redact selected URLs, headers, and JSON fields before upload, depending on their configured capture policy. Hosted storage does not currently apply a universal redaction pass to submitted event payloads; review capture policy and captured data before recording sensitive workloads. Signed evidence bundles are immutable after issuance and are not modified to apply redaction. Retention, deletion, legal holds, and exports are tenant-scoped and controlled by the hosted lifecycle authority.

Deployment security

Production deployments should enforce:

  • TLS at every exposed boundary.
  • Immutable image digests and verified provenance.
  • Signed admission decisions where deployment gates are enabled.
  • Database and object-store network isolation.
  • Key rotation and credential revocation procedures.
  • Dependency and container vulnerability scanning.

Certificate trust store updates

TLS verification is supplied by the HTTP client, runtime, operating system, or an application-bundled trust store. Keeping the operating system updated alone may not update a vendored or statically bundled CA list. Rebuild deployed images and restart services after trust-store security updates; verify the specific client used by the application. Do not disable certificate validation to resolve trust errors.

DRC clients rely on their configured TLS implementation and trust store. The Rust clients use rustls with trust roots managed by the locked Rust dependencies; Python SDK distributions use certifi; Node.js SDKs use the CA trust store provided by the Node.js runtime. Keep those dependencies, runtime packages, and deployed images current, and restart services after updating runtime trust data. Updating a DRC package does not necessarily update a trust store supplied by the host runtime. Do not disable certificate or hostname verification to work around trust failures.

The DRC Node packages require a supported Node.js release from 22.23.4, 24.22.1, or 26.12.1 onward on the corresponding release line. Validate TLS behavior through the actual DRC client and deployment path; success from another client on the same host does not verify this path.

Security reporting

Report a suspected vulnerability through the security contact published by your DRC service operator. Do not include production payloads, credentials, or private evidence in an initial report.