trustops-security-data-lake 0.2.17

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 --rebase-times
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 --rebase-times
security-lakehouse assessment status --lake ./lake

To give an agent the same lake over MCP (stdio):

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

See headless GRC for remote-server mode and the MCP trust boundary.

Docker, Helm, and production configuration · Server authentication

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.

Inspect the current safeguard catalog from the CLI:

security-lakehouse frameworks safeguards --format table

The images show the bundled demo fixture, not live customer evidence. The inline images follow your GitHub theme.

_{Overview — assessment score, control pass rate, open findings, and evidence to refresh, with framework posture and the highest-risk findings below.}

_{Frameworks — catalogued, mapped, and reviewed requirements are counted separately, then broken down per framework.}

_{Evidence — each normalized record shows its source, mapped control, freshness against the source's SLA, and where the original lives.}

_{Graph — focus one evidence type and see the controls it proves and the assets it came from.}

_{Triage — a finding with its asset and owner, suggested remediation steps, and state, assignee, and due date recorded in triage history.}

Full walkthrough · Connections · Findings · Remediation · Audit room · Workflows · Trust center

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, Microsoft Intune, BambooHR, Rippling, Workday, Snowflake, Databricks (preview), and ClickHouse. Check the connector catalog for each integration's scope and status. A connector can also ship as a separately installed Python package that registers its sync builder and catalog row through entry points; see Shipping a connector as a package.

Cloud connectors use short-lived or workload identity credentials: AWS STS sessions, Azure managed or federated identity, and GCP Application Default Credentials (workload identity or the metadata server; a service-account key file also works). GitHub reads a GitHub App installation token, which expires within an hour; you mint and rotate it. Other SaaS connectors (Okta, GitLab, Jira, BambooHR, Rippling, Workday) use scoped API tokens or an integration-user login. Connector settings keep a credential reference (an environment variable name or mounted secret file), not the secret itself.

• 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 planned. 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

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

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, ClickHouse, and Databricks integrations are evidence backends; they do not host the TrustOps application. Snowflake Native App packaging is planned; the Databricks evidence reader is in preview (live-workspace verification pending). See the deployment guide.

Architecture guide · Architecture diagram · Assessment publication and failure contracts

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

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.

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