Как провести пилот SAST и SCA за 30 дней

Пилот SAST и SCA за 30 дней укладывается в четыре этапа: неделя на подготовку и установку, две недели на сканирование и разбор результатов, неделя на выводы и решение. Главное — заранее зафиксировать цели, набор репозиториев и измеримые критерии успеха, иначе вместо сравнения продуктов вы получите набор впечатлений.

Зачем нужен пилот и чем он отличается от демо

Демонстрация вендора показывает возможности продукта на подготовленном примере. Пилот (proof of concept) показывает, как продукт работает на вашем коде, в вашем конвейере и с вашими людьми. Он отвечает на вопросы, которые нельзя закрыть презентацией: сколько реальных уязвимостей будет найдено, сколько шума создаст инструмент, сколько времени займёт сканирование и согласятся ли разработчики с ним работать. Критерии выбора, из которых стоит исходить, описаны в статье «Как выбрать SAST-анализатор».

Неделя 0: подготовка до старта

Эта работа определяет успех всего пилота, поэтому сделайте её до установки продуктов.

• Сформулируйте цели. Например: выбрать SAST и SCA для всех команд; подтвердить работу в закрытом контуре; оценить влияние на время сборки.
• Назначьте роли. Владелец пилота со стороны ИБ, технический ответственный от DevOps, 2–3 разработчика-участника, представитель вендора или интегратора.
• Выберите репозитории. 3–5 проектов: разные языки и команды, один проект с известными уязвимостями из прошлых тестов на проникновение, один проект с большой историей зависимостей. Это даёт эталон для проверки пропусков.
• Согласуйте доступ. Учётные записи в Git, права на CI, сетевые правила, место для установки сервера сканирования. Задержки с доступами — самая частая причина срыва сроков.
• Определите метрики. См. раздел ниже.
• Решите вопрос с данными. Если код нельзя передавать наружу, запрашивайте только локальную установку и подтверждайте это письменно.

Неделя 1: установка и первый запуск

• Установите решения в тестовом контуре и замерьте трудозатраты: сколько часов и каких специалистов потребовалось. Это пойдёт в оценку стоимости владения.
• Подключите репозитории и выполните первое сканирование с настройками по умолчанию. Зафиксируйте количество находок и время сканирования.
• Для SCA проверьте, как продукт определяет зависимости: из манифестов, из сборки, транзитивные ли учитываются. Например, Sonatype Lifecycle поддерживает более 20 языков и форматов пакетов и генерирует SBOM, а OWASP Dependency-Track принимает SBOM в формате CycloneDX, поэтому уточните, в каком виде каждому продукту нужны входные данные. Подробнее о SBOM — «Что такое SBOM».

Недели 2–3: разбор результатов и интеграция в CI

• Триаж вместе с разработчиками. Возьмите случайную выборку находок (например, 50–100 на продукт) и отметьте каждую как истинную, ложную или «неактуальную». Разбирайте вслепую, не зная, какой продукт нашёл находку, если сравниваете нескольких кандидатов.
• Проверка пропусков. На проекте с известными уязвимостями проверьте, нашёл ли каждый инструмент то, что уже подтверждено пентестом.
• Интеграция в CI/CD. Подключите сканирование pull request в GitLab, GitHub или Jenkins. Измерьте время проверки и убедитесь, что инкрементальный режим работает; OWASP рекомендует запускать SAST именно на pull request.
• Политики SCA. Настройте правило, останавливающее сборку на критичных уязвимостях и запрещённых лицензиях, и посмотрите, сколько сборок оно остановило бы. Сначала включайте режим предупреждения, чтобы не парализовать работу команд.
• Защита от вредоносных пакетов. Если оцениваете такую функцию, проверьте её отдельно. У Sonatype это задача продукта Firewall, который блокирует вредоносные компоненты при загрузке и помещает подозрительные в карантин.
• Настройка. Попробуйте подавить ложные срабатывания, добавить собственное правило, назначить задачи в Jira. Оцените, насколько это просто для вашей команды.

Неделя 4: итоги и решение

