DevSecOps по приказу ФСТЭК №117: как автоматизировать безопасную разработку и при чём тут управление секретами
Приказ ФСТЭК №117 вступил в силу в марте 2026 года. Большинство компаний сосредоточились на требованиях к защите информационных систем в эксплуатации. Но в приказе есть блок который касается разработки.
Он называется «Требования к безопасности жизненного цикла программного обеспечения» — РБПО. И в нём есть конкретика по управлению секретами в пайплайнах.
Что требует ФСТЭК в части разработки
Из приказа №117 применительно к процессу разработки:
Статический анализ кода на уязвимости. Не раз в квартал, а при каждом изменении — как часть пайплайна.
Проверка сторонних зависимостей. Известные уязвимости в используемых библиотеках должны обнаруживаться автоматически.
Управление секретами. Пароли, API-ключи, токены, строки подключения к базам данных — всё это не должно попадать в репозиторий и не должно быть доступно всем членам команды.
Разграничение доступа к средам. Разработчик не должен иметь прямой доступ в production. Тестировщик не должен видеть production-секреты.
Журналирование действий. Кто, что и когда менял в системах разработки.
Последний пункт часто игнорируют. А зря — при проверке ФСТЭК вопрос о журнале действий в DevOps-инфраструктуре задаётся всё чаще.
Почему секреты в пайплайнах — главная проблема
Из всего что требует ФСТЭК, именно управление секретами вызывает больше всего нарушений на практике. Три причины.
Разработчики находят способы обойти ограничения когда они неудобны. Хардкод в коде, секрет в .env-файле в репозитории, пароль в комментарии — классика которая встречается в каждой второй команде.
Вайбкодинг сделало проблему хуже. Когда код генерирует ИИ-ассистент — в нём нередко появляются заглушки с реальными значениями которые разработчик забывает заменить перед коммитом.
HashiCorp Vault ушёл с российского рынка в 2023 году. Альтернативы требуют времени на внедрение. Многие команды до сих пор не выстроили замену.
Результат: секреты живут там где не должны. В репозитории, в переменных окружения платформы, в логах пайплайна.
Правильный паттерн: секреты через API в момент выполнения
Единственный способ который закрывает и требования ФСТЭК, и здравый смысл безопасности — получать секреты из внешнего хранилища через API в момент выполнения пайплайна.
Схема работает так. Пайплайн стартует и запрашивает временный JWT-токен у OpenID Connect провайдера. Этим токеном аутентифицируется в BearPass API. Получает нужный секрет в JSON-ответе. Использует его в текущей сессии. Секрет нигде не сохраняется.
Вот как это выглядит для GitLab CI:
deploy_production:
stage: deploy
script:
- |
TOKEN=$(curl -s -X POST "${BEARPASS_URL}/api/auth/oidc" \
-H "Content-Type: application/json" \
-d "{\"token\": \"${CI_JOB_JWT_V2}\"}" \
| jq -r '.access_token')
DB_PASS=$(curl -s \
-H "Authorization: Bearer ${TOKEN}" \
"${BEARPASS_URL}/api/items?search=Production+DB" \
| jq -r '.data[0].password')
DATABASE_URL="postgresql://app:${DB_PASS}@db/prod" ./deploy.sh
В репозитории нет ни одного реального секрета. Только адрес сервера BearPass. Токен GitLab CI OIDC действует только во время конкретного запуска. Журнал BearPass фиксирует каждый запрос.
Разграничение доступа: отдельный сервисный аккаунт для каждого пайплайна
Принцип минимальных привилегий должен распространяться и на автоматизацию.
У каждого пайплайна отдельный сервисный аккаунт в BearPass. Build-пайплайн видит только ключи для сборки. Deploy-пайплайн production видит только то что нужно для деплоя. Тестовый пайплайн работает только с тестовыми секретами.
Production-секреты недоступны из dev и staging пайплайнов. Это архитектурное ограничение, а не политика которую можно нарушить.
При компрометации сервисного аккаунта одного пайплайна — остальные не затронуты.
Метрики для ФСТЭК: что измерять
ФСТЭК при проверке смотрит не только на наличие мер, но и на измеримые результаты. Для управления секретами в разработке ключевая метрика одна: доля пайплайнов которые получают секреты через централизованное хранилище, а не из переменных окружения платформы.
Это считается просто. Посмотрите сколько у вас пайплайнов. Посмотрите сколько из них используют BearPass API. Остальные — потенциальное нарушение.
Второй показатель: наличие сканера секретов в пайплайне. TruffleHog, GitLeaks или встроенные проверки GitLab — что именно используется и сколько срабатываний было за последний квартал.
Чеклист DevSecOps по требованиям ФСТЭК №117
- Сканер секретов работает при каждом коммите — хардкодированные ключи блокируют слияние.
- Статический анализ кода встроен в пайплайн при каждом изменении.
- Зависимости проверяются на известные уязвимости при каждой сборке.
- Каждый пайплайн имеет отдельный сервисный аккаунт с минимальными правами.
- Секреты получаются через API хранилища, а не из переменных окружения платформы.
- Production-секреты недоступны из dev и staging пайплайнов.
- Все обращения к секретам журналируются с временными метками и идентификаторами пайплайна.
- Логи пайплайнов не содержат значений секретов — маскирование настроено.
Итог
Приказ ФСТЭК №117 добавил разработку в периметр регуляторных требований. Управление секретами в пайплайнах — один из ключевых пунктов который легко проверить и легко нарушить. Централизованное хранилище с API, отдельные сервисные аккаунты для пайплайнов и журнал запросов закрывают этот пункт технически и дают метрики для регулятора.