Блог BearPass

DevSecOps по ФСТЭК №117: безопасная разработка и секреты

DevSecOps по приказу ФСТЭК №117: как автоматизировать безопасную разработку и при чём тут управление секретами

Приказ ФСТЭК №117 вступил в силу в марте 2026 года. Большинство компаний сосредоточились на требованиях к защите информационных систем в эксплуатации. Но в приказе есть блок который касается разработки.
Он называется «Требования к безопасности жизненного цикла программного обеспечения» — РБПО. И в нём есть конкретика по управлению секретами в пайплайнах.

Что требует ФСТЭК в части разработки

Из приказа №117 применительно к процессу разработки:
Статический анализ кода на уязвимости. Не раз в квартал, а при каждом изменении — как часть пайплайна.
Проверка сторонних зависимостей. Известные уязвимости в используемых библиотеках должны обнаруживаться автоматически.
Управление секретами. Пароли, API-ключи, токены, строки подключения к базам данных — всё это не должно попадать в репозиторий и не должно быть доступно всем членам команды.
Разграничение доступа к средам. Разработчик не должен иметь прямой доступ в production. Тестировщик не должен видеть production-секреты.
Журналирование действий. Кто, что и когда менял в системах разработки.
Последний пункт часто игнорируют. А зря — при проверке ФСТЭК вопрос о журнале действий в DevOps-инфраструктуре задаётся всё чаще.

Ваши пайплайны берут секреты из переменных окружения CI/CD платформы?

BearPass REST API позволяет получать секреты в пайплайне через JWT-токен в момент выполнения. Ничего не хранится в репозитории. Журнал фиксирует каждый запрос. До 5 пользователей бесплатно навсегда.

Попробовать бесплатно

Почему секреты в пайплайнах — главная проблема

Из всего что требует ФСТЭК, именно управление секретами вызывает больше всего нарушений на практике. Три причины.
Разработчики находят способы обойти ограничения когда они неудобны. Хардкод в коде, секрет в .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 — что именно используется и сколько срабатываний было за последний квартал.

BearPass для DevOps

Секреты в пайплайне без хранения в репозитории. По требованиям ФСТЭК №117.

REST API · JWT OIDC · Журнал запросов · RBAC по пайплайнам
On-premise · Реестр РФ №15427 · Шифрование ГОСТ

Попробовать бесплатно — до 5 пользователей навсегда

Чеклист DevSecOps по требованиям ФСТЭК №117

  • Сканер секретов работает при каждом коммите — хардкодированные ключи блокируют слияние.
  • Статический анализ кода встроен в пайплайн при каждом изменении.
  • Зависимости проверяются на известные уязвимости при каждой сборке.
  • Каждый пайплайн имеет отдельный сервисный аккаунт с минимальными правами.
  • Секреты получаются через API хранилища, а не из переменных окружения платформы.
  • Production-секреты недоступны из dev и staging пайплайнов.
  • Все обращения к секретам журналируются с временными метками и идентификаторами пайплайна.
  • Логи пайплайнов не содержат значений секретов — маскирование настроено.

Итог

Приказ ФСТЭК №117 добавил разработку в периметр регуляторных требований. Управление секретами в пайплайнах — один из ключевых пунктов который легко проверить и легко нарушить. Централизованное хранилище с API, отдельные сервисные аккаунты для пайплайнов и журнал запросов закрывают этот пункт технически и дают метрики для регулятора.

BearPass — корпоративный менеджер паролей

Секреты в CI/CD через API. Без хранения в репозитории. On-premise.

REST API · JWT через OpenID Connect · CLI · Журнал запросов · RBAC
On-premise · Реестр РФ №15427 · Шифрование ГОСТ

Попробовать бесплатно — до 5 пользователей навсегда

Документация по API: docs.bearpass.ru · Поддержка: @BearHelper_bot

2026-06-24 21:34 Экспертиза