• Соберите метрики в единую таблицу по каждому кандидату.
• Проведите ретроспективу с разработчиками: что мешало, что помогало, готовы ли они работать с этим инструментом каждый день.
• Запросите коммерческое предложение с расчётом на 3 года и добавьте стоимость инфраструктуры и сопровождения. Подход к расчёту — в статье «Open-source или коммерческие AppSec-инструменты».
• Подготовьте короткий отчёт для руководства: что проверяли, что выяснили, какое решение рекомендуете и какие риски остаются.

Какие метрики собирать

• Доля истинных срабатываний: истинные находки в выборке к её размеру.
• Охват известных уязвимостей: сколько из подтверждённых ранее дефектов найдено.
• Время сканирования: полного репозитория и pull request.
• Покрытие языков и зависимостей: все ли технологии стека проанализированы, нет ли «слепых зон».
• Трудозатраты на внедрение и сопровождение: в человеко-часах.
• Время на разбор одной находки: замерьте у разработчиков.
• Удобство для разработчика: короткий опрос участников после пилота.
• Работа в вашем контуре: подтверждена ли установка без выхода во внешнюю сеть, если это требование.

Заранее договоритесь о пороговых значениях, например «доля истинных срабатываний не ниже согласованной цифры» и «проверка pull request занимает не больше определённого времени». Конкретные значения зависят от вашей организации, универсальных нормативов не существует.

Типичные ошибки пилота

• Нет письменных критериев успеха. В итоге решает тот, кто убедительнее говорит.
• Пилот только на демо-проектах. Они не показывают реальный шум и сложность.
• Разработчиков не привлекли. Без них нельзя оценить истинные и ложные срабатывания.
• Слишком много кандидатов. Два-три продукта — предел, при котором можно качественно оценить каждый за 30 дней.
• Разные условия для кандидатов. Одинаковые репозитории, одинаковая глубина настройки, одинаковые сроки.
• Пилот без решения. Заранее определите, кто и когда принимает решение, иначе проект затянется.

Что дальше после пилота

После выбора продукта поэтапно расширяйте охват: сначала критичные приложения, затем остальные команды. Начните с режима «только предупреждения», затем вводите блокировку по критичным находкам. Для целостной картины рассмотрите карту DevSecOps: услуги по внедрению DevSecOps помогают встроить инструменты в процессы, а не просто установить их. Сравнение продуктов для пилота: SAST и SCA.

Шаблон отчёта по итогам пилота

Чтобы результаты пилота можно было показать руководству и использовать при закупке, оформите их в коротком документе из пяти разделов. Первый — цели и границы: какие репозитории и продукты участвовали и в каких условиях. Второй — таблица метрик по каждому кандидату. Третий — выводы разработчиков: что было удобно и что мешало. Четвёртый — оценка трудозатрат и стоимости владения на три года. Пятый — рекомендация и план внедрения с этапами и ответственными.

Приложите к отчёту примеры реальных находок: две-три подтверждённые уязвимости, которые обнаружил инструмент, и две-три типичные ложные. Такие примеры убеждают руководство лучше любых процентов, потому что показывают ценность и издержки на конкретных случаях из вашего кода.

Помните и об организационной стороне: заранее предупредите команды разработки, что в течение месяца в их конвейере появятся дополнительные проверки, и объясните, что результаты пилота не используются для оценки отдельных разработчиков. Без этого участники начинают скрывать проблемы или обходить сканирование, и вы получаете искажённую картину. Назначьте единый канал для вопросов по пилоту и еженедельную короткую встречу, на которой обсуждаются блокеры и промежуточные цифры.

Если пилот проводится в нескольких странах или в нескольких юридических лицах холдинга, определите единый набор метрик заранее: так результаты можно сравнивать между площадками и принимать общее решение о закупке и стандарте для всех команд.

Частые вопросы

Источники

• OWASP DevSecOps Guideline: Static Application Security Testing
• Sonatype Lifecycle: страница продукта
• Sonatype Firewall: страница продукта
• OWASP Dependency-Track
• Semgrep Docs: Semgrep Code overview