@tar_9897/certus-ai

v2.2.4

Published

2 days ago

Certus CLI for compliance enforcement at the merge gate with 5 scanners, 18 blueprints, and signed evidence workflows.

0High
0Medium
0Low

compliance soc2 hipaa pci-dss iso27001 nist-800-53 fedramp cmmc gdpr ccpa hitrust security evidence audit cli devsecops sast sbom blueprints risk

Installation

Install Certus from npm:

public npm package: @tar_9897/certus-ai
optional tarball for offline installs
org API key for dashboard sync
managed GitHub App installation path for selected repositories

Install the CLI:

# npm install
npm install -g @tar_9897/[email protected]

# Delivered tarball alternative
npm install -g ./certus-ai-2.2.4.tgz

# Verify the installed CLI
certus --version
# Output: 2.2.4

certus doctor

Connect the CLI to the approved workspace:

certus login \
  --api-url https://www.getcertus.cloud \
  --api-key <org-api-key> \
  --org <org-slug>

certus status

Without an issued org API key and workspace, the CLI cannot sync evidence to Certus or attach scans to selected customer repositories.

Pilot Runbook

Use one narrow operator flow for every pilot:

# 1. Install the CLI from npm
npm install -g @tar_9897/[email protected]

# 2. Bind the CLI to the issued workspace
certus login \
  --api-url https://www.getcertus.cloud \
  --api-key <org-api-key> \
  --org <org-slug>

certus status

# 3. Install the managed GitHub App from Dashboard -> Integrations -> GitHub
#    on the approved repository scope

# 4. Require certus/compliance in GitHub branch protection or a ruleset

# 5. Run one real PR through the lane and verify stored evidence
certus evidence list

Done when:

One pilot workspace exists for the customer boundary
One operator key is issued and tested with certus status
The managed GitHub App is installed on selected repositories only
The target branch requires certus/compliance
One passing PR and one failing PR have both been observed on the same lane
The PR comment, commit status, and signed evidence pack are all present

Operator boundary:

Certus manages the hosted GitHub App, webhook receiver, merge-gate evaluation, PR reporting, and evidence storage
The pilot operator manages workspace issuance, repository approval, branch protection requiring certus/compliance, and reviewer adoption
Access to the operator dashboard should be controlled with PILOT_OPERATOR_EMAILS so pilot operations are not tied to one hardcoded mailbox
Do not widen repo scope or framework scope until one protected branch lane behaves predictably

Why Certus?

Traditional compliance tools audit code after it ships. By then, the damage is done — non-compliant code is in production, audit findings pile up, and remediation becomes a fire drill.

Certus flips that. Protected pull requests are evaluated before they merge. Certus collects scanner evidence, applies policy thresholds, and stores review output before code moves forward.

For GitHub, Certus posts the required status context certus/compliance. GitHub blocks merges only when repository branch protection or rulesets require that status check.

This is what makes Certus different:

| Traditional review | Certus | |---|---| | Audits run quarterly | Protected PRs are evaluated before merge | | Findings surface weeks later | Findings surface in the PR comment | | Evidence is collected manually | Evidence packs are signed and stored automatically | | Developers learn about issues after shipping | Developers see exactly what to fix before merging | | Compliance is a separate team's problem | Compliance is part of the developer workflow |

The CLI is publicly installable from npm. Dashboard sync, evidence storage, and managed GitHub App workflows still require an approved Certus organization workspace and API key.

Current Enforcement Boundary

Certus only blocks on evidence it can support honestly:

authored framework controls only
blocking-eligible scanner evidence only
GitHub merge-gate and dashboard policy both use the same shared policy engine
GitHub branch protection or rulesets must require certus/compliance before GitHub will block the merge button
audit grade is an audit posture score by default; enable strict grade blocking with merge_gate.enforce_audit_grade: true

Current blocking-eligible evidence:

