Чтобы встроить безопасность в разработку, не нужна новая роль и не нужен дорогой инструмент: нужно на каждом этапе жизни задачи добавить один проверяемый шаг. В требованиях записать, кто что вправе делать. В проектировании разобрать, что может пойти не так. В ревью смотреть на права и ввод. В сборке запускать автоматические проверки. В приёмке прогонять права из-под каждой роли. Совокупность этих шагов и называют Secure SDLC, жизненным циклом безопасной разработки.
Главное отличие от аудита: аудит находит ошибки в готовом продукте, а процесс не даёт им туда попасть или хотя бы ловит их в день появления. Как выглядит разовая проверка, описано на странице «Аудит безопасности веб-приложения», как внедряем сам процесс, на странице «Безопасная разработка веб-приложений». Здесь разбираем, из чего он состоит и в каком порядке его собирать.
Что такое Secure SDLC и чем он отличается от аудита
SDLC — жизненный цикл разработки программы: от идеи до вывода из эксплуатации. Secure SDLC — тот же цикл, в котором на каждом этапе есть действие по безопасности. Это не отдельный стандарт, который надо сдавать, а способ организовать работу так, чтобы типовые ошибки не доходили до пользователей.
Разницу с аудитом удобно увидеть на одной таблице. Они не конкурируют: аудит проверяет, что процесс работает.
| Вопрос | Аудит | Secure SDLC |
|---|---|---|
| Когда проводится | Разово: перед запуском, после смены подрядчика, по требованию клиента | Постоянно: в каждой задаче и каждой сборке |
| Что даёт | Отчёт о состоянии на дату проверки | Привычки команды и проверки, которые работают без нас |
| Кто выполняет | Внешний исполнитель | Ваши разработчики, тестировщики и руководитель |
| Что устаревает | Отчёт теряет актуальность с первым релизом | Ничего: правила живут вместе с кодом |
| Когда нужен | Когда нужно знать, что происходит сейчас | Когда не хочется узнавать об ошибках от клиента |
Секреты в репозитории, чужие данные по прямой ссылке и устаревшие библиотеки находятся и без процесса, но каждый раз, когда их находит аудит, исправление стоит дороже: код уже в продакшене, клиенты уже пользуются, а автор задачи уже в другой команде.
Шесть этапов: что делается на каждом
Названия этапов у разных команд разные, суть одна. Ниже шесть этапов и для каждого минимальное действие, которое можно ввести за неделю, и расширенное, до которого команда дорастает позже.
| Этап | Минимум, с которого начинаем | Расширенный вариант | Что остаётся как след |
|---|---|---|---|
| Требования | Для каждой задачи с данными пользователей одна строка: кто видит, кто меняет, что пишется в журнал | Библиотека требований, из которой задача берёт нужные строки | Критерии приёмки в тикете |
| Проектирование | Вопрос «что может пойти не так» на разборе задачи, пять минут | Моделирование угроз по схеме потоков данных для новых модулей | Заметка в тикете или схема в репозитории |
| Разработка | Короткий список правил: ввод, права, секреты, логирование | Библиотеки и шаблоны, в которых правильный путь самый короткий | Правила в репозитории рядом с кодом |
| Ревью | Три вопроса к каждому запросу на слияние: права, ввод, секреты | Отдельное ревью рискованных мест вторым человеком | Комментарии в запросе на слияние |
| Сборка и приёмка | Поиск секретов и проверка зависимостей в каждой сборке; прогон прав из-под ролей перед релизом | Проверка кода правилами, образов и конфигурации, динамическая проверка на стенде | Отчёт сборки, запись о приёмке |
| Эксплуатация | Журнал входов и изменений, план обновления зависимостей, ответственный за инциденты | Разбор инцидентов, регулярная проверка восстановления из копии | Журнал, список обновлений, записи разборов |
Видно, что на старте почти ничего не требует денег: это вопросы, правила и журнал. Инструменты нужны там, где человек не справится сам, то есть в поиске секретов и зависимостей по всей истории репозитория.
Требования: как превратить «сделайте безопасно» в проверяемые строки
Требование «система должна быть защищена» нельзя ни реализовать, ни принять. Рабочее требование отвечает на вопрос «как это проверить». Хорошее правило: если тестировщик не может написать на него проверку, требование переписывается.
| Размытое требование | Проверяемое требование | Как проверяем при приёмке |
|---|---|---|
| Пользователи видят только своё | Запрос заказа другой организации возвращает отказ при любой роли и любом значении идентификатора | Из-под роли A открываем адреса объектов роли B, перебирая идентификаторы |
| Пароли хранятся безопасно | Пароли хранятся только в виде хеша с солью, на входе ограничено число попыток | Просмотр схемы и конфигурации; десять неверных попыток подряд блокируют вход |
| Файлы загружаются безопасно | Принимаются только перечисленные типы и размеры, файл не исполняется и отдаётся по ссылке с проверкой прав | Загрузка запрещённого типа и слишком большого файла, запрос ссылки без прав |
| Действия фиксируются | Вход, смена прав, выгрузка и удаление пишутся в журнал: кто, когда, над чем | Выполняем действия и находим их в журнале |
| Данные защищены при передаче | Все обращения идут по защищённому соединению, секретные заголовки и токены не попадают в журнал | Просмотр конфигурации входа; поиск токенов в журнале после тестового прогона |
Первые пять-шесть таких строк записываются один раз и копируются в критерии приёмки каждой задачи, где они уместны. Через квартал они превращаются в короткий документ «наши требования к безопасности», который отдаётся и новому сотруднику, и подрядчику.
Проектирование: моделирование угроз за час
Моделирование угроз звучит тяжело, но его рабочая версия занимает час на новый модуль. Берём схему, где видно, какие данные откуда и куда идут, и по каждому потоку задаём вопросы. Ниже рабочий порядок.
- Нарисуйте поток. Пользователь, веб-приложение, база, внешние сервисы, хранилище файлов. Каждая граница между ними — место, где данные переходят из одного уровня доверия в другой.
- Для каждой границы спросите: кто может подделать запрос. Любой пользователь? Другая организация? Сервис с лишними правами? Внешний вызов вебхука?
- Для каждого хранилища спросите: что будет, если оно утечёт. Если ответ «ничего страшного», можно не защищать усиленно. Если ответ «все данные клиентов», защита нужна на уровне хранения.
- Для каждого сценария спросите: что будет, если им злоупотребить. Бесконечные запросы, перебор адресов, массовая выгрузка.
- Запишите три-пять решений. Не отчёт на двадцать страниц, а список: что сделаем, где проверим, кто отвечает.
Результат хранится в репозитории рядом с кодом и пересматривается, когда меняется схема потока. Модуль, который просто добавляет поле в форму, моделирования не требует.
Разработка и ревью: что смотреть в запросе на слияние
Ревью уже есть в большинстве команд, и это самое дешёвое место для безопасности. Нужно только договориться, на что смотреть кроме стиля. Для начала хватит трёх вопросов к каждому запросу:
- Права. На сервере ли проверяется, что пользователь вправе видеть и менять этот объект? Не только по роли, но и по принадлежности объекта его организации.
- Ввод. Каждое значение из запроса, файла или внешней системы проходит проверку типа, длины и допустимых значений? Запросы к базе строятся с параметрами, а не склейкой строк?
- Секреты и журнал. Не появились ли в коде пароли, ключи, токены? Не попадают ли в журнал персональные данные и секретные значения?
Затем список растёт по тем ошибкам, которые команда уже допускала: нашли чужой заказ по прямой ссылке, добавьте в ревью вопрос про принадлежность объекта. Отдельная категория — рискованные места: вход, смена пароля, загрузка файлов, выгрузки, платёжные и интеграционные обработчики. Их стоит смотреть вдвоём. Как устроено специализированное чтение кода, описано на странице «Аудит кода и архитектуры».
Сборка и приёмка: что находит автоматика и чего она не видит
Автоматические проверки в сборке дополняют ревью, но не заменяют его. Вот что за что отвечает.
| Проверка | Что находит | Чего не находит | Когда включать |
|---|---|---|---|
| Поиск секретов | Пароли, ключи и токены в коде и в истории репозитория | Секреты, которые хранятся в виде, непохожем на ключ | Первой, в первую неделю |
| Проверка зависимостей | Библиотеки с известными уязвимостями | Ошибки в вашем собственном коде; уязвимости, о которых ещё не знают | Второй, в первый месяц |
| Проверка кода правилами | Типовые опасные конструкции: склейка запросов, небезопасные функции | Логические ошибки доступа, ошибки в бизнес-правилах | Когда команда привыкла к первым двум |
| Проверка образов и конфигурации | Лишние пакеты, запуск от администратора, открытые порты в описании развёртывания | Фактическое состояние боевой среды | После перехода на контейнеры |
| Динамическая проверка на стенде | Отсутствующие защитные заголовки, видимые ошибки конфигурации, часть типовых уязвимостей | Права на уровне объектов и бизнес-логику | После выхода на устойчивый стенд |
| Прогон прав из-под ролей | Доступ к чужим объектам, отсутствие проверок на сервере | Уязвимости, не связанные с правами | При приёмке каждого релиза с новыми ролями или объектами |
Последняя строка таблицы делается руками или тестами, и именно её чаще всего пропускают, хотя нарушение контроля доступа остаётся самым частым классом ошибок. Подробнее о классах — в статье «OWASP Top 10 простыми словами». Как организовать запуск автоматических проверок в сборке и не остановить релизы, разобрано в статье «DevSecOps: с чего начать небольшой команде».
Эксплуатация: что делать после релиза
После запуска безопасность не заканчивается: библиотеки стареют, появляются новые сведения об уязвимостях, меняются люди. Минимум, который нужен каждому продукту:
- Журнал. Входы, смена прав, выгрузки, удаления. Журнал хранится отдельно от приложения и не содержит секретных значений.
- Плановое обновление зависимостей. Раз в спринт или раз в месяц, по расписанию, а не «когда дойдут руки». Срочные обновления делаются вне расписания.
- Ответственный за инциденты. Конкретный человек и запасной. Что он делает в первый час: отключить скомпрометированный ключ, закрыть уязвимый адрес, сообщить тем, кого касается.
- Проверка восстановления из копии. Копия, которую не пробовали разворачивать, не считается.
- Разбор после инцидента. Какое действие на каком этапе процесса не сработало и что добавить в требования, ревью или сборку.
Последний пункт замыкает цикл: каждая найденная ошибка превращается в строку в одном из этапов и больше не повторяется. Круглосуточного дежурства у нас нет, поэтому, если ваши договоры его требуют, учитывайте это отдельно; плановое сопровождение описано на странице «Сопровождение ПО».
Как внедрять постепенно: порядок на первые три месяца
Попытка ввести всё сразу заканчивается тем, что команда обходит правила. Реалистичный порядок выглядит так:
| Период | Вводим | Как понять, что прижилось |
|---|---|---|
| Первая-вторая неделя | Поиск секретов в репозитории, три вопроса в ревью, ответственный за безопасность в команде | Ревьюеры сами задают вопросы про права |
| Первый месяц | Требования к доступу в критериях приёмки, проверка зависимостей в сборке, план обновлений | Каждая задача с данными имеет проверяемые строки |
| Второй месяц | Прогон прав из-под ролей при приёмке, простая модель угроз для новых модулей | Приёмка ловит ошибки до релиза |
| Третий месяц | Проверка кода правилами, проверка образов, разбор первых инцидентов или находок | Находки разбираются в день появления, а не копятся |
Если подрядчики пишут часть кода, те же строки записываются в договор и приёмку: требования к безопасности, право на проверку кода, исходники в вашем репозитории и отчёт сборки по каждому релизу. Вопросы, которые стоит задать подрядчику, собраны в статье «Как выбрать подрядчика на разработку ПО». Для продуктов с несколькими клиентами добавляется отдельная тема, разделение данных клиентов, описанная в статье про мультиарендность.
Что делаем мы и с чего начать
Начинаем с обследования процесса: 200 000 ₽ и 2–3 недели для одной команды, 350 000 ₽ и 3–4 недели, если команд или подрядчиков несколько. Смотрим, как у вас идёт задача от идеи до релиза, где уже есть безопасные привычки, где их нет, и что можно ввести без остановки работы. На выходе карта процесса, набор проверяемых требований, шаблон моделирования угроз, список для ревью и порядок внедрения. Обследование вычитается из первого этапа, если продолжаете с нами, а документами можно пользоваться и без нас.
Дальше, если нужно, пилот на одном продукте: от 150 000 до 400 000 ₽ за 2–8 недель. Мы настраиваем проверки в вашей сборке, пишем правила и обучаем ревью на ваших задачах, а не на учебных примерах. Мы не отдел безопасности и не дежурим круглосуточно, лицензии ФСТЭК у нас нет, боевые системы мы не атакуем. Исходники и настройки лежат в вашем репозитории с первого коммита. Цены и сроки — на странице «Тарифы», описание услуги — на странице «Безопасная разработка веб-приложений».
Частые вопросы
Что такое Secure SDLC простыми словами?
Это обычный цикл разработки, в котором на каждом этапе есть небольшое действие по безопасности: требования с проверяемыми строками, вопрос «что может пойти не так» при проектировании, три вопроса в ревью, автоматические проверки в сборке и прогон прав при приёмке. Отдельного стандарта, который надо сдавать, здесь нет.
Чем Secure SDLC отличается от DevSecOps?
Secure SDLC описывает весь цикл, включая требования, проектирование и ревью, а DevSecOps — автоматические проверки в сборке и выкладке. DevSecOps можно считать частью Secure SDLC, которая лучше всего поддаётся автоматизации.
Нужен ли для этого отдельный специалист по безопасности?
Для старта нет. Достаточно назначить ответственного в команде, который ведёт список вопросов для ревью и следит за результатами проверок. Внешний специалист нужен для первоначальной настройки, моделирования угроз сложных модулей и независимой проверки.
С чего начать, если времени почти нет?
С трёх вещей, которые занимают неделю: поиск секретов в репозитории, три вопроса в ревью про права, ввод и секреты, и проверяемые требования к доступу в критериях приёмки. Остальное добавляется по мере привыкания.
Как встроить безопасность, если код пишет подрядчик?
Записать требования в договор и приёмку: проверяемые строки по доступу и данным, право проверять код, исходники в вашем репозитории с первого коммита, отчёт автоматических проверок по каждому релизу. Приёмку с прогоном прав из-под ролей делаете вы или независимый исполнитель.
Заменяет ли процесс аудит безопасности?
Нет. Процесс снижает число ошибок и ловит их раньше, а аудит независимо проверяет, что он работает. Перед запуском продукта или по требованию клиента отчёт аудита всё равно нужен.
Можно ли внедрить Secure SDLC в закрытом контуре?
Да. Проверки работают на вашем сервере сборки, а базы известных уязвимостей зеркалируются внутрь контура и обновляются по расписанию. Код никуда не передаётся.
Сколько стоит внедрение Secure SDLC?
Обследование процесса стоит 200 000 ₽ за одну команду и 350 000 ₽ за несколько команд или подрядчиков, оно вычитается из первого этапа. Пилот на одном продукте — 150 000–400 000 ₽ за 2–8 недель. Дальнейшие этапы называются после пилота.