Dimax GroupЦентр AI-трансформации
Разобрать задачу

SAST-анализ кода, DAST-тестирование и SCA-анализ зависимостей: настройка в вашей сборке

SAST читает ваш код, SCA сверяет библиотеки с базой известных уязвимостей, DAST проверяет запущенное приложение снаружи. Каждый видит своё, поэтому ценность даёт не сканер, а настроенный конвейер: что запускается на каждом изменении, что блокирует выпуск, кто разбирает находки. Настраиваем его в вашей сборке и в закрытом контуре.

Разобрать задачу Как идёт работа

Пилот на одном-трёх репозиториях — от 150 000 ₽Сканеры ставятся у вас, исходники никуда не выгружаютсяDAST только на вашем тестовом стенде, боевую систему не атакуем

С чем приходят

Когда нужны автоматические проверки кода и зависимостей

Сканер есть, отчёт никто не читает

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

Клиент прислал опросник по безопасности разработки

Спрашивают, проверяете ли вы код и библиотеки автоматически. Ответ «иногда вручную» не убеждает: нужен процесс со следом в журнале сборки.

Команда выросла, ревью не успевает

Рецензент смотрит логику и не замечает, что в зависимость пришла известная уязвимость или в коммит попал ключ. Рутинные проверки лучше отдать машине, а человека оставить для логики.

Код нельзя отправлять в чужой сервис

Облачные сканеры просят загрузить исходники. Для закрытых проектов это чаще всего не подходит по требованиям заказчика, поэтому инструменты ставятся в вашем контуре.

Что чем проверяется

SAST, SCA, DAST и соседние проверки: что смотрит каждая

Выбор по ситуации и порядок подключения — в статье «SAST, DAST, SCA: в чём разница».

Проверка
Что анализирует
Что находит
Чего не видит
ПроверкаSASTстатический анализ
Что анализируетИсходный код без запуска: путь данных от ввода пользователя к опасным местам
Что находитСклейку строк в запросе, небезопасное чтение файла, слабое хеширование, типовые пропуски проверки прав
Чего не видитОшибки логики вроде «можно оформить заказ за чужую организацию» и всё, что зависит от настроек на стенде
ПроверкаSCAанализ состава
Что анализируетСписок библиотек и их версий по файлам блокировки и образам
Что находитЗависимости с известными уязвимостями, неподходящие лицензии, заброшенные пакеты
Чего не видитУязвимости в вашем собственном коде; не отличает библиотеку, чья опасная функция не вызывается
ПроверкаDASTдинамический анализ
Что анализируетЗапущенное приложение снаружи: запросы, ответы, заголовки, сессии
Что находитОтсутствие защитных заголовков, отражённый ввод, открытые служебные адреса, слабые настройки сессий
Чего не видитСтраницы за входом без настроенной учётной записи, длинные цепочки шагов, код, до которого сканер не дошёл
ПроверкаПоиск секретовистория репозитория
Что анализируетВсе коммиты, включая старые и удалённые из текущей ветки
Что находитКлючи, пароли и токены в коде и конфигурациях
Чего не видитСекреты вне репозитория; найденный ключ всё равно придётся перевыпускать
ПроверкаКонтейнеры и конфигурацияобразы и описание развёртывания
Что анализируетФайлы сборки образов, сами образы, манифесты развёртывания
Что находитЗапуск от имени администратора, лишние открытые порты, устаревший базовый образ
Чего не видитЧто происходит внутри самого приложения
Условный пример

Что находит каждый инструмент на трёх условных ошибках

Примеры условные, на них видно, почему ни одна проверка не заменяет остальные.

Поиск по каталогу собирает запрос склейкой строк

SAST видит путь от поля поиска до запроса к базе и показывает строку кода. DAST находит ошибку, только если сканер дошёл до этой формы и по ответу понял, что запрос ломается. SCA здесь бессилен: ошибка в вашем коде, а не в библиотеке.

Библиотека разбора документов с известной уязвимостью

SCA сопоставляет версию с базой и сообщает о находке и о том, в какой версии она исправлена. SAST её не заметит, потому что дефект сидит внутри чужого кода. DAST увидит последствия, только если уязвимость проявляется в ответах приложения.

