Есть момент, когда компания внезапно понимает: «мы уже не стартап на коленке, у нас продукт, клиенты, релизы, ответственность — и, кажется, пора взрослеть». Вот примерно там и появляется РБПО — разработка безопасного программного обеспечения.
В выпуске CrossCheck говорят: РБПО — не «для галочки» и не «для регулятора». Это про то, чтобы выжить в реальности, где код растёт, команды меняются, а рынок всё чаще спрашивает: «а вы вообще понимаете, из чего и как собраны ваши решения?».
РБПО — это не «секьюрити-проект», а культура разработки
Термин РБПО — это по сути ребрендинг того, что раньше называли SDL (Secure Development Lifecycle). С 2018 года в российской регуляторной повестке РБПО сместилось от формальных требований к реальным инженерным практикам.
Главный пойнт выпуска: РБПО — это не только про безопасность. Это про качество, управляемость и нормальную инженерную дисциплину. Без этого безопасность превращается в набор разрозненных инструментов, которые мешают выпускать фичи.
Если перевести на язык бизнеса: РБПО — это когда продукт делается предсказуемо, а не как получится.
Когда бизнес реально приходит к РБПО: три сценария
Почти все компании попадают в РБПО одним из трёх путей.
1) Комплаенс: «хотим продавать туда, где спрашивают»
Самый частый двигатель прогресса. Компания выходит на рынок, где требования к разработке и сертификации — часть входного билета. Неважно, это требования ФСТЭК, ЦБ, ФСБ или корпоративные требования большого заказчика. Как только появляется внешний спрос на доказательства зрелости, РБПО становится неизбежным.
2) Рост и хаос: «мы уже не вывозим релизы»
Вторая классика — продукт и команда растут, а управляемость падает. Сначала «файлики на диске, потом Git, потом трекер, потом тесты н»у хотя бы какие-то». Это не обязательно история про безопасность. Это история про то, что стоимость ошибок и регресса начинает убивать скорость.
3) Редкий случай: «мы обожглись»
Иногда компания приходит к РБПО после инцидента или жёсткого фейла. Но, как признают в выпуске, такое бывает реже, чем принято думать.
Почему аудит — шаг №0
Прежде чем покупать инструменты и нанимать фаззингистов, надо ответить на базовый вопрос:
От чего мы защищаемся и где у нас поверхность атаки? Пока вы не сделали моделирование угроз и не понимаете, что в продукте является критичным, можно ле��ко попасть в ловушку «сделали фаззинг, потому что надо фаззинг». Типичный случай: фаззер запускали бумажки есть — а что конкретно тестировали и зачем, никто толком не понимает.
Поэтому аудит — это не формальность. Это стартовая диагностика: что уже есть, чего нет, кто за что отвечает, сколько это вообще стоит по времени и людям.
Из чего реально состоит РБПО
Когда разговор доходит до практик, появляется важная вещь: РБПО — это не одна кнопка. Это набор дисциплин, которые закрывают разные дыры:
Инвентаризация состава продукта: зависимости, библиотеки, пакеты, компоненты. SBOM — звучит скучно, но это фундамент.
Композиционный анализ: open source не становится безопасным просто потому что «это опенсорс».
Статический анализ: проверка кода на типичные классы ошибок.
Динамический анализ и фаззинг: поиск падений и уязвимостей на продукте.
Минимизация привилегий и hardening: особенно больно в микросервисах и Kubernetes.
Тестирование как норма: не «перед релизом на удачу», а в процессе.
И важный нюанс от экспертов: если компания не понимает, из чего состоит её продукт, никакой shift‑left не случится. Нечего сдвигать влево, если вы не знаете, что проверять.
Сертификация: продукта и процесса — две разные вселенные
В выпуске объяснили различия:
Сертификация продукта (дистрибутива)
Здесь участвуют испытательные лаборатории: определяют поверхность атаки, набор испытаний, требования по уровню доверия и т. д. По факту современные продукты редко вписываются в формальные требования с первого раза, поэтому лаборатории часто подключаются раньше и оказывают методическую помощь. Да, иногда это выглядит как консалтинг — но иначе высок риск неудачи.
Сертификация процесса РБПО
Здесь лаборатории формально нет. Есть заявитель и орган по сертификации. А такие команды, как ФОБОС, выступают как аудит-консалтинг: помогают подготовиться, выстроить практики и собрать артефакты так, чтобы это работало не только на бумаге.
Важно: сертификат процесса — не «быстрый путь в тендеры». Даже в самой логике регулятора он позиционируется как способ упростить внесение изменений в сертифицированные продукты. Но компании всё равно л��бят им хвастаться — это повышает доверие.
Культура важнее инструментов
Если вы ждёте, что РБПО начнётся с закупки анализаторов — плохие новости. Самые большие затраты идут не на тулзы, а на смену культуры.
Потому что разработчики не мечтают писать тесты. Они мечтают, чтобы тесты «как-нибудь появились сами». А РБПО требует дисциплины: кто-то должен фиксировать состав продукта, кто-то моделировать угрозы, кто-то разбирать результаты анализа, кто-то автоматизировать конвейер.
И тут все приходят к выводу: без сильного DevOps не вывезем. Всё это должно быть автоматизировано, иначе РБПО действительно может затормозить разработку.
Слушайте и смотрите полный выпуск подкаста «CrossCheck 2.0: РБПО и сертификация — от паники к процессу»:
