stella-ops.org/git.stella-ops.org
1
0
Fork 0
Code Issues Pull Requests Actions 2 Releases Wiki Activity
Files
7503c19b8ffa7f2891e5e672f9cfbf7efa4e2efb
git.stella-ops.org/docs/technical/architecture/security-boundaries.md
StellaOps Bot 7503c19b8f Add determinism tests for verdict artifact generation and update SHA256 sums script 
- Implemented comprehensive tests for verdict artifact generation to ensure deterministic outputs across various scenarios, including identical inputs, parallel execution, and change ordering.
- Created helper methods for generating sample verdict inputs and computing canonical hashes.
- Added tests to validate the stability of canonical hashes, proof spine ordering, and summary statistics.
- Introduced a new PowerShell script to update SHA256 sums for files, ensuring accurate hash generation and file integrity checks.
2025-12-24 02:17:34 +02:00

1.7 KiB
Raw Blame History

Security boundaries (platform-level)

This document describes the baseline security boundaries expected across StellaOps modules. Module dossiers may impose stricter requirements.

Authentication and authorization

All externally reachable services are expected to enforce:

  1. Token validation (short-lived, tenant-scoped access tokens).
  2. Sender constraints where configured (DPoP / mTLS).
  3. Scope-based authorization (least privilege).
  4. Tenant isolation: requests and data access are filtered by tenant context.

Network segmentation (typical deployment)

  • Front door / ingress: TLS termination, rate limiting, and WAF controls.
  • Gateway layer: authenticated routing and tenant resolution; exposes only required service surfaces.
  • Private service network: internal service-to-service traffic (least privilege, explicit allowlists).
  • Stateful infrastructure: PostgreSQL, Valkey, object storage, message brokers (not directly internet-exposed).

Deployment bundles under deploy/ are the authoritative source of concrete network layouts.

Data protection

  • TLS for in-transit protection (including internal traffic where required by the profile).
  • Secrets must not be embedded in documentation examples; use a secrets provider (file, Docker secrets, Kubernetes secrets, vault).
  • Evidence artifacts should be written to content-addressed or immutable stores where replay/audit requires it.

Auditability

The platform is designed for audits:

  • Deterministic outputs for the same inputs.
  • Evidence artifacts (SBOM slices, advisories/VEX observations, explain traces) linkable to digests.
  • Structured logs and correlation IDs for tracing request paths across services.