Сказка — ложь, да в ней намек, разработчикам урок.

В некотором опенспейсе, в некотором коворкинге завелся один стартап. С кофе-машиной, горящими дедлайнами и вечными созвонами. Решили там сделать ПОшечку невиданную — чтобы пользователи радовались, инвесторы кивали одобрительно, а деньги сами шли в кассу. 

И закипела работа, и стартовали один за другим спринты. Фичи выкатывались, метрики росли, разработчики героически коммитили по ночам. Вот только о безопасности в стартапе вспоминали примерно никогда. Некому было охранять секреты пользовательские, деньги виртуальные да API-ключи заветные. А хранилось всё это, прямо скажем, не самым надежным образом.

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

Позвали тогда богатыря бывалого — эксперта по безопасной разработке. Ну, то есть меня. И попросили научить разработчиков код проверять, секреты хранить да конвейеры защищенные строить. В общем, построить РБПО, но без бюджетов размером с ВВП сказочного государства.

Так появился этот цикл статей — про то, как собрать на коленке минимальный, но рабочий конвейер безопасной разработки. 

Долго сказка сказывается, да только CI/CD-пайплайн собирается еще дольше. Так что устраивайтесь поудобнее — расскажу, как строил «РБПО для бедных». 

В этой статье мы рассмотрим:

• что такое РБПО;

• зачем РБПО стартапам;

• какие ресурсы потребуются для сервисов РБПО;

• как спланировать конвейер безопасной разработки;

• и как будет выглядеть дальнейшая работа с «РБПО для бедных».

Дисклеймер

Важно сразу условиться, Путник!

Данный цикл статей не заменяет требования ГОСТ, OWASP SAMM, BSIMM и других серьезных методологий безопасной разработки. Это скорее практический пример того, как можно организовать конвейер безопасной разработки ПО с минимальным вложением средств. 

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

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

Ошибки возможны, и не нужно бояться их совершать. Главное — делать выводы и постепенно строить процессы, которые будут надежнее вчерашних. 

Да прибудет с вами си…
Хотя нет, это уже из другой оперы.

Что такое РБПО?

РБПО – это не страшный зверь и не заклинание из древней книги. Расшифровывается просто: «разработка безопасного программного обеспечения». Это подход, при котором о безопасности думают не в конце, когда код уже написан и убежал в прод, а на всем пути разработки — от проектирования ПО и написания первой строчки кода до доставки готового приложения пользователям. 

Представь, что ты строишь избу.

Можно сначала срубить стены, крышу, а потом уже думать: «А не забыл ли я печку заложить да под дымоход отверстие оставить?» — и в итоге переделывать половину.

А можно сразу закладывать безопасность в проект: дверь с секретом, окна на запоре, трубу печную без щелей. Вот РБПО – это и есть такой безопасно-строительный кодекс для разработчиков.

Если говорить языком государственным, требования к разработке безопасного программного обеспечения закреплены в ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования». 

Конечно, данный ГОСТ не обязателен для всех разработчиков. Но то, что какие-то практики не закреплены в законе или договора подряда — не повод их игнорировать. Есть езе разные BSIMM, DSOMM, SAMM и прочие заморские аббревиатуры, которые многим знакомы даже лучше отечественных стандартов. Но сейчас не про это. 

Актуальный ГОСТ Р 56939-2024 состоит из требований к 25 крупным процессам безопасной разработки ПО, покрывающим направления от определения требований безопасности к будущему ПО и моделирования угроз, до вывода из эксплуатации. РБПО – это масштабно.

В рамках этого цикла мы не будем рассматривать все практики разработки безопасного ПО, применимые к стартапам. Рассмотрим только часть. Позже, если материал окажется полезным, я продолжу расширять «РБПО для бедных» новыми инструментами и практиками безопасной разработки.

На текущий момент «РБПО для бедных» является сильно урезанной версией РБПО и состоит из набора бесплатных или условно-бесплатных инструментов (GitLab CI, Nexus, Vault, DefectDojo, Dependency-Track, Gitleaks, Trivy, Checkov, Opengrep, Nuclei), которые мы научим дружить и взаимодействовать между собой, чтобы проверять код на определенных этапах его написания, хранить и искать секреты, следить за зависимостями разрабатываемого ПО, анализировать контейнеры и хранить уязвимости в одном месте, без золотых подписок и серверов за миллион. 

На всякий случай еще раз хотел бы напомнить, что если вы разрабатываете суровый интерпрайз или разрабатываемое вами ПО является ГИС или частью КИИ, то вам нужно читать не данную статью, а ГОСТ Р 56939-2024 и иные НПА. 

Для чего РБПО стартапам?

Стартап – это как молодой рыцарь, который хочет завоевать мир, но у него ни доспехов, ни меча, ни даже коня нормального. Времени в обрез, денег впритык, а инвесторы требуют релизы каждый спринт. В такой гонке основатели обычно кричат: «Безопасность? Потом! На фазе масштабирования! Сначала — выжить!».

Вот тут-то и приходят хакеры-злодеи. Для них такой стартап – лакомый кусок: код сырой, пароли в репозитории, API без авторизации, зависимости древние как сам царь Горох. Один успешный взлом – и стартап превращается в тыкву, пользователи уходят, репутация рушится, инвесторы закрывают кошелек.

РБПО нужен стартапам как воздух, просто в более лайтовой версии – чтобы не ломать бюджет и не тормозить разработку. Даже минимальный набор практик позволяет: 

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

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

3. Успокоить инвесторов. Когда ты показываешь, что думаешь о безопасности, доверие растет.

