Скил security — рецепты безопасности внутри рабочего процесса

Советы по безопасности, которые поступают после реализации, обходятся дорого. Обнаружить открытый секрет в истории коммитов или уязвимую зависимость в продакшне куда затратнее, чем поймать проблему на этапе планирования. Скил security нужен для того, чтобы security-рассуждения оставались внутри рабочего процесса, а не за его пределами.

Скил охватывает четыре области: аутентификация и авторизация, защита данных, безопасность зависимостей и набор операционных рецептов для инцидентов, которые повторяются в разных проектах. В каждой области — конкретные правила, а не общие принципы. Например, правило о кешированных секретах указывает: если горячий кеш (Redis, Memcached, in-process map) хранит «сырые» bearer-учётные данные — даже с ограниченным TTL и сетевой изоляцией — это необходимо зафиксировать в реестре принятых рисков проекта. Причина: оператор с доступом к кешу может извлечь секрет в открытом виде, не проходя через журнал аудита основного хранилища.

Аутентификация и валидация входных данных

Базовые правила просты: никаких хардкоженных секретов, валидация всех входных данных на стороне сервера, принцип минимальных привилегий для API-ключей. Защита данных добавляет ещё три: санитизация пользовательского ввода против XSS и SQL-инъекций, шифрование чувствительных данных в покое и в транзите, отказ от логирования персональных данных.

Аудит зависимостей сформулирован нейтрально к технологическому стеку. Скил предписывает агенту выполнять «нативную для пакетного менеджера команду аудита на заявленном пороге критичности» — конкретный вызов должен быть в CLAUDE.md проекта, а не в общем файле фреймворка. Это не позволяет фреймворку кодировать npm-специфичные или cargo-специфичные команды, которые ломаются в других экосистемах.

Рецепты для инцидентов

Три рецепта описывают ситуации, которые при отсутствии предварительной подготовки превращаются в длительные сессии отладки. Рецепт очистки истории git описывает обязательный двухфлаговый вызов git filter-repo: один флаг для содержимого блобов, второй для сообщений коммитов. Без второго флага любой паттерн, упомянутый в сообщении коммита, описывающем саму очистку, остаётся в истории. Рецепт также определяет допустимые каналы резервного копирования и объясняет, почему тег в том же репозитории не является валидным бэкапом после перезаписи force-push.

Рецепт сосуществования Tailscale и VPN — пятишаговый чеклист для macOS. Самая частая ловушка: запуск Tailscale после коммерческого VPN. VPN захватывает первый доступный tunnel-интерфейс, и Tailscale тихо не может установить mesh-соединение. Рецепт также описывает флаг --accept-dns=false, который не позволяет двум демонам одновременно перезаписывать системный резолвер и провоцировать периодические NXDOMAIN-ошибки.

Эвристика «разведка против компрометации» отвечает на другой вопрос: 200-ответ на подозрительное имя файла не является доказательством взлома. Скил перечисляет четыре индикатора, отличающих фоновый сканерный шум от реальной компрометации: необычные base64-нагрузки, даты изменения файлов, не совпадающие с датой провизионирования, исходящие соединения от PHP-воркеров на неизвестные IP и нестандартные записи в cron или SSH-ключи.

Угрозная модель при смене корня запроса

Один рецепт выделяется по охвату. Когда задача меняет корень HTTP-запроса — переключает document root, точку монтирования контейнерного тома или цель симлинка — скил требует проверить каждого потребителя, разрешающего пути относительно этого корня, а не только конфигурацию, выполняющую переключение. Кеши выполнения, использующие путь как ключ, воспринимают два байтово-идентичных файла с разными inode как разные источники. Долгоживущий воркер, загрузивший один и тот же класс из обоих inode, упадёт с ошибкой «повторное объявление» во время запроса. Смягчение: сделать два корня одним inode-деревом на время переключения через симлинк, затем запланировать каноническое перемещение отдельным шагом.

Место в процессе

Скил security является компаньоном скила security-baseline, который содержит каноническое правило S1–S9. Совместная загрузка обоих покрывает планирование безопасности; загрузка только security покрывает расследование живого инцидента. Скил также поставляет два переиспользуемых шаблона планов: один — для задач по CVE зависимостей и обновлению версий фреймворка, второй — для атомарного переключения с авторолбэком при изменении конфигурации живого сервиса.

Читайте что такое Datarim для общего контекста или изучите скил self-verification, чтобы увидеть, как выводы о безопасности структурируются в слое верификации.