SbomScanner findings backed by dependency inventory and OSV advisory data
SecretsScanner findings backed by direct file-content credential matches
TestScanner results only when Certus actually executes the declared test suite
SastScanner results only when Semgrep runs successfully, the control has explicit authored rule coverage, and that rule coverage applies to the repo language under review
IaCScanner results only when OPA runs successfully, the control has explicit authored policy coverage, and that policy coverage applies to the detected Kubernetes workload kinds under review

Current advisory-only paths:

unsupported frameworks
derived framework mappings
fallback or heuristic SAST
fallback or heuristic IaC findings
Terraform, Docker, and CloudFormation findings until they are backed by authored authoritative policy coverage

Current SAST authored-rule coverage:

34 authored SAST controls exist today
9 currently carry explicit Semgrep rule bindings
the remaining authored SAST controls stay advisory until their rule coverage is defined pack by pack

Current authored framework-pack coverage:

| Framework | Authored controls | Total controls | |---|---:|---:| | SOC-2 | 6 | 36 | | HIPAA | 6 | 34 | | PCI-DSS | 4 | 34 | | ISO-27001 | 4 | 40 | | NIST-800-53 | 4 | 36 | | GDPR | 4 | 21 | | FEDRAMP | 12 | 32 | | CMMC | 20 | 26 | | CIS | 14 | 18 |

Step-by-Step: Your First Scan

Let's scan a real open-source repository from start to finish.

1. Run the scan

certus scan expressjs/express --ai

This single command does everything:

  CERTUS  ·  Merge-Gate Compliance
  v2.2.4  ·  getcertus.cloud

  Cloned expressjs/express (shallow, 2.1s)
  Running 5 scanner passes ................. done (4.8s)
  Running compliance blueprints ............ done (3.2s)
  Mapping to compliance controls ........... done (0.3s)
  Signing evidence pack (SHA-256) .......... done (0.1s)
  AI compliance assessment ................. done (2.4s)

2. Read the results

  ─── Scan Results ─────────────────────────────────

  Grade       B+  (84/100)
  Verdict     PASSED
  Duration    12.8s
  Total       12 findings
  Critical    0
  High        2
  Medium      6
  Low         4
  Controls    24/29 passed
  Blueprints  14/18 passed

  ─── Policy Checks ────────────────────────────────

  Advisory  Minimum grade: B+ recorded for reporting
  Pass  Critical findings: 0 (max allowed: 0)
  Pass  High findings: 2 (max allowed: 5)
  Advisory  Coverage: 72% observed from repository artifacts

  ─── Evidence Pack ────────────────────────────────

  Pack ID     ep_cf79c0d0d9b7
  SHA-256     cf79c0d0d9b7f708a49b...
  Integrity   HASH VERIFIED

3. Review the report

A JSON report is saved automatically:

cat certus-report-express-2026-03-23.json | jq '.grade, .score, .summary'

4. View findings in detail

# Open the terminal dashboard
certus dashboard

# Or export as HTML
certus audit --framework SOC-2

GitHub App (Merge Gate)

For the hosted product, the GitHub App is managed by Certus. Approved pilot organizations install the existing app into selected repositories and let the hosted webhook receiver process PR events.

Hosted product flow

Sign in to the dashboard at https://www.getcertus.cloud/login
Open Dashboard -> Integrations -> GitHub
Start the install flow for the approved pilot organization
Install the Certus GitHub App only on selected pilot repositories
Return to the dashboard and confirm the installation is connected

Hosted users do not need:

the GitHub App private key
the webhook secret
the GitHub App setup wizard

Certus owns the hosted receiver at:

https://www.getcertus.cloud/api/webhooks/github

Self-hosted or operator flow

Run this only if you are operating your own Certus deployment and your own GitHub App:

certus github setup

That wizard stores local GitHub App credentials in ~/.certus/config.json for self-hosted merge-gate operation.

What happens after install

From now on, every PR opened on those selected repositories will automatically:

Trigger a compliance scan via webhook
Post the certus/compliance commit status and, when permissions allow, a GitHub Check Run named Certus Compliance
Post a detailed PR comment with findings and remediation steps
Let GitHub block the merge when branch protection or rulesets require certus/compliance
Sign and store the evidence pack

