Skip to main content

TrustOps — read-only cloud, identity, code and data sources; Common Control Framework and framework packs.

Open, self-hosted GRC for cloud and AI.

PyPI version Python 3.11+ CI status License: Apache 2.0

Quick start · How it works · Frameworks & CCF · Explore · Develop & verify

TrustOps collects security evidence, evaluates controls, tracks follow-up work, and exports assessments for review. Built for humans and agents: use the console for investigation and review, or API, CLI, MCP, and CI for automation. Deploy it in your environment. Data access and egress depend on your configured connectors, sinks, and model integrations.

Quick start

Try the console with fixture data. From a cloned repository, use Python 3.11+, uv, and Node 22+:

uv sync --frozen --extra dev --extra server
make demo-local

Open localhost:8787/console/dashboard/. The command builds the console, loads the golden fixture, migrates the local database, and starts the server. This local demo disables authentication; use authenticated deployment for a shared environment.

Other setup paths — pip, CLI-only, and deployment

For a source install without uv:

python -m venv .venv
source .venv/bin/activate
pip install -e ".[dev,server]"
make web-install web-build
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

For the CLI and local lake only:

pip install trustops-security-data-lake
security-lakehouse fixtures load --company golden --out ./lake

Docker, Helm, and production configuration · Server authentication

How it works

Step What you do What you get
Collect Connect a source with read-only access. Evidence with source, freshness, and provenance.
Evaluate Apply deterministic control rules. Results tied to evidence and the evaluated catalog.
Resolve Assign findings, track fixes, and review exceptions. Ownership and a record of follow-up decisions.
Export Freeze an assessment and share reports. Evidence and assessment history for reviewers.

The Common Control Framework reuses safeguards across framework mappings. A mapping does not itself establish compliance. Models may summarize or propose actions; deterministic rules decide control results.

Frameworks and common controls

13 framework packs · 44 reusable safeguards · 15 control families · 942 catalogued requirements.

559 requirements have safeguard mappings; 254 have reviewed mappings. Catalog coverage and evaluated customer posture are separate measures.

SOC 2
SOC 2
ISO framework family
ISO 27001 · 27017 · 42001
NIST CSF
NIST CSF 2.0
NIST AI RMF
NIST AI RMF
CIS AWS
CIS AWS
CMMC
CMMC 2.0
European framework family
EU AI Act · GDPR
FedRAMP Moderate
HIPAA · PCI DSS

Framework identities show catalog scope. A pack may be a limited mapping; see the coverage matrix for the exact boundary. SOC 1 and ISO 27701 are planned, with no catalogued controls yet.

CCF layer What it represents
Control families Risk domains that organize reusable safeguards.
Safeguards Evidence requirements, ownership, review frequency, and executable evaluation rules.
Framework mappings Links from safeguards to individual framework requirements, with proposed and reviewed status kept separate.
Assessment results Pass, fail, stale, or not-evaluated outcomes from the collected evidence.
Control families and evaluation details

Identity & access · data protection · detection · logging · change management · availability · incident response · third-party risk · vulnerability management · AI governance · risk management · privacy · governance · monitoring · control operations.

One safeguard can serve several frameworks. Every required mapped safeguard must pass for a requirement to pass; an unmapped requirement remains unmapped. A reviewed mapping is not certification or proof that a customer's controls pass.

CCF design and safeguards · Coverage by framework · Executable catalog

security-lakehouse frameworks safeguards --format table

Explore

01 · Product tour — overview, evidence, and audit room

The images below show the stored demo fixture, not live customer evidence.

Overview Evidence
TrustOps demo overview TrustOps demo evidence
Frameworks Triage
TrustOps demo frameworks TrustOps demo triage

Full walkthrough · Connectors · Findings · Remediation · Audit room · Workflows

02 · Connect sources — cloud, identity, code, and existing lakes

In the console, open Connectors → choose a source → Discover → Test → Enable → Sync. No pre-existing data lake is required. For automation, use the headless setup playbook.

Sources include AWS, Azure, GCP, GitHub, GitLab, Okta, Snowflake, and ClickHouse. Check the connector catalog for each integration's scope and status.

No connector requires pasted long-lived cloud keys.

  • 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. See the cloud setup guide.
  • Azure supports a customer-owned Entra application, managed identity, or federated workload identity with Reader scope.
  • Snowflake uses a read-only service identity with a key-pair or OAuth token reference. TrustOps stores identifiers, not passwords or private-key contents. Snowflake is the existing security-data-lake path.

AWS credential lifecycle diagram · Continuous ingestion

