The security-baseline Skill — Nine Clusters for Shipped Artefacts
Datarim's security-baseline skill defines S1–S9: nine security rule clusters that apply whenever an agent ships a skill, template, script, or CI workflow. The threat model starts with how AI agents spread code.
When an AI agent uses a skill, it copies that skill's patterns into a consumer project's runtime. A single unsafe recipe in a shipped Datarim artefact — a curl | bash install pattern, an unquoted parameter expansion, a hardcoded credential placeholder — propagates to every project that runs Datarim. The security-baseline skill defines the floor that prevents this.
The skill was produced from a corporate security audit in April 2026 and covers nine clusters: S1 through S9. It is the document loaded by reviewer and security agents during planning, QA, and compliance review whenever a task touches shipped artefacts.
S1 and S2 — Shell and Python
S1 applies to every shell script and every bash/sh fenced block in shipped skills, agents, commands, templates, and docs. Required rules include strict mode (set -euo pipefail), quoted parameter expansions, validated positional arguments, quoted heredoc terminators, no eval on user-controlled input, and no curl | bash anywhere. The CI gate is shellcheck on committed *.sh files.
S2 applies to Python. The key rules: no subprocess.run with shell=True on input the user or filesystem controls; atomic credential writes with mode 0o600; no yaml.load without SafeLoader; no requests calls with verify=False. The CI gate is bandit -ll -ii.
S3 and S4 — Credentials and Supply Chain
S3 covers credentials and secrets. No hardcoded values in any shipped artefact. The canonical reference shape for credential discovery in shipped templates is an env-var path — project-specific locations belong in the project's own CLAUDE.md, not in the framework runtime. The rotation policy on accidental commit is 24 hours: rotate at the source, scrub git history, force-push, notify clones.
S4 covers supply chain. GitHub Actions must be pinned to 40-character commit SHAs, not tags or branches. Every workflow needs an explicit permissions: block starting from least privilege. Every release tarball ships a CycloneDX or SPDX SBOM. Release artefacts must be cosign-signed, and the release workflow must emit a SLSA Level 2 build-provenance attestation. The consumer-side verify recipe lives in the release-verify skill.
S5 — Markdown as executable instructions
AI agents treat shipped Markdown as executable knowledge. S5 follows from that fact. Examples in skills and templates must use placeholders and obviously synthetic strings, never real OAuth client IDs or internal hostnames. Any block that teaches what not to do — shown only to make the corrected version intelligible — must be wrapped in a counter-example fence: <!-- security:counter-example --> with the corrected pattern immediately following. CI gates skip those blocks during automated scanning.
S6, S7, S8, S9
S6 defines repo hygiene: LICENSE, SECURITY.md, CODEOWNERS, Dependabot configuration, branch protection, and tag protection. Tag protection matters specifically because SLSA provenance is invalidated by a retag after release.
S7 is the CI verification gate — the set of required jobs that block merge: shellcheck, bandit, semgrep, gitleaks, trufflehog, actionlint, zizmor, osv-scanner, bats, and a markdown-policy regex scan. S8 maps each S1–S7 cluster to controls in OWASP ASVS v5, SOC 2, ISO 27001:2022, and CIS Controls v8 — informative, not certificative. S9 covers drift and incident response: no rule relaxation without architect approval, every new finding produces a regression test or an accepted-risk entry in the suppression registry within seven days.
Read what Datarim is for the broader context, or see the release-verify skill for the S4 consumer-side verification recipe.