No CI YAML is required for the GitHub App path. Repository sync is enabled through the pilot workspace and managed GitHub App installation. If you want repo-specific policy thresholds, framework selection, or strict audit-grade blocking, add an optional .certus.yml.

Strict merge-gate example:

merge_gate:
  enabled: true
  block_on_failure: true
  max_critical: 0
  max_high: 5
  min_grade: C
  enforce_audit_grade: true

Without enforce_audit_grade: true, a PR can show Audit Grade F and still pass the merge gate if the blocking-eligible critical and high findings are within policy. That separation is intentional: the audit grade is broader posture, while the merge gate blocks only on enforceable signals.

Full Walkthrough: Real Repo Example

Here's a complete example scanning a private GitHub repository that has been approved for the pilot workspace, reviewing a PR, and verifying evidence.

Authenticate

# Hosted product: install the Certus GitHub App from the dashboard
# on selected pilot repositories, then connect the CLI to the active workspace
certus login \
  --api-url https://www.getcertus.cloud \
  --api-key <org-api-key> \
  --org <org-slug>

# Optional: GitHub token for CLI-only GitHub API access
certus github login
# Paste a short-lived token when prompted; do not commit it
# Scope access to the minimum repositories required

Scan a repository

certus github scan acme-corp/payment-api

Output:

  Mode       GitHub Authenticated Scan
  Target     acme-corp/payment-api
  Branch     main
  Visibility private
  Commit     a1b2c3d4e5f6

  Running 5 scanner passes ................. done
  Running compliance blueprints ............ done
  Mapping to compliance controls ........... done
  Signing evidence pack .................... done

  ─── Scan Results ─────────────────────────────────

  Grade       A-  (91/100)
  Verdict     PASSED
  Controls    27/29 passed
  Blueprints  16/18 passed

  Report saved to certus-report-payment-api-2026-03-23.json

Scan a specific PR

certus github pr acme-corp/payment-api 42

This will:

  Mode       PR Compliance Scan
  Target     acme-corp/payment-api
  PR         #42

  Title      Add Stripe webhook handler
  Author     jane-dev
  Branch     feature/stripe-webhooks -> main
  Changes    +284 / -12 across 8 files

  Creating check run (in_progress) ......... done
  Cloning PR branch ....................... done
  Running 5 scanner passes ................. done
  Running compliance blueprints ............ done
  Completing check run — PASSED ............ done
  Posting commit status .................... done
  Posting PR comment ....................... done
  Evidence stored (ep_8f3a2b1c)

  PR #42 scan complete — PASSED
  View PR: https://github.com/acme-corp/payment-api/pull/42

Preview what would be posted (dry run)

certus github pr acme-corp/payment-api 42 --dry-run

Post only a comment (skip check run)

certus github pr acme-corp/payment-api 42 --comment-only

Verify evidence integrity

# List all evidence packs
certus evidence list

# Verify a specific pack
certus evidence verify ep_8f3a2b1c

# Output:
#   Pack ID          ep_8f3a2b1c
#   SHA-256 (stored) 8f3a2b1c4d5e6f...
#   SHA-256 (computed) 8f3a2b1c4d5e6f...
#   Hash Match       YES
#   JWS Signature    VALID
#   Verdict          FULLY VERIFIED

Auto-fix findings

# See what would be fixed
certus fix --dry-run

# Apply fixes
certus fix --yes

# Re-scan to verify
certus scan . --no-clone --ai

Predict risk before merging

certus risk .

Replay a past merge

certus runback --pr 42

Command Reference

Core — Scanning & Analysis

