TrustOps
Continuous compliance in your cloud.
Read-only evidence collection, deterministic control tests, and audit-ready proof — in one self-hosted platform.
Product tour · Connectors · Architecture · API & agents · Deploy
What TrustOps does
One operating loop: collect evidence read-only, evaluate controls with deterministic rules, operate the findings, prove posture with immutable snapshots.
Regulatory requirements are consolidated into a
Common Control Framework: you operate one
safeguard, and it satisfies every requirement mapped to it across frameworks.
The catalog holds 942 requirements across 13 frameworks; run
security-lakehouse frameworks safeguards for current coverage.
Evidence stays in your environment. Models may summarize and prioritize; they do not silently change evidence or decide pass/fail.
Quickstart
# PyPI (Python 3.11+) — console + API
pip install 'trustops-security-data-lake[server]'
security-lakehouse platform seed-dev --lake ./lake
security-lakehouse serve --server --lake ./lake # http://127.0.0.1:8787/console/
# Container image
docker run -p 8787:8787 ghcr.io/msaad00/trustops:latest
# Kubernetes (Helm)
helm install trustops deploy/helm/trustops
See deploy/README.md for production configuration, and the Product tour for what to do once it is running.
Surfaces — console, API, CLI, MCP, CI
| Surface | Purpose |
|---|---|
| Console | Posture, controls, evidence, findings, workflows, and audit room |
| API | Versioned /api/v1 contract |
| CLI | Local pipelines, validation, snapshots, and server operations |
| MCP & agents | Read posture and propose governed actions with approval boundaries |
| CI | Block releases when posture or control-test thresholds regress |
Connectors — least-privilege, read-only
AWS · Azure · GCP · GitHub · GitLab · Okta · Snowflake · ClickHouse, plus the
scanner, ticketing, and AI-platform entries in
connectors/catalog.json.
Product preview
| Trust Home | Audit room |
|---|---|
| Evidence | Connectors |
|---|---|
More views: frameworks · insights · workflows · trust center
Quick start
Requires Python 3.11+ and Node 22+ (the console is built from source; it is not committed to the repository).
python -m venv .venv
source .venv/bin/activate
pip install -e ".[dev,server]"
make web-install web-build # builds the console into src/security_lakehouse/web/dist
security-lakehouse fixtures load --company golden --out build/lakehouse
security-lakehouse db upgrade --lake build/lakehouse
security-lakehouse serve \
--lake build/lakehouse \
--server \
--allow-insecure-no-auth \
--port 8787
Open http://127.0.0.1:8787/console/dashboard/.
Skipping the console build leaves that URL a 404: the server mounts /console/
only when a built console is present, and falls back to a single status page.
make demo-local runs the whole sequence in one step.
--allow-insecure-no-auth is for local development only. Production deployments require configured authentication; see server authentication.
Connect a live source
The default path is agentless and read-only; no pre-existing data lake is required.
- Console: open Connectors, choose a source, then run Discover → Test → Enable → Sync.
- Headless: follow the connector setup playbook for API, CLI, and MCP flows.
- Existing lake: connect Snowflake or ClickHouse when evidence already lives there.
Cloud connectors use short-lived provider credentials or workload identity. No connector requires pasted long-lived cloud keys. TrustOps stores non-secret identifiers, redacted fingerprints, sync history, and evidence hashes.
Connector security contracts:
- AWS uses STS AssumeRole, one External ID per deployed role, short-lived session credentials, and read-only IAM posture APIs. Temporary credentials expire after each session; TrustOps stores no long-lived access keys. Scale rollout with CloudFormation StackSets or Terraform workspaces; Bulk account import is the next operator surface.
- Azure uses a customer-owned Entra application, managed identity, or federated workload identity with Reader scope. Tokens are short-lived, and no Azure password or raw client secret is stored.
- Snowflake supports browser SSO for human proof or a read-only service identity with a key-pair or OAuth token reference held by the runtime secret manager. TrustOps stores account, role, and view identifiers — not passwords or private-key contents. Snowflake is the existing security-data-lake path.
Architecture
read-only source → raw observation → normalized fact → deterministic evaluation
→ finding/current posture → immutable snapshot → governed action
The console, CLI, MCP server, agents, and CI gate share the same API and assessment engine. This keeps browser output and headless automation consistent.
What ships
| Area | Included |
|---|---|
| Compliance | SOC 2, NIST AI RMF, FedRAMP, ISO, CIS AWS, HIPAA, PCI DSS, GDPR, and EU AI Act packs |
| Evidence | Freshness SLAs, provenance, SHA-256 verification, tags, and saved views |
| GRC workflows | Remediation, policies, attestations, vendor risk, access reviews, and approvals |
| Identity | OIDC, SAML, API keys, RBAC, tenant boundaries, and SCIM scaffolding |
| Deployment | Local, Docker, Helm, EKS reference IaC, Snowflake, and ClickHouse |
| Exports | Snapshots, executive PDF, trust shares, OpenAPI, MCP, and GitHub posture gate |
See the product shape for shipped, partial, and planned capability status.
Verify
make smoke # backend, contracts, docs, brand, pipeline, API
make web-ci # install, typecheck, production build
make security # dependency audits and pre-commit checks
Regenerate documentation screenshots with make demo-screenshots-full.
Repository map
src/security_lakehouse/ assessment engine, API, auth, connectors, MCP
app/web/ Next.js console
controls/ frameworks/ control catalogs, packs, and mappings
deploy/ Docker, Helm, cloud, warehouse, and IaC examples
docs/ product, architecture, operations, and API guides
Documentation
- Product walkthrough
- Architecture
- Connector catalog
- Continuous ingestion
- Audit readiness
- Agent API
- Deployment
- Roadmap
Apache-2.0 licensed. Third-party visual assets and usage terms are documented in THIRD_PARTY_ASSETS.md.
Release files for trustops-security-data-lake 0.2.4
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| trustops_security_data_lake-0.2.4.tar.gz | 2.2 MB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| trustops_security_data_lake-0.2.4-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 4.6 MB
Release files / trustops_security_data_lake-0.2.4.tar.gz
| Download URL | trustops_security_data_lake-0.2.4.tar.gz |
|---|---|
| Size | 2.2 MB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
ce826585b5dff618e0185efcb8943d05b2fad3fce6f47aa33d9d2487a2b5d934
|
|
BLAKE2b-256 checksum How to use checksums |
866616ed1dbd01c70549a896fb91d197898427aadc54b981112e35d9184a5991
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Aug 14, 2026.
Transparency logRelease files / trustops_security_data_lake-0.2.4-py3-none-any.whl
| Download URL | trustops_security_data_lake-0.2.4-py3-none-any.whl |
|---|---|
| Size | 2.4 MB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
e121eac3665f3e72d849a204f23a83c586ec184bed0bc8438434df66c8cac0f2
|
|
BLAKE2b-256 checksum How to use checksums |
dbc85338958581328c091656dca42696376f3867b72225700a4efd398a0ad103
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Aug 14, 2026.
Transparency log