Пользователь меняет номер заказа в адресе и видит чужой заказ

Надёжно найти такую ошибку не сможет ни один из трёх классов: сканер не знает, чей заказ чей. Здесь нужен человек и прогон по матрице «роль — объект — действие», это уже ревью кода на безопасность или аудит безопасности веб-приложения.

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

Конвейер

Куда встроить проверки: коммит, запрос на слияние, сборка, стенд

Заготовка для разбора: на вашей платформе сборки строки будут другими, вопрос «где блокируем» остаётся тем же.

Точка
Что запускаем
Блокирует ли выпуск
Почему так
ТочкаПеред коммитомна машине разработчика
Что запускаемПоиск секретов и быстрые правила SAST
Блокирует ли выпускНет, только предупреждает
Почему такЛокальную проверку можно обойти, настоящая преграда стоит на сервере; зато секрет не попадает в историю
ТочкаЗапрос на слияниепроверка изменений
Что запускаемSAST по изменённым файлам, SCA по файлам блокировки, поиск секретов
Блокирует ли выпускДа, но только для новых находок высокой серьёзности
Почему такБлокируем то, что внесено этим изменением; накопленное не заставляем исправлять в одном запросе
ТочкаСборка образапосле сборки
Что запускаемПроверка образа и перечень состава (SBOM) для выпуска
Блокирует ли выпускДа, если найдена критичная уязвимость, для которой есть исправление
Почему такОбраз — то, что уйдёт в эксплуатацию; состав каждого выпуска фиксируется
ТочкаТестовый стендпосле выкладки
Что запускаемDAST: базовое сканирование, затем сценарии со входом
Блокирует ли выпускНет, результат идёт на разбор
Почему такЛожных срабатываний здесь больше, блокировка по ним быстро раздражает команду
ТочкаНочной полный прогонпо расписанию
Что запускаемПолный SAST, SCA с обновлённой базой уязвимостей
Блокирует ли выпускНет, создаёт задачи
Почему такНовая уязвимость в библиотеке появляется, пока ваш код не менялся
ТочкаПеред выпускомрешение человека
Что запускаемСводка открытых находок
Блокирует ли выпускРешает ответственный за выпуск
Почему такВыпуск с принятым риском допустим, но запись о нём остаётся
Шум

Как не утонуть в срабатываниях

Главный риск автоматических проверок не в пропущенной уязвимости, а в том, что результат перестают читать.

Фиксируем базовую линию

На живом проекте первый запуск даёт много находок. Закрыть их разом нельзя: состояние записывается как базовая линия, блокируются только новые находки, накопленное разбирается по плану.

Серьёзность и достижимость

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

Подавление только с причиной и сроком

Скрыть находку можно, но запись содержит причину, автора и дату пересмотра.

Статусы находок

Что можно решить по каждой находке и кто это решает

Решение
Что значит
Кто решает
Когда пересматриваем
РешениеИсправитьправка кода или обновление библиотеки
Что значитНаходка подтверждена и достижима
Кто решаетВладелец модуля, срок по серьёзности
Когда пересматриваемЗакрывается после повторной проверки
РешениеЛожное срабатываниеошибки нет
Что значитСканер не учёл проверку, которая есть выше по коду
Кто решаетРазработчик, второй взгляд у ответственного за безопасность
Когда пересматриваемПри смене правила или крупном изменении модуля
РешениеНедостижимодефект есть, добраться нельзя
Что значитУязвимая функция не вызывается или код закрыт от внешнего ввода
Кто решаетОтветственный за безопасность
Когда пересматриваемПри каждом обновлении зависимости и изменении точек входа
РешениеПринять рискисправлять не будем
Что значитИсправление нецелесообразно сейчас, есть компенсирующая мера
Кто решаетВладелец продукта письменно
Когда пересматриваемЧерез заранее названный срок
Закрытый контур

Как это устроено, когда код нельзя выносить наружу

Сканеры работают у вас

Инструменты ставятся на ваши серверы или в ваш сервер сборки. Исходники, отчёты и перечни состава остаются внутри периметра и не отправляются в облачные сервисы.

Базы уязвимостей обновляются по регламенту

SCA бесполезен, если его база устарела. В закрытом контуре держим зеркало баз, порядок и частоту обновления записываем, а отчёт предупреждает, если обновление давно не проходило.