| Command | What it does | |---|---| | certus scan <repo> [--ai] | Primary command. Clones a repo (or GitHub URL), runs all 5 scanners, executes 18 blueprints, maps findings into the control registry, signs evidence, and generates an AI assessment. Use --framework HIPAA to focus on one framework. Use --no-clone to scan the current directory. | | certus verify [--repo owner/name] | Run compliance verification with framework control display. | | certus init | Initialize a .certus.yml workspace configuration file in the current repo. | | certus risk <path> | Pre-merge risk prediction. Shows risk score, evidence completeness, and control coverage. | | certus fix [--dry-run] [--yes] | Auto-remediate findings. Reads the latest scan report and generates patches for 12 common compliance gaps (gitignore, secret scanning CI, Dockerfile fixes, security headers, etc.). |

GitHub Integration

| Command | What it does | |---|---| | certus github setup | Self-hosted/operator only. Walks through App ID, private key, webhook secret, and client ID. Saves local GitHub App configuration to ~/.certus/config.json. Hosted-product users should install the managed app from the dashboard instead. | | certus github login | Authenticate with a short-lived token for CLI-only access. Verifies the token and saves local configuration. | | certus github status | Show GitHub connection status: username, organizations, API rate limit. | | certus github repos [--org <name>] | List accessible repositories. Filter by organization. | | certus github scan <owner/repo> | Scan a GitHub repository with full authentication. Supports private repos. Clones, scans, stores evidence, and displays results. | | certus github pr <owner/repo> <number> | Merge gate command. Scans a PR branch, creates a Check Run (in_progress then completed), posts a commit status, posts a rich PR comment, and stores signed evidence. Use --dry-run to preview without posting. | | certus github comment <owner/repo> <number> | Post (or update) a compliance comment on a PR. Uses the latest scan report or runs a fresh scan. | | certus github check <owner/repo> <sha> | Create a Check Run on a specific commit. Falls back to commit status if Check Run permissions aren't available. |

Configuration & Authentication

| Command | What it does | |---|---| | certus config show | Display current configuration (API URL, org, key sources). | | certus config setup | Interactive setup wizard for API keys and settings. | | certus config set <key> <value> | Set a specific config value. Keys: api-url, api-key, org, openai-key. | | certus config reset | Reset all configuration to defaults. | | certus login [--api-url] [--api-key] [--org] | Authenticate with the Certus platform API. | | certus status | Check API connectivity, authentication status, workspace info. | | certus ping | Test API connectivity and response time across endpoints. |

Evidence & Compliance

| Command | What it does | |---|---| | certus evidence list | List all evidence packs (checks local reports first, falls back to API). | | certus evidence get <id> | Get detailed evidence pack information. | | certus evidence verify <id> | Verify SHA-256 hash + JWS signature integrity. | | certus evidence export <id> [--format json or pdf] | Export an evidence pack. | | certus evidence query [--pr 42] [--repo owner/name] | Find evidence packs by PR number or repository. | | certus blueprint list | List all 18 compliance blueprints with descriptions. | | certus blueprint run <slug> [--pr 42] | Run a specific blueprint against a PR or codebase. | | certus blueprint preview <slug> | Preview what a blueprint checks without executing. | | certus policy list [--framework HIPAA] | List all framework controls. Filter by framework. | | certus policy validate <file> | Validate a policy definition file. |

Analysis & Reporting

| Command | What it does | |---|---| | certus history | Show scan history with compliance grade trends over time. | | certus dashboard | Full compliance dashboard in the terminal: grade, trends, top findings. | | certus cost | Estimate regulatory fine exposure and remediation effort. | | certus audit --framework SOC-2 | Generate a compliance audit document (HTML). | | certus explain SOC-2:CC6.1 | Explain any compliance control in plain English. Works fully offline. | | certus compare old.json new.json | Compare two scan reports side-by-side. | | certus drift | Detect compliance drift since last passing baseline. | | certus benchmark | Compare compliance posture against built-in illustrative industry baselines. | | certus attest --framework HIPAA | Generate a hashed compliance attestation summary from report data. | | certus export --format sarif | Export in SARIF, HTML, Markdown, CSV, or OSCAL format. | | certus runback [--pr 42] | Replay stored verification context from local report files. |

Git Hooks

| Command | What it does | |---|---| | certus activate | Install pre-commit + pre-push hooks for automatic compliance scanning on every commit. | | certus deactivate | Remove Certus git hooks and restore backups. |