4. Выполнить требования регуляторов. Даже маленький стартап может работать с персональными данными (152-ФЗ).

5. Не изобретать велосипед. Готовые открытые инструменты позволяют за день настроить то, на что раньше уходили месяцы.

В общем, «РБПО для бедных» – это не роскошь, а бронежилет для стартапа. Отсутствие РБПО — тоже своего рода стратегия. Но с риском для нервов.

Определяем ресурсы

«Кашу маслом не испортишь», – гласит народная мудрость. А у бояр масла – кот наплакал. Сел я на лавку, почесал репу и начал прикидывать, на чем же я конвейеры безопасные возводить буду. Принесли бояре мне чей-то домашний ПК, ну прямо скажу, не супер-пупер-машина, а так – середнячок. Скрин характеристик прилагаю, чтоб ты не думал, будто бы мне дали суперкомпьютер:

Ресурсов – в обрез, но как говорится: «Голь на выдумку хитра». «РБПО для бедных» – оно такое: не жирно, но задорно.

Взвесил я все за и против, и решил: «Понастрою-ка я пять виртуальных машин в VirtualBox. Пусть каждому сервису – своя изба. И нагрузку распределю, и бэкапить удобнее», а получится ли шустро – время покажет. Набросал я табличку – чтоб ничего не забыть.

Вот она, перед тобой:

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

Планирование конвейера РБПО

Планирование – самый важный этап работ. Лучше 2 дня потерять – потом за 5 минут долететь. Так что прежде чем рубить сплеча, я сначала набросал схему будущего конвейера. Вот что у меня получилось.

Основные этапы пайплайна (в порядке исполнения):

Этап 1: build – собираем приложение в кулак. На этом этапе мы не ищем уязвимости, а просто готовим то, что будем проверять и отправлять в хранилище.

• build – берем исходный код React-приложения, устанавливаем зависимости через npm, собираем статику.

• docker-build – ждем, когда build закончится, и собираем Docker-образ.

Этап 2: sbom – инвентаризируем все, что внутри. Теперь, когда у нас есть и исходники, и образ, составляем опись имущества (SBOM) – чтобы Dependency-Track потом отслеживал уязвимые библиотеки.

• sbom – генерируем SBOM из зависимостей, зафиксированных в конфигурационных файлах ПО, манифестах пакетов или других источниках данных, чтобы выявить все компоненты и зависимости, используемые в проекте.

• sbom-docker – генерируем SBOM из уже собранного Docker-образа.

Этап 3: code-scan – проверяем код и живое приложение. Самый ответственный этап. Здесь в дело вступают четыре анализатора: 

• secrets-scan (Gitleaks) – ищем случайно закоммиченные пароли, токены, ключи.

• sast (Opengrep) — проводим статический анализ кода на наличие кодовых конструкций потенциально являющихся дефектами безопасности (XSS, инъекции и пр.).

• iac-scan (Checkov) — проверяем файлы IaC конфигураций на наличие уязвимостей (Dockerfile, k8s, terraform).

• dast (Nuclei) — поднимаем стенд и проводим динамическое сканирование работающего приложения на наличие уязвимостей.

Этап 4: upload – отправляем артефакты в хранилища. Финальный аккорд. Все отчеты и образы должны быть готовы:

• defectdojo – собираем отчеты от четырех сканеров (secrets-scan, sast, iac-scan, dast) и отправляем в DefectDojo.

• dependency-track – собираем SBOM-файлы от sbom и sbom-docker и отправляем их в Dependency-Track через API (разные проекты – для приложения и для образа).

• nexus – публикуем Docker-образ в Nexus Registry.

Небольшое уточнение: SBOM нужен не только для первичной проверки зависимостей, но и для инвентаризации состава разрабатываемого ПО. Когда появится новая уязвимость в библиотеке, Dependency-Track сможет показать, какие проекты потенциально под угрозой.

У многих может возникнуть вопрос: почему стадия build идет раньше проверок безопасности? Логичнее ведь сначала искать уязвимости, а уже потом собирать приложение.

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

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

Краткое описание последующей работы

Вот что мы сделаем в следующих частях нашего цикла:

• Этап 1 – Подготовка VirtualBox и хостовой машины. Создадим пять виртуалок с Ubuntu Server, настроим сеть, установим Docker и базовые утилиты.

• Этап 2 – Установка сервисов. Развернем GitLab, Nexus, Vault, DefectDojo, Dependency-Track и CLI-инструменты (Checkov, Trivy, Gitleaks, Opengrep, Nuclei).

• Этап 3 – Базовая настройка. Зайдем в каждый сервис, сменим пароли, создадим репозитории, группы, API-ключи, настроим JWT-аутентификацию Vault с GitLab.

• Этап 4 – Пайплайн CI/CD. Напишем .gitlab-ci.yml с шаблонами, подключим раннеры, реализуем все стадии (build, sbom, code-scan, upload). Научимся получать секреты из Vault и не падать при находках.

• Этап 5 – Резервное копирование. Подготовим скрипты для Windows и Linux, настроим планировщик, чтобы лаборатория не пропала при сбое диска, проверим восстановление.

• Этап 6 – Тестирование на небезопасном приложении (Reactvulna). Прогоним через пайплайн специально уязвимый проект, посмотрим, что найдут сканеры, и сравним с ожиданиями.

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

PURP — Telegram-канал, где кибербезопасность раскрывается с обеих сторон баррикад

t.me/purp_sec — инсайды и инсайты из мира этичного хакинга и бизнес-ориентированной защиты от специалистов Бастиона