Правила под ваш код

Типовые правила не знают ваших обёрток над запросами к базе или собственной проверки прав. Дописываем правила под ваш каркас, чтобы сканер ловил отклонения именно от ваших соглашений.

Что делаем

Из чего состоит работа и сколько она стоит

Цены — по тарифам. Работы дешевле 150 000 ₽ не берём; остановиться можно после любой ступени, сделанное остаётся у вас по акту.

Обследование: стек, сборка и текущие проверки

Языки и репозитории, платформа сборки, что уже запускается, пробный прогон на выборке вашего кода для оценки шума. На выходе схема конвейера проверок, выбор инструментов с причинами, пороги блокировки и вилка бюджета. Вычитается из первого этапа, если продолжаете с нами.

200 000 ₽ · 2–3 недели

Обследование: несколько платформ сборки или много команд

То же для нескольких репозиториев в разных системах сборки и с разными владельцами. Добавляется карта владельцев и единые правила обработки находок.

350 000 ₽ · 3–4 недели

Пилот лёгкий: проверки на одном-трёх репозиториях

SAST, SCA и поиск секретов в запросах на слияние, DAST на тестовом стенде, разбор накопленных находок с базовой линией, инструкция для разработчиков.

150 000–400 000 ₽ · 2–8 недель

Пилот тяжёлый: много репозиториев, сценарии DAST со входом

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

400 000–1 200 000 ₽ · 2–3 месяца

Сопровождение

Обновление правил и баз, настройка порогов, разбор спорных находок вместе с командой. Плановые доработки конвейера входят с пакета на 60 000 ₽. Сверх пакета — 5 000 ₽ в час.

20 000 / 60 000 / 120 000 ₽ в месяц
Процесс

Как идёт работа

2–4 недели — Обследование

Смотрим репозитории и сборку, запускаем пробный прогон на выборке кода, оцениваем шум. Фиксируем, что блокирует выпуск, а что только создаёт задачи.

1–2 недели — Подключение на одном репозитории

Ставим инструменты в вашем контуре, настраиваем запрос на слияние и ночной прогон. Выбираем репозиторий, где команда готова принять процесс.

1–2 недели — Базовая линия и разбор

Фиксируем накопленные находки, вместе с командой разбираем самые серьёзные, остальные получают статус и срок.

2–4 недели — DAST на стенде

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

Дальше — Расширение и сопровождение

Повторяем настройку на остальных репозиториях по шаблону, затем обновляем правила и базы по пакету часов из договора.

Цена

Что двигает цену внутри вилки

Число репозиториев и языков

Каждый язык и каркас требуют своих правил. Пять сервисов на одном языке дешевле двух на разных.

Состояние кода

В старом коде без тестов находок много, и разбор занимает больше времени, чем настройка сканера.

Платформа сборки

Если автоматической сборки нет, сначала приходится делать её. Встроенные проверки платформы зависят от её редакции, это выясняем на обследовании.

Глубина DAST

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

Контроль

Что остаётся у вас и чего мы не делаем

Остаётся у вас

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

Мы этого не делаем

  • Не атакуем боевые системы: DAST идёт на вашем тестовом стенде и с вашего согласия.
  • Не проводим пентест, аттестацию и не оказываем WAF, SIEM или IDS как услугу; лицензии ФСТЭК у нас нет.
  • Не обещаем отсутствие уязвимостей: пустой отчёт означает, что сканер не нашёл типовых ошибок.
  • Не продаём лицензии коммерческих сканеров; работаем с открытыми инструментами или с вашими лицензиями.
  • Не берём работы дешевле 150 000 ₽ и не дежурим круглосуточно.
Граница

Автоматические проверки, ревью кода и аудит: где проходит граница

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

Безопасность во всём жизненном цикле разработки — это безопасная разработка, проверки отсюда — её часть. Сборку целиком описывает страница «DevSecOps: внедрение», угрозы до кода — моделирование угроз.

Порядок обычно такой: секреты и зависимости (дешевле и чаще всего), затем SAST на новых изменениях, затем DAST на стенде.

Инструменты

На чём собираем