Diagnostics

| Command | What it does | |---|---| | certus doctor | Diagnose installation, configuration, connectivity. Reports framework/blueprint/scanner/integration counts. | | certus logs | View scan and verification logs. | | certus diagnostics export | Export diagnostic information for troubleshooting. |

Evidence Signing & Verification

Every scan produces a tamper-proof evidence pack. Auditors can independently verify integrity without access to Certus.

How it works

Layer 1 — SHA-256 Content Hash

Every evidence pack is hashed over a recursively deep-sorted canonical JSON representation. This produces identical hashes for semantically identical data, regardless of property order.

Layer 2 — HMAC-SHA256 JWS Signature (optional)

When EVIDENCE_SIGNING_KEY is set, Certus produces a JWS (JSON Web Signature) for non-repudiation:

{sha256-hash}::{base64-header}.{base64-payload}.{base64-signature}

Setting up signing

# Generate a signing key
openssl rand -hex 32

# Set it for all scans
export EVIDENCE_SIGNING_KEY=your-generated-key

# Scan — evidence will be automatically signed
certus scan your-org/your-repo --ai

# Verify
certus evidence verify ep_abc123

Verification verdicts

| Verdict | Meaning | |---|---| | FULLY VERIFIED | SHA-256 hash matches AND JWS signature is valid | | HASH VERIFIED | SHA-256 hash matches, no JWS was attached | | HASH VALID, JWS unverifiable | Hash OK but JWS failed (wrong key or tampered) | | INTEGRITY FAILURE | Hash mismatch — evidence was modified after signing |

Auto-Remediation

Certus includes 12 built-in fixers that generate patches for common compliance gaps:

certus scan your-org/your-repo --ai   # Step 1: Scan
certus fix --dry-run                   # Step 2: Preview what would change
certus fix --yes                       # Step 3: Apply fixes
certus scan . --no-clone --ai          # Step 4: Verify improvement

What gets fixed

| Fixer | Creates/Modifies | Frameworks | |---|---|---| | .gitignore | Standard ignore entries | All | | Secret scanning CI | secret-scan.yml (gitleaks) | SOC-2, PCI-DSS | | Security scanning CI | security-scan.yml (CodeQL + npm audit) | NIST-800-53 | | Incident response | INCIDENT_RESPONSE.md + SECURITY.md | SOC-2, HIPAA | | Dockerfile USER | Non-root container user | CIS, NIST-800-53 | | Dockerfile HEALTHCHECK | Container health check | CIS | | Security headers | Helmet.js middleware | SOC-2, PCI-DSS | | Environment protection | Deployment workflow with reviewers | SOC-2 | | Monitoring | Health check + audit logging module | HIPAA, SOC-2 | | CI pipeline | GitHub Actions CI workflow | NIST-800-53 | | Compliance config | .certus.yml workspace config | All | | PR template | Compliance checklist for PRs | All |

Scanners (5)

These scanner passes run in parallel and feed evidence into policy evaluation, blueprint analysis, and control mapping. Blocking behavior depends on scanner trust and explicit authored control coverage, not on scanner presence alone.

| Scanner | What it reports | |---|---| | TestScanner | Executes the declared test suite when Certus can run it; otherwise falls back to framework discovery, test-file analysis, and coverage artifacts | | SastScanner | Semgrep-backed static analysis when Semgrep is installed and the authored rule bundle applies to the repo language; otherwise falls back to advisory pattern checks | | SbomScanner | Dependency inventory, OSV advisory matches, license issues, and CycloneDX SBOM generation | | IaCScanner | OPA-backed blocking for explicitly bound Kubernetes workload configuration controls; Terraform, Docker, and CloudFormation checks remain advisory | | SecretsScanner | Direct file-content matching for API keys, tokens, passwords, private keys, and connection strings |

Blueprints (18)

Blueprints perform deep file-level analysis of your codebase.

