trustops-security-data-lake 0.2.20

Quick start · How it works · Self-host · Frameworks · Scope · Explore

Open-source, self-hosted compliance automation. Connect your stack, continuously test controls, collect evidence, and hand auditors proof — running in your own cloud or VPC, on your own data lake.

• Your cloud, your evidence. Evidence stays in storage you run. Data leaves only through the connectors, sinks, and model integrations you configure.
• Deterministic and API-first. Rules decide pass or fail, and every result links to its evidence; models may summarize or propose, never decide. The console, API, CLI, MCP server, and CI gates share one engine.

Quick start

With Docker Compose v2:

git clone https://github.com/msaad00/trustops-security-data-lake.git
cd trustops-security-data-lake
docker compose up

Open localhost:8787/console/dashboard/. It serves the bundled sample company with authentication off, on 127.0.0.1 only. The 5-minute tutorial continues to a real cloud account, a mapping review, and an OSCAL export.

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

pip install "trustops-security-data-lake[server]"
security-lakehouse fixtures load --company golden --out ./lake --rebase-times
security-lakehouse assessment status --lake ./lake
security-lakehouse serve --server --allow-insecure-no-auth --lake ./lake --port 8787

pip install 'trustops-security-data-lake[mcp]'
TRUSTOPS_LAKE=./lake trustops-mcp

How it works

Evidence arrives in one of two modes; both feed the same rules and assessments.

* Preview: implemented and fixture-tested, not yet verified against a live tenant. Lake mappings are experimental. The connector catalog lists all 28 contracts: 25 executable (18 generally available, 7 in preview).

Self-host

Server mode requires authentication (OIDC, SAML, or API keys). In hosted mode each tenant's connector secrets and cloud access stay tenant-scoped: hosted connector credentials. Start with the deployment guide.

Frameworks and common controls

20 framework packs · 94 reusable safeguards · 21 control families in 10 categories · 2,245 catalogued requirements. 2 more registry entries are planned or superseded and hold no requirements.

1,415 requirements have safeguard mappings; 350 have reviewed mappings. Catalog coverage and evaluated customer posture are separate measures.

Control families by category:

• Governance and risk: Risk management · Governance
• Identity and access: Identity and access
• Data protection and privacy: Data protection · Privacy
• Secure engineering: Change management · Secure development · Secure architecture
• Infrastructure security: Configuration management · Vulnerability management · Network security
• Detection and response: Detection · Audit logging · Incident response
• Resilience and integrity: Availability and recovery · System maintenance · Processing integrity
• Third-party and supply chain: Third-party risk
• People and physical: People security · Physical security
• AI governance: AI governance

SOC 2	ISO 27001 · 27017 · 27701 · 42001	NIST CSF 2.0	NIST AI RMF
CIS Controls · CIS AWS	CMMC 2.0	EU AI Act	NIST 800-53 · 800-171 Rev 3 · RMF FedRAMP · HIPAA · PCI DSS GDPR · NIS2 · DORA

A reviewed mapping has been confirmed by a person; a proposed one has not, and neither is a certification. Some packs are limited: PCI DSS v4.0.1 covers its 12 principal requirements, ISO/IEC 27701:2025 seeds 10 of its 78 Annex A controls, and every NIST RMF, NIST 800-171 Rev 3, NIS2, and DORA mapping is proposed. SOC 1 is planned. The AI governance family's 13 safeguards map 80 requirements across NIST AI RMF, ISO/IEC 42001, the EU AI Act, and GDPR, mostly proposed. The coverage matrix has the exact boundary per framework. Your own reviewers can approve or reject mappings for your tenant, with an attributable audit trail: mapping review.

security-lakehouse frameworks safeguards --format table

Scope

Details: product status · roadmap.

Assessment and scale boundaries

CCF mapping coverage describes the catalog. Operational safeguard results require explicit evidence bindings, reviewed mappings, and evidence for applicable observed assets. The Frameworks page shows those results separately from framework-control readiness; complete inventory and organizational compliance remain separate claims. See CCF evaluation.

For a technical review, start with these reproducible contracts:

Evaluation runs in local Python and publishes immutable, hashed generations. Warehouse sinks export completed results; they do not remove local memory limits. The supported Helm deployment has one writable application replica. See the architecture, benchmark evidence, and HA boundary for measured and unverified scope.

Explore

Source → Raw evidence → Normalized facts → Control evaluation → Assessment
                                                ↓                  ↓
                                           Owned findings    Review / export

Develop and verify

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