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

Безопасная разработка веб-приложений: Secure SDLC для вашей команды и ваших подрядчиков

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

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

Обследование процесса — 200 000 ₽, вычитается из первого этапаТребования записываются так, чтобы их можно было проверить при приёмкеПравила, шаблоны и настройки лежат в вашем репозитории

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

Когда безопасность нужно встраивать в процесс, а не проверять в конце

Безопасностью занимаются перед релизом

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

Подрядчики пишут код, а требований нет

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

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

В опросниках по безопасности просят описать, как у вас устроены ревью, проверки зависимостей и реагирование на уязвимости. Ответ «разработчики внимательные» не принимается.

Аудит находит то же самое, что в прошлый раз

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

Этапы

Шесть этапов Secure SDLC: что делаем и что остаётся на выходе

Ниже заготовка для обследования: на ваших системах строки будут другими, этапы те же. Для каждого этапа есть минимальное действие, которое вводится без остановки работы. Подробнее о каждом этапе — в статье «Как встроить безопасность в разработку».

Этап
Что делаем
Что остаётся на выходе
Кто отвечает
ЭтапТребованиядо разработки
Что делаемДля каждой задачи с данными пользователей записываем, кто что видит и меняет, что пишется в журнал; формулируем проверяемо
Что остаётся на выходеСтроки в критериях приёмки, библиотека требований
Кто отвечаетВладелец продукта и аналитик, консультирует исполнитель
ЭтапПроектированиеновые модули
Что делаемРазбор потоков данных и границ доверия, вопросы «кто может подделать запрос» и «что будет при утечке хранилища»
Что остаётся на выходеСхема потоков и три-пять решений в репозитории
Кто отвечаетАрхитектор и ведущий разработчик
ЭтапРазработкаежедневная работа
Что делаемКороткие правила для ввода, прав, секретов и журнала; общие модули, в которых правильный путь самый короткий
Что остаётся на выходеПравила рядом с кодом, общие функции
Кто отвечаетРазработчики
ЭтапРевьюкаждый запрос на слияние
Что делаемТри вопроса про права, ввод и секреты; отдельное чтение рискованных мест вдвоём
Что остаётся на выходеСписок для ревью, комментарии в запросах
Кто отвечаетРевьюеры команды
ЭтапСборка и приёмкакаждый релиз
Что делаемАвтоматические проверки секретов и зависимостей; прогон прав из-под каждой роли на стенде
Что остаётся на выходеОтчёт сборки, запись о приёмке
Кто отвечаетТестировщик и ответственный за безопасность
ЭтапЭксплуатацияпосле запуска
Что делаемЖурнал действий, плановое обновление зависимостей, ответственный за инциденты, разбор причин
Что остаётся на выходеЖурнал, график обновлений, записи разборов
Кто отвечаетКоманда сопровождения
Пример

Как одна задача проходит через процесс: условный пример

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

Требования

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

Проектирование

На разборе задачи рисуется поток: браузер, веб-приложение, хранилище файлов, база. Задаются вопросы. Кто может подменить идентификатор файла в адресе? Что будет, если загрузить исполняемый файл с безобидным расширением? Что увидит поддержка при просмотре чужого файла? Решения записываются: проверка принадлежности на сервере при каждом скачивании, файлы лежат отдельно от кода и не исполняются, поддержка получает доступ только через журналируемую процедуру.

Ревью и сборка

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

Приёмка

Тестировщик загружает файл от имени организации A и пробует открыть его по прямой ссылке от имени организации B, перебирая идентификаторы. Загружает файл запрещённого типа и слишком большой. Проверяет, что в журнале есть все действия. Задача закрыта, когда эти проверки пройдены, а не когда код слит в основную ветку.

Ошибки

Классы ошибок: на каком этапе их дешевле закрыть

Список связан с категориями OWASP Top 10, но сгруппирован по тому, где ошибку проще остановить. Что означают сами категории, написано в статье «OWASP Top 10 простыми словами».