03 · Controls and workflows — safeguards, frameworks, and ownership
Area Read more
Safeguards and executable rules Common Control Framework
Framework mappings and coverage Framework coverage
Findings, reviews, exceptions, and audit preparation Product walkthrough · Audit readiness
Implemented, partial, and planned capabilities Product status · Roadmap

Catalog size, mapped coverage, and evaluated results are separate measures. Inspect the current safeguard catalog with security-lakehouse frameworks safeguards.

04 · Deployment and interoperability — local, cloud, and evidence storage
Source → Raw evidence → Normalized facts → Control evaluation → Assessment
                                                ↓                  ↓
                                           Owned findings    Review / export
Layer Current boundary
Evidence and evaluation Local JSONL, deterministic rules, and verified assessment generations.
Local analytics SQLite mart; DuckDB is optional.
Operational state Application database and local state for jobs, assignments, and reviews.
External storage Snowflake and ClickHouse integrations; verify the configured deployment.
Portable evidence Optional Parquet export of one verified generation; independently tested with DuckDB.
Open table catalogs Optional Iceberg REST publication; local Polaris and DuckDB snapshot reads tested.

Run locally with Python or Docker, or deploy the Helm chart in your own cloud. The current assessment writer needs durable local POSIX storage and one writer per lake. Snowflake and ClickHouse integrations are evidence backends; they do not host the TrustOps application. Snowflake Native App packaging and Databricks support are planned. See the deployment guide.

Architecture guide · Architecture diagram · Assessment publication and failure contracts

05 · API, agents, and CI — use the same assessment engine headlessly
Surface Purpose
Console Browse posture, evidence, findings, and reviews.
API Versioned /api/v1 access for integrations.
CLI Collect, evaluate, verify, export, and run the local server.
MCP Read assessments and propose actions through governed tools.
CI Apply posture and control-test thresholds to delivery workflows.

TrustOps operator skill · Specialist skills · Agent workflow catalog · AI bill of materials

Develop and verify

Checks, repository layout, and documentation
make smoke       # backend, contracts, docs, brand, pipeline, API
make web-ci      # install, typecheck, production build
make security    # dependency audits and pre-commit checks

Regenerate fixture screenshots with make demo-screenshots-full.

Directory Contents
src/security_lakehouse/ Assessment engine, API, auth, connectors, and MCP.
app/web/ Next.js console.
controls/, frameworks/, mappings/ Rules, framework catalogs, and mappings.
deploy/ Deployment and infrastructure examples.
docs/ Product, architecture, operations, and API guides.

Validation and benchmark plan · Deployment · Roadmap · Third-party assets

Apache-2.0 license.

Release files for trustops-security-data-lake 0.2.13

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for trustops-security-data-lake 0.2.13
File Size Uploaded
trustops_security_data_lake-0.2.13.tar.gz 2.4 MB Details

Built distribution (wheel)

Table of built distributions (wheels) for trustops-security-data-lake 0.2.13
File Interpreter ABI Platform
trustops_security_data_lake-0.2.13-py3-none-any.whl Python 3 none any Details

Total release size: 5.0 MB

Release files / trustops_security_data_lake-0.2.13.tar.gz

Download URL trustops_security_data_lake-0.2.13.tar.gz
Size 2.4 MB
Tags Source
SHA-256 checksum
How to use checksums
344dd5f9bdd0c3b0768743465321d6d48b86768cae62578b34b39c87620eb907
BLAKE2b-256 checksum
How to use checksums
f6713e1d0f2486ad061f9e38ce416db1f17ffc369ed1fac30c660279080cd885
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 Sep 22, 2026.

Transparency log

Release files / trustops_security_data_lake-0.2.13-py3-none-any.whl

Download URL trustops_security_data_lake-0.2.13-py3-none-any.whl
Size 2.6 MB
Tags Python 3
SHA-256 checksum
How to use checksums
1f4b47ef5cc69032b1022bcc28db0dc9f0bb34d7e904d35989e0658f33e0e0c0
BLAKE2b-256 checksum
How to use checksums
64ca1f60cb3f1665698643358947ab8c6e01b91764f87062369074a9901e2f8b
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 Sep 22, 2026.

Transparency log

Release history Release notifications | RSS feed

0.2.16

2 release files

0.2.15

2 release files

0.2.14

2 release files

This release

0.2.13 This release

2 release files

0.2.12

2 release files

0.2.11

2 release files

0.2.10

2 release files

0.2.9

2 release files

0.2.8

2 release files

0.2.7

2 release files

0.2.6

2 release files

0.2.5

2 release files

0.2.4

2 release files

0.2.3

2 release files

0.2.2

2 release files

0.2.1

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page