Security Baseline

Overview

Security Baseline is the canonical S1–S11 ruleset for Datarim shipped artifacts (skills, agents, commands, templates, scripts, docs). Loaded by reviewer, security, and compliance agents during /dr-plan, /dr-qa, /dr-compliance, and /dr-do when touching production code paths. Origin: corporate security audit, 2026-04-28 (6 findings: 2× HIGH command injection, 4× MEDIUM SSH/credentials/supply-chain).

Threat Model

Datarim ships skills, templates, agents, and commands that AI agents copy into runtime and execute, often with elevated privileges (root SSH, OAuth tokens with write scope, package installation). A vulnerable line in a shipped script is replicated into every consumer's production runbook. A documented curl | bash recipe in a skill becomes the canonical install pattern across the ecosystem. Every shipped artifact is production code under attack.

Rule Clusters (Quick Reference)

Cluster	Scope	Required CI gate
S1	Shell scripts + embedded shell blocks	shellcheck (committed .sh)
S2	Python + python-fenced blocks	bandit -ll -ii
S3	Credentials, secrets, tenant identifiers	gitleaks, trufflehog
S4	Supply chain	actionlint, zizmor, osv-scanner, signed releases
S5	Markdown documentation as code	regex anti-pattern grep (markdown-policy)
S6	Repo hygiene (LICENSE, SECURITY.md, …)	manifest presence checks
S7	CI verification gate (this matrix)	meta — every required job above blocks merge
S8	Standards mapping (S1–S7 → ASVS / SOC 2 / …)	(no automated gate — informative)
S9	Drift, evolution, incident response	bats regression tests + suppression registry sync
S10	Branch-integration floor	branch-integration-guard PreToolUse hook (runtime)
S11	Untrusted-content boundary review gate	distinct adversarial review (pre-merge; CI-green alone does not clear it)

S1 — Shell Scripts

• Strict mode at the top of every script: set -euo pipefail + quoted IFS=$'\n\t'.
• Quote every parameter expansion ("$1", "$@"). Unquoted expansion is a defect.
• Validate positional arguments against an explicit regex before use.
• Quoted heredoc terminators (<<'EOF') when the heredoc carries variables that must reach the consumer literally.
• No eval on user-controlled or filesystem-derived input.
• No curl | bash install recipes; hash-pinned tarballs or package-manager only.
• No ssh -o StrictHostKeyChecking=no; bootstrap host keys via ssh-keyscan -H.
• shellcheck -S warning clean; suppression must cite reason + finding-ID + reviewer inline.

S2 — Python

• No shell=True with user-controlled input; use subprocess with argv lists.
• Atomic mode-0o600 credential writes via O_EXCL.
• No eval / pickle.loads / yaml.load on untrusted input.
• requests verify=True (default; never set to False for "convenience").
• SHA-256 or stronger for hashes (no MD5 / SHA-1 outside legacy).
• bandit -ll -ii clean.

S3 — Credentials & Secrets

• No hardcoded secrets, API keys, tenant IDs in code or docs.
• Generic env-var paths (${PROJECT_CREDS_DIR}) — no host-specific paths shipped.
• Secrets via env / Vault / prompt only — never in .env committed to git.
• .gitignore coverage: *.pem, *.key, *.token, **/Credentials/**.
• Rotation policy on accidental commit: rotate within 24h, scrub history, force-push, notify clones.

S4 — Supply Chain

• No curl | bash; hash-pinned installs only.
• GitHub Actions pinned to commit SHA + explicit permissions: block.
• SBOM (CycloneDX) shipped per release.
• Signed releases (Sigstore cosign keyless, GitHub OIDC).
• SLSA L2 build provenance via actions/attest-build-provenance.
• Dependabot / Renovate enabled on every repo.
• Consumer-side verify: see the release-verify skill.

S5 — Markdown as Code

• Placeholders, not real IDs in shipped recipes.
• Never prescribe unsafe patterns as a primary recipe.
• Counter-example fence syntax for teaching unsafe patterns: <!-- security:counter-example --> … <!-- /security:counter-example -->.
• Embedded fenced blocks (```bash, ```python) inherit the corresponding S1 / S2 rules.

S6 — Repo Hygiene

Every shipped repo (Datarim itself and every project it scaffolds) SHOULD ship: LICENSE, SECURITY.md, CODE_OF_CONDUCT.md, CONTRIBUTING.md, CODEOWNERS, dependabot.yml, branch protection rules, tag protection rules.

S7 — CI Verification Gate

Required jobs (every PR / push to main): shellcheck, bandit, semgrep, gitleaks, trufflehog, actionlint, zizmor, osv-scanner, regression bats, markdown-policy. Each blocks merge on non-zero finding.

S8 — Standards Mapping

S1–S7 map to OWASP ASVS v5, SOC 2 CC controls, ISO 27001 Annex A, CIS Controls v8. Full table in documentation/reference/standards-mapping.md; informative — no automated gate, used in audits.

SOC 2 Progress

Status: technical control mapping in progress. Datarim has not published a SOC 2 report and this page does not claim certification or attestation.

Covered (9/9 baseline → SOC 2 Common Criteria): all 9 S-clusters (S1–S9) map to at least one SOC 2 Common Criterion — CC6 (Logical & Physical Access), CC7 (System Operations), CC8 (Change Management), CC9 (Risk Mitigation). The baseline is technical scaffolding: secure-by-default code, signed releases, drift detection, public-surface hygiene, network-exposure tiering.

Outstanding (operational evidence): Datarim is a dev-tool baseline, not an applicative SOC 2 control set. The following remain the consumer project's responsibility, not the framework's:

• Formal SOC 2 Type I readiness review (control-design walkthrough with an external auditor) — not yet scheduled.
• Evidence-collection workflow (ticketing trail, access reviews, vendor management register) — outstanding at the framework layer.
• Operational artefacts for consumer adoption: incident-response runbooks, business-continuity / disaster-recovery exercises, HR controls, vendor risk register.

Next evidence: keep the control mapping current, define evidence ownership and retention, complete an internal readiness review, and engage an independent service auditor before making any readiness or report claim. No audit date is promised here.

S9 — Drift & Evolution

• No relaxation without architect approval.
• New finding → rule update + regression test in tests/security/ within 7 days.
• Suppression registry: tests/security/baseline.json — every # shellcheck disable, # nosec, # nosemgrep entry MUST cite reason + finding-ID + reviewer.

S10 — Branch-Integration Floor

An agent MUST NOT merge or push an integration branch (dev, develop, development, integration, staging) directly into a protected branch (main, master, trunk, release); protected branches receive changes only through a pull/merge request. Pulling a protected branch down into a working branch is allowed. Enforced at runtime by the branch-integration-guard PreToolUse hook, which inspects the structured command only; there is no env var, flag or in-band text that disables it.

S11 — Untrusted-Content Boundary Review Gate

Any change that introduces or alters a boundary where untrusted bytes enter a model context (retrieved documents, fetched web or tool output, user files, database rows) needs a distinct, findings-only adversarial security review before merge. Green CI does not clear this gate. The review covers at least fence-escape, nonce predictability, trust-class cross-promotion, provenance forgery, size-guard bypass and fail-open behaviour; findings follow the S9 obligation.

When It's Used

Loaded by reviewer, security, and compliance agents during /dr-plan, /dr-qa, /dr-compliance, /dr-do. Cited from AGENTS.md § Security Mandate. Companion: security skill (operational recipes — git history scrub, Tailscale+VPN coexistence, recon-vs-compromise heuristics) and release-verify skill (S4 consumer-side entry point).