Evidence you can read yourself
Samba runs inside your boundary, so the evidence that it is operating correctly is generated inside your boundary too. Nothing on this page is gated — if your security review needs it during evaluation, it should not be behind a form.
Control Evidence
54 controls, evaluated against your running cluster
Samba ships with a control catalog that it evaluates against the cluster it is actually running in — not a questionnaire response, and not a description of how the software is supposed to be configured. The same catalog drives the deployment repository's drift check, so what we deploy and what we describe cannot diverge.
54
controls in the catalog
Across 14 categories, each carrying its SOC 2 criterion and NIST 800-53 lineage.
Weekly
restore verification
Backups run daily and are proven by actually restoring one — not asserted annually by policy. The control fails if the last successful restore is more than seven days old.
Yours
environment, yours to read
Your staff and your assessor read the results directly, on their own schedule.
What the catalog covers
Network segmentation — ingress policies
Network segmentation — egress policies
RBAC & least privilege
Secrets management (Vault)
Encryption at rest
Service mesh & mutual TLS
Pod security posture
Admission controller enforcement
Data protection — backups & persistence
High availability & redundancy
Security monitoring & alerting
Log integrity & redaction
Audit log retention
Resource exhaustion protection
Audit
A change history the application cannot rewrite
Every configuration change, flow execution, and credential use is recorded with a correlation ID, the acting user, and old/new values. Immutability is enforced by a database trigger rather than by application code — so the application that writes the audit log has no path to altering it. That distinction is the one an assessor probes for, and it is the reason the guarantee survives a compromise of the application tier.
Data Protection
How the deployment is built
Single-tenant by design
Every customer gets a dedicated deployment in their own cluster. Your configuration, credentials, and integration data share nothing with any other organization. Data sovereignty is structural, not a policy commitment.
Secrets never touch application config
Credentials are centralized in HashiCorp Vault with audit logging on every access, and the auto-unseal key is protected by Azure Key Vault. No credentials are persisted in application configuration or container images.
Encrypted at rest and in transit
All data is encrypted at rest with FIPS 140-2 validated modules, and in transit with TLS everywhere — including mutual TLS between every internal service via the Linkerd service mesh.
Default-deny networking
Network segmentation is enforced by default-deny NetworkPolicies: nothing reaches anything else unless a policy explicitly allows it. Ingress and egress are governed separately.
GitOps deployment, no manual drift
Deployments are applied via Flux GitOps, so what is running corresponds to a reviewed commit. There is no undocumented manual change path into a running environment.
Sandbox cannot reach production secrets
Development and production execution run in separate containers under distinct Kubernetes priority classes and resource quotas, with production credentials scoped exclusively to the production executor.
Frameworks
Where Samba sits in your compliance program
FIPS 140-2 cryptography
FIPS 140-2 validated cryptography is available via HashiCorp Vault Enterprise (BoringCrypto, certificate #4156) using your own Vault Enterprise license. PostgreSQL and the Linkerd service mesh both use FIPS-validated cryptographic modules by default.
NIST SP 800-171
A full control-family mapping against NIST SP 800-171 Rev 2 is available on request for prospective government customers and their assessors. The control catalog above carries 800-53 lineage on every entry.
FedRAMP & your ATO
Samba is designed for deployment into Azure Government, inheriting Azure's existing FedRAMP High provisional ATO for the underlying infrastructure. We are not pursuing a separate FedRAMP authorization for the software: Samba operates as an application component inside your agency's existing ATO, which is standard practice for commercial software in authorized infrastructure. A detailed Customer Responsibility Matrix is available on request.
Request the detailed documentation
The summaries above are public because a security reviewer needs them during evaluation. The detailed matrices go out to named prospects and their assessors under NDA, which is the normal pattern in this market.
Reporting a vulnerability
If you believe you have found a security issue in Samba, we want to hear about it directly and we will not take action against good-faith researchers. Email security@cirrustempo.com with enough detail to reproduce the issue. We acknowledge reports within two business days.