Анализ кода, зависимостей и секретов
  • Semgrep и SonarQube Community для SAST; Bandit, gosec и ESLint-плагины для отдельных языков
  • Trivy, OSV-Scanner и OWASP Dependency-Check для SCA
  • Syft и форматы CycloneDX или SPDX для перечня состава; Dependency-Track для хранения
  • Gitleaks для поиска секретов в истории
Динамические проверки и сборка
  • OWASP ZAP и Nuclei для DAST на тестовом стенде
  • GitLab CI, Jenkins или GitHub Actions: проверки подключаются к тому, что у вас уже есть
  • Docker и проверка образов перед выкладкой
  • Ваш трекер задач для находок; отчёты остаются в вашем контуре
Материалы

Материалы по теме

Статья

SAST, DAST, SCA: в чём разница и что нужно вам

Какой вопрос задаёт каждая проверка, что она не видит и в каком порядке подключать их небольшой команде.

  • Вопрос каждой проверки
  • Выбор по ситуации
  • Как читать отчёт
Читать →
Статья

OWASP Top 10 простыми словами для заказчика

Десять классов ошибок без жаргона и вопросы подрядчику. Пригодится, чтобы понимать, что именно ищет сканер.

  • Десять категорий
  • Что находит автоматика
  • Как читать отчёт
Читать →
Статья

DevSecOps: с чего начать небольшой команде

Порядок подключения проверок в конвейер без остановки разработки.

  • Первые шаги
  • Пороги блокировки
  • Кто разбирает находки
Читать →
Заявка

Разберём, какие проверки нужны вашему проекту

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

Спасибо, заявка отправлена. Ответим в течение рабочего дня.

Не удалось отправить. Напишите в телеграм или позвоните.

Вопросы

Частые вопросы: SAST, DAST и SCA

Чем SAST отличается от DAST и SCA?

SAST читает исходный код без запуска, DAST проверяет запущенное приложение снаружи, SCA сверяет сторонние библиотеки с базой известных уязвимостей. Первый ищет ошибки в вашем коде, второй проблемы в работающей системе, третий уязвимости чужого кода в вашем проекте. Ни один не заменяет остальные.

Сколько стоит настройка SAST, DAST и SCA?

Обследование стоит 200 000 ₽ за 2–3 недели (350 000 ₽ при нескольких платформах сборки), оно вычитается из первого этапа. Пилот на одном-трёх репозиториях — 150 000–400 000 ₽ за 2–8 недель, большой проект с несколькими языками и DAST со входом — 400 000–1 200 000 ₽ за 2–3 месяца. Сопровождение — 20 000, 60 000 или 120 000 ₽ в месяц.

Нужны ли все три проверки сразу?

Нет. Обычно начинают с поиска секретов и SCA, затем подключают SAST на новых изменениях, DAST добавляют последним. Если команда небольшая, трёх потоков находок она не переварит. Порядок определяем на обследовании.

Можно ли запускать DAST на рабочей системе?

Мы запускаем его только на тестовом стенде и с вашего согласия. Сканер отправляет вредоносные на вид запросы, может создавать записи и перегружать сервис. Боевую систему мы не атакуем.

Что делать с большим списком находок после первого запуска?

Записать состояние как базовую линию и блокировать только новые находки высокой серьёзности. Накопленное разбираем по плану: сначала достижимое и серьёзное, остальным присваиваем статус и срок.

Работает ли это в закрытом контуре без выхода в интернет?

Да. Сканеры ставятся у вас, базы уязвимостей зеркалируются и обновляются по регламенту, отчёты остаются внутри.

Заменяет ли автоматическая проверка аудит или ревью кода?

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

На каких платформах сборки это работает?

На GitLab CI, Jenkins и GitHub Actions: проверки подключаются к тому, что у вас уже есть. Если автоматической сборки нет, начнём с неё, иначе проверки некуда встраивать.

Кому принадлежат настройки и правила?

Вам. Конфигурации, правила и описание конвейера лежат в вашем репозитории с первого коммита. Порядок передачи прав записывается в договоре.

Вы работаете только в Ростове-на-Дону?

Мы в Ростове-на-Дону, работаем с заказчиками по всей России: удалённо и в вашем контуре. Доступ к системам и обследование согласуем на старте с вашей службой безопасности.

Смежное

Что посмотреть рядом