| # | Blueprint | What it checks | Key Frameworks | |---|---|---|---| | 1 | Security Headers | HSTS, CSP, X-Frame-Options, CORS configuration | SOC-2, PCI-DSS | | 2 | Auth Hardening | MFA, session management, password policies | SOC-2, HIPAA, ISO-27001 | | 3 | Audit Logging | Audit trail completeness, log integrity | SOC-2, HIPAA, PCI-DSS | | 4 | Dependency Hygiene | Vulnerable, outdated, or unmaintained dependencies | SOC-2, NIST-800-53 | | 5 | Secrets Rotation | Rotation policies, hardcoded credentials | PCI-DSS, ISO-27001 | | 6 | PII Redaction | PII exposure in logs, responses, error messages | HIPAA, GDPR | | 7 | Runtime Shielding | Rate limiting, helmet, CSRF protections | SOC-2, PCI-DSS | | 8 | Control Map | Control mapping coverage and gap analysis | All | | 9 | Cloud Posture | AWS/GCP/Azure configuration security | NIST-800-53, FedRAMP | | 10 | Input Validation | Input sanitization and validation patterns | PCI-DSS, NIST-800-53 | | 11 | Error Handling | Stack trace exposure, graceful degradation | SOC-2, ISO-27001 | | 12 | Data Encryption | Encryption at rest and in transit, key management | HIPAA, PCI-DSS, GDPR | | 13 | Access Control | RBAC, authorization checks, privilege escalation | SOC-2, HIPAA, ISO-27001 | | 14 | API Security | API auth, rate limiting, input validation | PCI-DSS, NIST-800-53 | | 15 | Container Security | Dockerfile best practices, non-root, multi-stage | CIS, NIST-800-53 | | 16 | CI/CD Security | Pipeline security, pinned actions, secret scanning | SOC-2, NIST-800-53, CIS | | 17 | Network Security | TLS config, CORS, firewall rules, DNS security | PCI-DSS, NIST-800-53 | | 18 | Incident Response | IR documentation, monitoring, backup/recovery | SOC-2, HIPAA, NIST-800-53 |

Frameworks (24)

| Framework | Controls | Description | |---|---|---| | SOC 2 | 36 | Trust Services Criteria (CC, A, PI, C, P series) | | HIPAA | 34 | Security Rule safeguards | | PCI-DSS | 34 | Payment Card Industry DSS v4.0 | | ISO 27001 | 40 | Annex A information security controls (2022) | | NIST 800-53 | 36 | Federal information security controls Rev 5 | | GDPR | 21 | EU General Data Protection Regulation | | FedRAMP | 32 | Federal Risk and Authorization Management | | CMMC | 26 | Cybersecurity Maturity Model Certification | | CCPA | 20 | California Consumer Privacy Act | | HITRUST | 30 | Health Information Trust Alliance CSF | | NIST CSF | 25 | NIST Cybersecurity Framework | | CIS | 18 | Center for Internet Security Controls | | SOX | 20 | Sarbanes-Oxley Act IT controls | | FISMA | 20 | Federal Information Security Modernization Act | | FERPA | 15 | Family Educational Rights and Privacy Act | | GLBA | 15 | Gramm-Leach-Bliley Act | | NERC CIP | 15 | North American Electric Reliability Corporation | | PIPEDA | 12 | Personal Information Protection (Canada) | | LGPD | 15 | Lei Geral de Protecao de Dados (Brazil) | | APRA CPS 234 | 15 | Australian Prudential Regulation Authority | | CSA STAR | 20 | Cloud Security Alliance STAR | | ITAR | 15 | International Traffic in Arms Regulations | | COBIT | 20 | Control Objectives for IT | | SOC 3 | 15 | Trust Services Criteria (public report) |

SDK Reference

Use Certus programmatically in your own tools and pipelines.

