This release is a pre-release and may not be stable for production use.
DataSecOps CLI
A command-line interface for the Monitorial Orbit Native App on Snowflake. Streamlines dbt development, source control workflows, and framework configuration management for teams using the DataSecOps Framework.
What is this?
The DataSecOps CLI is the local developer companion to the Monitorial Orbit Native App — a Snowflake Native App that provides governance, configuration management, and standardised development workflows for data teams.
This CLI connects to the native app and gives developers:
- dbt development commands — run, build, test, lint, and manage dbt projects via dbt 2.x or dbt Core 1.x
- Source control operations — branching, committing, rebasing, and deploying via GitPython with naming conventions enforced by the framework
- DCM projects — validate, render, plan and deploy any number of Snowflake DCM projects from the shared DCM model (
config/dcm_model.json), in dependency order with each project's deploy role - Configuration downloads — pull SQLFluff rules, CI/CD pipelines, dbt packages, and CoCo skills from the native app to your local project
- MCP server — expose framework governance rules to AI coding assistants (VS Code, Cursor, CoCo, Claude Code)
Installation
pip install datasecops-cli
With MCP server support:
pip install "datasecops-cli[mcp]"
Requires Python 3.10 or later.
Prerequisites
- A Snowflake connection configured in
~/.snowflake/connections.toml - The Data Engineers DataSecOps Native App installed in your Snowflake account
- A project profile created in the native app
Optional:
- dbt — required for dbt commands (
dbt). Install viapip install dbt(dbt 2.x) orpip install dbt-core dbt-snowflake(dbt Core 1.x), matching the engine configured in the native app's Project Settings. - CoCo for skill downloads
- Node.js 18+ for GitHub/Azure DevOps MCP servers
Quick Start
1. Configure your project
datasecops setup
This prompts for your Snowflake connection name and native app database, then writes .datasecops.yml.
If you skip this step, running datasecops will offer to run setup automatically.
2. Run the CLI
datasecops
Features
| Menu | Capabilities |
|---|---|
| Development | dbt run, build, test, lint (SQLFluff/dbt lint), format (dbt format, dbt2), deps, seed, compile, parse, snapshot, freshness, docs |
| Git | Branch create/checkout/delete, commit & push, rebase, squash, deploy to environment branches, cherry-pick, reset branch from main |
| DCM Operations | Plan, deploy, status, download and list the DCM projects in the model |
| Downloads | SQLFluff config, CI/CD pipelines (GitHub Actions / Azure DevOps), dbt packages, CoCo skills |
dbt command flags
The Development menu exposes these flags from the underlying dbt commands:
run/build---full-refresh;--emptyruns with zero-row refs/sources to validate dependencies cheaply — it still executes each model's SQL against the warehouse, so table models are materialized with empty/reduced data and their current contents are replaced; it is not a no-write dry run.--generate-info-schema(dbt2 only) writes the dbt Information Schema (queryable project metadata) totarget/info_schema/;--static-analysis strict(dbt2 only, independent of--generate-info-schema) adds column-level lineage.compile- compile the whole project, a specific selector, or an ad-hoc dbt-SQL query (--inline);--no-introspectto error instead of running introspective warehouse queries;--generate-info-schema(dbt2 only) as above.parse---no-partial-parseto force a full re-parse instead of only recently changed files;--generate-info-schema(dbt2 only) as above.lint/format(dbt2 engine only) -dbt lintsupports--rules/--exclude-rules(rule codes to enable/disable),--jinja-render-mode(symbolic/rendered/turbo), and--changedto lint only git-modified files. The separatedbt format/dbt fmtcommand auto-formats SQL files according to.sqlflufflayout rules, with a--checkdry-run mode. These are not available on the SQLFluff (dbt Core 1.x) path; on dbt Core the CLI skips--generate-info-schema/--static-analysis strictwith a warning instead of sending a flag dbt Core would reject.
Non-Interactive Mode (CI/CD)
The download subcommand lets you pull framework config in CI/CD pipelines without interactive prompts:
# Download specific items
datasecops download sqlfluff
datasecops download sqlfluff packages
datasecops download pipelines macros
# Install framework-pinned package versions
datasecops download install-sqlfluff
datasecops download install-dbt
# Download config and install packages together
datasecops download sqlfluff install-sqlfluff
# Download and install everything
datasecops download all
Available items: sqlfluff, pipelines, packages, macros, scripts, install-sqlfluff, install-dbt, all
The pipeline platform (GitHub / Azure DevOps) is auto-detected from the native app's source control configuration.
Pipeline Setup
Your pipeline needs two things:
-
A
.datasecops.ymlin the repo (already committed — contains no secrets):connection_name: "ci" app_database: "MONITORIAL_ORBIT"
-
A Snowflake connection in
~/.snowflake/connections.tomlfor the CI service account:# GitHub Actions example - name: Configure Snowflake connection run: | mkdir -p ~/.snowflake cat > ~/.snowflake/connections.toml << EOF [ci] account = "${{ vars.SNOWFLAKE_ACCOUNT }}" user = "${{ vars.SNOWFLAKE_USER }}" authenticator = "snowflake_jwt" private_key_file = "/tmp/rsa_key.p8" warehouse = "CI_WH" role = "CI_ROLE" EOF - name: Download SQLFluff config run: datasecops download sqlfluff
The exit code is 0 on success, 1 if any download fails.
Environment settings for the branch
datasecops pipeline env reads the dbt Targets from the native app (Settings › Data › dbt
Targets) and sets TARGET, SF_ROLE, SF_WAREHOUSE and TARGET_SCHEMA for the target mapped to
the branch, so pipelines don't hard-code them:
datasecops pipeline env --branch "$GITHUB_REF_NAME" # GitHub Actions: target whose Branch is this branch
datasecops pipeline env --branch "$BUILD_SOURCEBRANCH" # Azure DevOps (the full ref, not BUILD_SOURCEBRANCHNAME)
datasecops pipeline env --target unit-test # a named target
Pass the branch through the runner's environment variable, not a ${{ ... }} / $(...) expression:
those are substituted into the script before the shell runs, so a branch name containing $(...)
would execute.
--branchmatches a target's Branch, then a target named like the branch;refs/heads/is ignored and a pull request's merge ref resolves to its source branch ($GITHUB_HEAD_REFon GitHub,$SYSTEM_PULLREQUEST_SOURCEBRANCHon Azure DevOps). On Azure DevOps pass$BUILD_SOURCEBRANCH:$BUILD_SOURCEBRANCHNAMEis only the last part of the ref (release/prod->prod). Exact names win; a case-insensitive match is used only when it is unambiguous.- GitHub Actions: the values are appended to
$GITHUB_ENV. Azure DevOps: they are set with##vso[task.setvariable]. Elsewhere (or--format shell) they are printed as shell-quotedKEY=valuelines. - A target with no role, warehouse or schema leaves that variable as it is.
- The command connects with
.datasecops.yml's connection, so the CI user needs theorbit_developerapplication role. It exits1when no target matches.
DCM projects
datasecops model pull # native app -> config/dcm_model.json (this repo's projects; --full = all)
datasecops model validate
datasecops model render --check # generated definitions are current
datasecops dcm plan -p security --target PROD --summary dcm-plan.md
datasecops dcm deploy -p security --target PROD
datasecops dcm pipelines # the app-defined pipelines assigned to each project
Each DCM project usually lives in its own repository, and its pipelines (DCM PR validate, DCM deploy) plan and deploy that single project. See docs/dcm.md for the model, every command, the deployment scripts and the pipelines.
MCP Server
The package includes an MCP (Model Context Protocol) server that exposes your framework's governance configuration to AI coding assistants. Instead of static skill files, the MCP server gives AI tools live access to your native app's current rules.
Available Tools
| Category | Tools |
|---|---|
| Configuration | get_branching_rules, get_linting_rules, get_dbt_packages, get_pipeline_config, get_dbt_versions |
| Project | get_project_settings, get_project_profiles, get_deployment_targets, get_available_skills |
| Linting | lint_sql, fix_sql, lint_project |
| Source Control | validate_branch_name, get_deployment_workflow |
Setup for AI Tools
CoCo — add to .snowflake/cortex/mcp.json in your project root:
{
"mcpServers": {
"datasecops-framework": {
"type": "stdio",
"command": "datasecops-mcp",
"args": ["--connection-name", "<CONNECTION>", "--app-database", "<APP_DB>"]
},
"github": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "<your-github-pat>"
}
},
"dbt": {
"type": "stdio",
"command": "uvx",
"args": ["dbt-mcp"]
}
}
}
For Azure DevOps instead of GitHub:
{
"mcpServers": {
"datasecops-framework": {
"type": "stdio",
"command": "datasecops-mcp",
"args": ["--connection-name", "<CONNECTION>", "--app-database", "<APP_DB>"]
},
"azure-devops": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@tiberriver256/mcp-server-azure-devops"],
"env": {
"AZURE_DEVOPS_ORG_URL": "https://dev.azure.com/<your-org>",
"AZURE_DEVOPS_AUTH_METHOD": "pat",
"AZURE_DEVOPS_PAT": "<your-azure-pat>"
}
},
"dbt": {
"type": "stdio",
"command": "uvx",
"args": ["dbt-mcp"]
}
}
}
VS Code / Cursor — add to .vscode/mcp.json or .cursor/mcp.json:
{
"mcpServers": {
"datasecops-framework": {
"command": "datasecops-mcp",
"args": ["--connection-name", "<CONNECTION>", "--app-database", "<APP_DB>"]
}
}
}
Recommended MCP Server Stack
For full integration with Snowflake, dbt, and your source control platform, configure these MCP servers alongside the framework server:
| Server | Purpose | Install |
|---|---|---|
| datasecops-framework | Governance rules, linting, branch validation | Included (datasecops-mcp) |
| dbt | Lineage, model discovery, codegen, semantic layer | pip install dbt-mcp |
| GitHub | PRs, issues, CI checks, releases | npx -y @modelcontextprotocol/server-github |
| Azure DevOps | PRs, pipelines, work items, boards | npx -y @tiberriver256/mcp-server-azure-devops |
See the Getting Started Guide for full configuration instructions for each editor and platform.
Configuration
The CLI reads from a .datasecops.yml file in your project root (created by the setup script):
connection_name: "my_connection"
app_database: "MONITORIAL_ORBIT"
Project profiles, linting rules, pipeline templates, and deployment targets are all managed centrally in the native app and pulled down by the CLI.
License
MIT
Metadata
Release files for datasecops-cli 0.7.0b9
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| datasecops_cli-0.7.0b9.tar.gz | 207.5 kB | With provenance | Details for datasecops_cli-0.7.0b9.tar.gz |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Actions Reset |
|---|---|---|---|---|
| datasecops_cli-0.7.0b9-py3-none-any.whl | Python 3 | none | any | Details for datasecops_cli-0.7.0b9-py3-none-any.whl |
Total release size: 363.7 kB
Release files / datasecops_cli-0.7.0b9.tar.gz
| Download URL | datasecops_cli-0.7.0b9.tar.gz |
|---|---|
| Size | 207.5 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
ea97f1230f93607888e547bfda61cc93e2903358c4be45cdd4f2836c188385a6
|
|
BLAKE2b-256 checksum How to use checksums |
3d1b3194f3d7842e7b92a85e9e31b76cf0089ef8504e63a4074ef0a0b1eb7867
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.16
|
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 Oct 28, 2026.
Transparency logRelease files / datasecops_cli-0.7.0b9-py3-none-any.whl
| Download URL | datasecops_cli-0.7.0b9-py3-none-any.whl |
|---|---|
| Size | 156.2 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
1394ca378aad07918b33dea7b949540e3904dc572bf3ee8c9f5d9cb5d176faaf
|
|
BLAKE2b-256 checksum How to use checksums |
aa9b740cfc0577581ba6439d689981aa78ec9a1b55aac7743f0b95d68beaf1cd
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.16
|
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 Oct 28, 2026.
Transparency logSecurity for datasecops-cli 0.7.0b9
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.
Full provenance
All 2 files in this release have been uploaded with provenance metadata.
Attestation for datasecops_cli-0.7.0b9.tar.gz
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 Oct 28, 2026.
Transparency logA note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.