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 via pip install dbt (dbt 2.x) or pip 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

dbt command flags

The Development menu exposes these flags from the underlying dbt commands:

• run / build - --full-refresh; --empty runs 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) to target/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-introspect to error instead of running introspective warehouse queries; --generate-info-schema (dbt2 only) as above.
• parse - --no-partial-parse to force a full re-parse instead of only recently changed files; --generate-info-schema (dbt2 only) as above.
• lint / format (dbt2 engine only) - dbt lint supports --rules/--exclude-rules (rule codes to enable/disable), --jinja-render-mode (symbolic/rendered/turbo), and --changed to lint only git-modified files. The separate dbt format/dbt fmt command auto-formats SQL files according to .sqlfluff layout rules, with a --check dry-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 strict with 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

install-sqlfluff/install-dbt pin to the version marked active in the native app's DBT_VERSIONS config for the engine in use, falling back to the first enabled version if none is marked active (matching how the app itself resolves a version to install).

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:

1. A .datasecops.yml in the repo (already committed — contains no secrets):

   connection_name: "ci"
   app_database: "MONITORIAL_ORBIT"
   

2. A Snowflake connection in ~/.snowflake/connections.toml for 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.

• --branch matches 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_REF on GitHub, $SYSTEM_PULLREQUEST_SOURCEBRANCH on Azure DevOps). On Azure DevOps pass $BUILD_SOURCEBRANCH: $BUILD_SOURCEBRANCHNAME is 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-quoted KEY=value lines.
• 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 the orbit_developer application role. It exits 1 when 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

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:

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