Скил security-baseline — девять кластеров для выпускаемых артефактов
Скил security-baseline в Datarim определяет S1–S9: девять кластеров правил безопасности, действующих всякий раз, когда агент выпускает скил, шаблон, скрипт или рабочий процесс CI. Модель угроз начинается с того, как ИИ-агенты распространяют код.
Когда ИИ-агент использует скил, он копирует паттерны этого скила в среду выполнения потребительского проекта. Одна небезопасная инструкция в выпущенном артефакте Datarim — паттерн установки curl | bash, неэкранированное раскрытие переменной, встроенный в код учётный данные — распространяется на каждый проект, использующий Datarim. Скил security-baseline определяет нижний предел, который это предотвращает.
Скил был создан по результатам корпоративного аудита безопасности в апреле 2026 года и охватывает девять кластеров: S1 по S9. Это документ, который загружается агентами-ревьюерами и агентами безопасности при планировании, контроле качества и проверке соответствия каждый раз, когда задача касается выпускаемых артефактов.
S1 и S2 — Shell и Python
S1 применяется к каждому shell-скрипту и каждому блоку bash/sh в выпускаемых скилах, агентах, командах, шаблонах и документации. Обязательные правила включают строгий режим (set -euo pipefail), экранирование раскрытий переменных, проверку позиционных аргументов, экранирование терминаторов heredoc, запрет eval для входных данных, контролируемых пользователем, и полный запрет curl | bash. CI-шлюз — shellcheck для зафиксированных файлов *.sh.
S2 применяется к Python. Ключевые правила: запрет subprocess.run с shell=True для входных данных пользователя или файловой системы; атомарная запись учётных данных с режимом 0o600; запрет yaml.load без SafeLoader; запрет вызовов requests с verify=False. CI-шлюз — bandit -ll -ii.
S3 и S4 — учётные данные и цепочка поставок
S3 охватывает учётные данные и секреты. Никаких жёстко прописанных значений ни в каком выпускаемом артефакте. Канонический формат ссылки на учётные данные в выпускаемых шаблонах — путь через переменную окружения; проектно-специфичные пути принадлежат CLAUDE.md проекта, а не среде выполнения фреймворка. При случайном коммите секрета: 24 часа на ротацию в источнике, очистку истории git, принудительный push и уведомление клонов.
S4 охватывает цепочку поставок. GitHub Actions должны быть закреплены за 40-символьными SHA коммитов, а не тегами или ветками. Каждый рабочий процесс должен иметь явный блок permissions:, начинающийся с минимальных привилегий. Каждый архив релиза включает CycloneDX или SPDX SBOM. Артефакты релиза должны быть подписаны через cosign, а рабочий процесс релиза должен создавать аттестацию происхождения сборки SLSA уровня 2. Рецепт проверки со стороны потребителя живёт в скиле release-verify.
S5 — Markdown как исполняемые инструкции
ИИ-агенты воспринимают выпущенный Markdown как исполняемые знания. S5 вытекает из этого факта. Примеры в скилах и шаблонах должны использовать заполнители и заведомо синтетические строки, а не реальные OAuth client ID или внутренние имена хостов. Любой блок, обучающий тому, что делать нельзя — показанный только для того, чтобы исправленный вариант был понятен, — должен быть обёрнут в ограждение антипримера: <!-- security:counter-example --> с исправленным паттерном сразу после. CI-шлюзы пропускают эти блоки при автоматическом сканировании.
S6, S7, S8, S9
S6 определяет гигиену репозитория: LICENSE, SECURITY.md, CODEOWNERS, конфигурация Dependabot, защита веток и защита тегов. Защита тегов важна именно потому, что аттестация SLSA признаётся недействительной при повторном создании тега после релиза.
S7 — это CI-шлюз верификации: набор обязательных задач, блокирующих слияние — shellcheck, bandit, semgrep, gitleaks, trufflehog, actionlint, zizmor, osv-scanner, bats и regex-сканирование markdown-policy. S8 сопоставляет каждый кластер S1–S7 с контролями в OWASP ASVS v5, SOC 2, ISO 27001:2022 и CIS Controls v8 — в информационных целях, не как сертификация. S9 охватывает отклонения и реагирование на инциденты: никакого ослабления правил без одобрения архитектора, каждая новая находка в течение семи дней создаёт регрессионный тест или запись о принятом риске в реестре исключений.
Общий контекст фреймворка описывает пост что такое Datarim. Рецепт верификации S4 со стороны потребителя описан в статье о скиле release-verify.