import {
  // Core client
  CertusClient,

  // Evidence engine
  EvidencePipeline,
  signData,
  verifySignature,
  computeHash,
  canonicalize,
  verifyJws,
  mapToControls,

  // Scanners
  TestScanner,
  SastScanner,
  SbomScanner,
  IaCScanner,
  SecretsScanner,

  // Frameworks & Blueprints
  getAllFrameworks,
  getFramework,
  runAllBlueprints,
  runBlueprints,
  getRegisteredSlugs,

  // Config
  loadConfig,
  saveConfig,
  clearConfig,
  isAuthenticated,
} from '@tar_9897/certus-ai'

Run a full scan

const pipeline = new EvidencePipeline()
const result = await pipeline.run({
  repoFullName: 'acme/api',
  prNumber: 42,
  headSha: 'abc123def456',
})

console.log(result.status)           // 'complete'
console.log(result.coveragePercent)  // 94
console.log(result.criticalFindings) // 0
console.log(result.signatureHash)    // "hash::jws"

Run individual scanners

const ctx = { repoFullName: 'acme/api', prNumber: 42, headSha: 'abc123' }

const [tests, sast, sbom, iac, secrets] = await Promise.all([
  new TestScanner().scan(ctx),
  new SastScanner().scan(ctx),
  new SbomScanner().scan(ctx),
  new IaCScanner().scan(ctx),
  new SecretsScanner().scan(ctx),
])

Sign and verify evidence

// SHA-256 only
const hash = await signData(evidenceData)

// SHA-256 + JWS (requires EVIDENCE_SIGNING_KEY env var)
process.env.EVIDENCE_SIGNING_KEY = 'your-secret'
const hashWithJws = await signData(evidenceData)
// Returns: "abc123...::eyJhbGci..."

// Verify
const isValid = await verifySignature(data, hashWithJws) // true

TypeScript types

import type {
  CertusConfig, EvidencePack, ScanResult, Finding,
  ControlMapping, Blueprint, BlueprintRun, BlueprintFinding,
  ComplianceControl, FrameworkDefinition, FrameworkControl,
  Repository, Organization, VerifyResult, PolicyDefinition,
} from '@tar_9897/certus-ai'

Connecting CLI to the Dashboard

The Certus dashboard at getcertus.cloud is the org-scoped browser workspace for scan results, repository management, evidence history, and compliance trends.

# 1. Log in to the dashboard at https://www.getcertus.cloud/login

# 2. Copy your organization API key from Settings

# 3. Connect the CLI
certus login \
  --api-url https://www.getcertus.cloud \
  --api-key <your-org-api-key> \
  --org <your-org-slug>

# 4. Verify the connection
certus status

Once connected, CLI scans sync evidence packs into the active organization workspace. Dashboard data is shared across authorized members of that organization rather than isolated per individual user.

Configuration

Config file

Stored at ~/.certus/config.json (permissions: 600).

certus config show     # View current config
certus config setup    # Interactive wizard
certus config set api-key <certus-api-key>   # Set a value
certus config reset    # Reset to defaults

Environment variables

| Variable | Purpose | |---|---| | CERTUS_API_URL | Override API base URL | | CERTUS_API_KEY | API key (overrides stored config) | | CERTUS_ORG_SLUG | Organization slug | | CERTUS_AI_PROVIDER | Optional managed AI provider selection | | GITHUB_TOKEN | Optional short-lived token for CLI-only authenticated scans | | EVIDENCE_SIGNING_KEY | HMAC-SHA256 key for JWS evidence signatures | | CERTUS_DASHBOARD_SYNC | Enable/disable dashboard sync (true/false) |

Workspace config

Create a .certus.yml in your repository root:

certus init

Platform Routes

| Surface | URL | |---|---| | Marketing + product | https://www.getcertus.cloud | | Documentation | https://www.getcertus.cloud/docs | | Login | https://www.getcertus.cloud/login | | Dashboard | https://www.getcertus.cloud/dashboard | | Configuration | https://www.getcertus.cloud/docs#configuration | | Changelog | https://www.getcertus.cloud/changelog |

Requirements

Node.js 20+ (required for the current CLI runtime and release support boundary)
npm 9+
Git (for certus scan repository cloning)

License

Proprietary. See LICENSE for full terms.