Open, self-hosted GRC for cloud and AI.
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; 45 have reviewed mappings. Catalog coverage and evaluated customer posture are separate measures.
SOC 2 |
ISO 27001 · 27017 · 42001 |
NIST CSF 2.0 |
NIST AI RMF |
CIS AWS |
CMMC 2.0 |
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 |
|---|---|
Full walkthrough · Connectors · Frameworks · Findings · Triage · 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.
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
Release files for trustops-security-data-lake 0.2.11
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.11.tar.gz | 2.4 MB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| trustops_security_data_lake-0.2.11-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 5.0 MB
Release files / trustops_security_data_lake-0.2.11.tar.gz
| Download URL | trustops_security_data_lake-0.2.11.tar.gz |
|---|---|
| Size | 2.4 MB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
e962ea65ccdffee637a315ead9172bfa6d9c067d4e4204d233c0e13fcfc0121d
|
|
BLAKE2b-256 checksum How to use checksums |
10a739f48e3393f932a27ced8c1458ef910485093063039872181206216b4d9c
|
| 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 14, 2026.
Transparency logRelease files / trustops_security_data_lake-0.2.11-py3-none-any.whl
| Download URL | trustops_security_data_lake-0.2.11-py3-none-any.whl |
|---|---|
| Size | 2.6 MB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
196f93a434c6854faad14bac5049afb571b4a14735a3cf6538195f83ccec0e5e
|
|
BLAKE2b-256 checksum How to use checksums |
9f9d76c2cc7cd3f20cc88581820b7b0a3ad518e455712215eadf9dc28dcafedf
|
| 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 14, 2026.
Transparency log