Класс ошибки
Откуда берётся
Где закрываем
Как проверяем
Класс ошибкиДоступ к чужим объектамсамый частый класс
Откуда берётсяПрава проверяются только в интерфейсе, а идентификаторы в адресах предсказуемы
Где закрываемТребования и ревью; общая функция проверки принадлежности объекта организации
Как проверяемПрогон из-под каждой роли с перебором идентификаторов
Класс ошибкиВнедрение запросовSQL и подобное
Откуда берётсяЗапрос к базе собирается склейкой строк с данными пользователя
Где закрываемОбщий способ построения запросов с параметрами; правило в ревью
Как проверяемПроверка кода правилами в сборке, ручной взгляд на рискованные места
Класс ошибкиПодмена страницыXSS
Откуда берётсяПользовательский текст попадает на страницу без экранирования
Где закрываемШаблоны с автоматическим экранированием, запрет вставки сырого текста
Как проверяемПравила в сборке, ручной ввод специальных символов при приёмке
Класс ошибкиСекреты в кодеключи, пароли, токены
Откуда берётсяКлюч скопирован «на время» и остался в истории репозитория
Где закрываемХранение вне кода, проверка перед коммитом и в каждой сборке
Как проверяемПоиск секретов по всей истории при внедрении
Подрядчики

Что записать в договор и приёмку, если код пишет подрядчик

Заготовка для договора: формулировки подгоняются под ваш проект, смысл остаётся. Вопросы к подрядчику шире описаны в статье «Как выбрать подрядчика на разработку ПО».

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

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

Цены — по тарифам. Сумма следующих этапов называется по итогам предыдущих, остановиться можно после любой ступени.

Обследование процесса: одна команда

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

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

Обследование: несколько команд и подрядчиков

Плюс сравнение практик команд, требования для договоров с подрядчиками и схема ответственности.

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

Пилот на одном продукте

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

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

Распространение на остальные продукты

Шаблоны и настройки переносятся на другие команды, добавляются моделирование угроз для новых модулей, проверка кода и конфигурации. Этапы с приёмкой.

этапами по 300 000–700 000 ₽

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

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

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

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

2–4 недели — Обследование: процесс как есть

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

Неделя — Требования и список для ревью

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

2–8 недель — Пилот на одном продукте

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

1–2 недели — Моделирование угроз новых модулей

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

Дальше — Распространение

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

Ежемесячно — Сопровождение

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

Цена

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

Число команд и подрядчиков

У каждой команды свои привычки и свой репозиторий. Работа растёт по числу различий в процессе, а не по числу людей.

Число ролей и объектов в продуктах

Требования к доступу и приёмка прогоном прав растут по числу пар «роль — объект». Продукт с двумя ролями и продукт с шестью ролями и правами на поля стоят по-разному.

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

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

Закрытый контур

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

Контроль

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

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

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

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

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

Процесс, аудит или автоматические проверки: что выбрать

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

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

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

Инструменты

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

Процесс и документы
  • Требования и шаблоны в репозитории в виде обычных текстовых файлов
  • Шаблоны запроса на слияние и тикета с вопросами по безопасности
  • Схемы потоков данных в тексте или в вашем инструменте диаграмм
  • Трекер задач, который у вас уже есть
Проверки и среда
  • GitLab CI, GitHub Actions или Jenkins
  • Gitleaks, OSV-Scanner, OWASP Dependency-Check, Trivy, Semgrep
  • Стенд приёмки с тестовыми учётными записями для каждой роли
  • Зеркала баз уязвимостей и внутренний репозиторий пакетов для закрытого контура
Материалы

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

Статья

Как встроить безопасность в разработку: Secure SDLC

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

  • Шесть этапов
  • Требования
  • Ревью и сборка
Читать →
Статья

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

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

  • Десять категорий
  • Проверки заказчика
  • Отчёт аудита
Читать →
Статья

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

Три проверки для старта и режимы подключения, чтобы релизы не встали.

  • Первая тройка
  • Режимы
  • Закрытый контур
Читать →
Заявка

Расскажите, как у вас устроена разработка

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

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

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

Вопросы

Частые вопросы: безопасная разработка веб-приложений

Сколько стоит внедрение безопасной разработки?

Обследование процесса стоит 200 000 ₽ для одной команды и 350 000 ₽ для нескольких команд или подрядчиков, оно вычитается из первого этапа. Пилот на одном продукте — 150 000–400 000 ₽ за 2–8 недель. Распространение на остальные продукты идёт этапами по 300 000–700 000 ₽, их цена называется после пилота.

Чем Secure SDLC отличается от аудита безопасности?

Аудит проверяет готовый продукт на дату проверки и даёт отчёт. Secure SDLC меняет процесс, чтобы типовые ошибки не доходили до продукта. Они дополняют друг друга: процесс снижает число находок, а аудит независимо проверяет, что процесс работает.

Нужен ли нам для этого специалист по безопасности?

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

Можно ли встроить это в договор с подрядчиком?

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

Как проверяется результат внедрения?

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

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

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

Решаете ли вы вопросы 152-ФЗ и GDPR?

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

Кому принадлежат правила и шаблоны?

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

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

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

Смежное

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