Небольшой команде DevSecOps начинают с трёх автоматических проверок в сборке: поиск секретов в репозитории, проверка зависимостей на известные уязвимости и проверка образов контейнеров. Подключают их сначала в режиме «показывать, но не блокировать», разбирают первые результаты и только потом переводят в блокировку для самых серьёзных находок. Всё остальное, от проверки кода правилами до динамических тестов, добавляется позже.
Причина такого порядка проста. Эти три проверки дают меньше всего ложных срабатываний и закрывают ошибки, которые действительно приводят к инцидентам: ключ в открытом репозитории и библиотека с известной дырой. Услуга описана на странице «Внедрение DevSecOps», а здесь разбираем, как сделать первые шаги самому и где не споткнуться.
Три проверки, с которых начинаем
Вместо длинного списка инструментов начнём с вопросов: какие ошибки чаще всего приводят к реальным последствиям и какие из них можно найти автоматически без шума. Ответ даёт таблица.
| Проверка | Что находит | Примеры инструментов | Почему в начале |
|---|---|---|---|
| Поиск секретов | Пароли, ключи доступа и токены в коде и в истории репозитория | Gitleaks, TruffleHog | Мало ложных срабатываний, последствия ключа в репозитории тяжёлые, исправление очевидно |
| Проверка зависимостей | Библиотеки, для которых известны уязвимости | OSV-Scanner, OWASP Dependency-Check, Trivy | Большая часть кода приложения — чужие библиотеки; отчёт сразу показывает объём работы |
| Проверка образов | Устаревшие базовые образы, лишние пакеты, запуск от администратора | Trivy, Grype, hadolint для файла сборки | Одна строка в описании сборки, результат понятен без знания приложения |
Все перечисленные инструменты открытые и работают на вашем сервере сборки. Какой выбрать, зависит от языка и привычек команды, на результат это влияет меньше, чем кажется: важнее, чтобы проверка запускалась в каждой сборке и чтобы кто-то читал её отчёт.
Что не входит в первую тройку, видно из названий: проверка исходного кода правилами, динамическое тестирование стенда, проверка описания инфраструктуры. Они полезны, но дают больше шума и требуют настройки под ваш код. Они дополняют первую тройку, а не заменяют её, и подключать их стоит, когда команда уже привыкла разбирать отчёты.
Как подключить проверки и не остановить релизы
Самая частая причина, почему DevSecOps умирает через месяц: проверку включили сразу в режиме блокировки, она нашла сотню старых замечаний, релиз встал, и разработчики её отключили. Чтобы так не случилось, у каждой проверки три режима, и переход между ними осознанный.
| Режим | Что происходит при находке | Сколько держим | Условие перехода дальше |
|---|---|---|---|
| Только информирует | Сборка проходит, отчёт сохраняется, находки видны в запросе на слияние | Одна-две недели | Первый отчёт разобран: ложные срабатывания помечены, реальные заведены в задачи |
| Предупреждает о новом | Сборка проходит, но новая находка в изменённом коде отмечается красным комментарием | Один-два месяца | Разработчики привыкли исправлять новое, старые замечания не растут |
| Блокирует серьёзное | Сборка останавливается при новой серьёзной находке; для остальных остаётся предупреждение | Постоянно | Есть процедура исключения: владелец, причина, срок |
Ключевая мысль: блокируем только то, что появилось в новом коде, а накопленный долг разбираем отдельно, по плану. Иначе в первый день придётся чинить годы накопленного, и никто не захочет включать проверку второй раз.
Что делать с шумом: ложные срабатывания и исключения
Любой сканер ошибается. Часть находок относится к коду, который не запускается, часть к библиотеке, чья уязвимая функция не вызывается, часть сообщает о тестовом ключе. Если шум не разбирать, команда научится не смотреть в отчёт, и тогда проверка хуже, чем её отсутствие: создаётся ощущение безопасности.
Как разбирать первый отчёт
- Отсортируйте по серьёзности и по тому, достижима ли уязвимость. Библиотека с дырой в функции, которую вы не вызываете, ниже по приоритету, чем ключ в репозитории.
- Каждую находку отнесите к одной из трёх групп: исправляем, исключаем с причиной, откладываем со сроком.
- Исключения записывайте в файл в репозитории, а не в интерфейсе сканера: так их видно в ревью и они не пропадают при смене инструмента.
- У каждого исключения три поля: кто принял решение, почему, до какого числа. Без срока исключение превращается в вечное.
- Раз в месяц пересматривайте исключения с истёкшим сроком. Это пять минут, и они защищают от накопления.
Ключ, найденный в истории репозитория, нельзя просто удалить из текущей версии: его надо считать скомпрометированным, отозвать и выпустить новый. Это единственная находка, где исключение почти никогда не уместно.
Кто читает результаты и как заводятся задачи
Без владельца проверка превращается в красную лампочку, на которую никто не смотрит. В небольшой команде работает простая схема.
- Один ответственный за безопасность в команде. Не отдельная должность, а роль на ротации: раз в спринт или раз в месяц. Он смотрит отчёты, заводит задачи, пересматривает исключения.
- Находки сразу попадают туда, где команда уже работает. В тикеты, в запрос на слияние, в чат команды, но не в отдельную панель, которую никто не открывает.
- У каждой задачи по безопасности есть срок, зависящий от серьёзности. Срок записывается один раз в правилах команды: например, критические устраняются до следующего релиза, остальные — в плановом порядке.
- Исправление проверяется той же проверкой. Задача закрыта, когда сборка перестала показывать эту находку.
Если команда мала, а подрядчики пишут часть кода, отчёт сборки включается в приёмку: подрядчик отдаёт релиз вместе с результатом проверок, а вы решаете, что с ними делать. Общий порядок такой приёмки описан в статье «Как встроить безопасность в разработку».
Закрытый контур: что меняется, если сборка не выходит в интернет
Инструменты проверки зависимостей и образов обычно берут свежие базы уязвимостей из внешних источников. Если ваш сервер сборки изолирован, эту часть придётся организовать иначе.
| Вопрос | Как решается в закрытом контуре |
|---|---|
| Откуда берутся базы уязвимостей | Зеркало баз внутри контура, которое обновляется по расписанию через разрешённый канал; в отчёте видна дата базы |
| Откуда берутся сами библиотеки | Внутренний прокси-репозиторий пакетов; проверка идёт по тем версиям, которые действительно скачиваются |
| Куда уходит код | Никуда: проверки работают на вашем сервере сборки, внешние облачные сканеры не используются |
| Как обновляются сами инструменты | Вместе с образами раннеров, по плановому окну, с проверкой на тестовом конвейере |
Для данных ограниченного доступа внешние сервисы проверки кода чаще всего не подходят по требованиям заказчика, и это ещё один довод в пользу открытых инструментов на своём оборудовании. Если сборка идёт на сервере GitLab или Jenkins внутри вашей сети, ничего дополнительно покупать не нужно.
Чего не вводить в первый месяц
Хочется сразу сделать «как в больших компаниях». Для небольшой команды это почти всегда вредит. Три вещи, которые лучше отложить:
- Проверка исходного кода правилами по полному набору. Она найдёт сотни замечаний разной важности. Включайте небольшой набор правил по классам, которые вам действительно знакомы: склейка запросов, опасные функции, жёстко заданные ключи.
- Динамическое тестирование на стенде. Оно требует стабильного стенда, учётных записей и настроенных сценариев. Без этого оно либо молчит, либо шумит.
- Единый портал управления уязвимостями. Пока находок немного, хватает тикетов и таблицы. Портал нужен, когда репозиториев много и нужен общий взгляд.
Ещё одна ловушка: сделать проверки обязательными для всех репозиториев одним приказом. Лучше начать с одного-двух продуктов, где команда готова разбираться, отладить процесс и потом тиражировать готовые настройки.
Как понять, что DevSecOps работает
Хорошие показатели не обязаны быть сложными, а цифры вы получите сами, из своего конвейера. Ниже вопросы, ответы на которые лучше смотреть раз в месяц.
| Вопрос | Хороший признак | Тревожный признак |
|---|---|---|
| Проверки запускаются в каждой сборке? | Да, на всех активных репозиториях | Часть репозиториев обходит проверки или запускает вручную |
| Сколько времени проходит от находки до исправления? | Критические находки закрываются быстрее срока из правил | Находки висят месяцами без владельца |
| Что с исключениями? | У каждого есть владелец, причина и срок | Исключений много, срок не указан или давно истёк |
| Как команда относится к отчёту? | Находки обсуждаются в ревью | Отчёт сразу закрывают, не читая |
| Растёт ли число старых замечаний? | Нет или медленно сокращается | Растёт: новый код приносит новые замечания |
Если по двум-трём строкам таблицы видны тревожные признаки, проблема, как правило, не в инструментах, а в процессе: нет владельца, нет срока, нет привычки смотреть результат.
Что делаем мы и с чего начать
Начинаем с обследования конвейера: 200 000 ₽ и 2–3 недели для одного-двух репозиториев и одной системы сборки, 350 000 ₽ и 3–4 недели, если систем и команд несколько. Смотрим, на чём вы собираете и выкладываете, где лежат секреты, как обновляются зависимости, и что можно подключить без остановки релизов. На выходе схема конвейера с точками проверок, порядок подключения, правила для находок и вилка бюджета. Обследование вычитается из первого этапа, если продолжаете с нами.
Дальше пилот: подключаем первые проверки на одном-двух продуктах, разбираем первый отчёт вместе с вашими разработчиками, настраиваем режимы и исключения. Пилот стоит от 150 000 до 400 000 ₽ и занимает 2–8 недель. Настройки лежат в вашем репозитории, инструменты работают на вашем сервере сборки. Мы не поставляем сканеры как услугу, не принимаем результаты на дежурстве и не заменяем отдел безопасности. Все цены — на странице «Тарифы», описание услуги — на странице «Внедрение DevSecOps».
Частые вопросы
С чего начать внедрение DevSecOps?
С трёх проверок в сборке: поиск секретов, проверка зависимостей и проверка образов. Они дают мало ложных срабатываний и закрывают ошибки, которые чаще всего приводят к реальным последствиям. Сначала включаем их в режиме «только показывать», через пару недель переводим серьёзные находки в блокировку.
Что дороже: инструменты или внедрение?
Основные инструменты открытые, поэтому большая часть затрат уходит на настройку, разбор первого отчёта и привычки команды, а не на лицензии. Суммы по инструментам не называем: они зависят от выбора и от вашей инфраструктуры.
Не замедлят ли проверки сборку?
Могут, если подключены без разбора. Поиск секретов и проверка зависимостей обычно занимают немного времени по сравнению с самой сборкой, а тяжёлые проверки выносятся в отдельную стадию или в ночной запуск. Время каждой стадии смотрим на обследовании и укладываем в приемлемый для вашей команды срок.
Что делать с ложными срабатываниями?
Разбирать первый отчёт вручную и записывать исключения в файл в репозитории с причиной, владельцем и сроком. Так шум не накапливается, а решения видны в ревью. Исключения с истёкшим сроком пересматриваются раз в месяц.
Как быть, если сканер нашёл ключ в истории репозитория?
Считать ключ скомпрометированным: отозвать, выпустить новый и обновить настройки там, где он использовался. Удаление из текущей версии кода недостаточно, потому что ключ остаётся в истории. После этого стоит подключить поиск секретов перед коммитом и в каждой сборке.
Подходит ли это, если у нас нет контейнеров?
Да. Поиск секретов и проверка зависимостей работают с любым кодом. Проверка образов добавляется, когда вы переходите на контейнеры. Если выкладка идёт скриптами на серверы, проверяется ещё и конфигурация серверов.
Можно ли внедрить DevSecOps в закрытом контуре?
Да. Инструменты работают на вашем сервере сборки, базы уязвимостей зеркалируются внутрь контура по расписанию, а код никуда не передаётся. Внешние облачные сканеры для данных ограниченного доступа чаще всего не подходят по требованиям заказчика.
Сколько стоит внедрение DevSecOps?
Обследование конвейера стоит 200 000 ₽ за один-два репозитория и 350 000 ₽ за несколько систем, оно вычитается из первого этапа. Пилот на первых проверках — 150 000–400 000 ₽ за 2–8 недель. Дальнейшие этапы называются после пилота.