Компании тратят миллионы на кибербезопасность, но продолжают страдать от утечек данных. Ошибки дорого обходятся бизнесу: по данным IBM и Ponemon, средняя стоимость утечки данных в США в 2024 году достигла $4,88 млн. Российским компаниям инциденты обходятся, в среднем, в 11,5 млн руб. Почему так происходит?
Ответ кроется в устаревшей парадигме, где безопасность программных продуктов либо возникает прямо перед выпуском в эксплуатацию, либо вовсе осуществляется строго наложенными средствами (например, фаерволами приложений). Бизнес часто инвестирует в дорогостоящий мониторинг и «тушение пожаров», но скептически смотрит на подход, который сдвигает безопасность «влево», на самые ранние этапы разработки ПО, и таким образом предотвращает многие инциденты. Сдвиг влево, конечно, пугает, ведь там нужно строить процессы безопасности совместно с разработчиками.
Пора менять этот нарратив. Безопасная разработка — это не дорогостоящая «страховка», а стратегический рычаг для роста. Правильным образом внедренные инструменты DevSecOps не только защищают от киберугроз, но и ускоряют выпуск качественного ПО, делают процессы контролируемыми и предсказуемыми, а бизнес — более устойчивым.
В статье Алексей Смирнов, основатель платформы безопасной разработки CodeScoring, разбирается, как устроена культура реагирования, совмещенная с конструктивной безопасностью, какие экономические выгоды приносит DevSecOps и как говорить о безопасной разработке с владельцами бизнеса.
Когда безопасность работает на опережение
В любой крупной компании существует Security Operation Center (SOC). Эта команда — «пожарные» цифрового мира, ведь они круглосуточно следят за атаками и ликвидируют инциденты. Но тушить пожары всегда дороже, чем предотвращать, поэтому в крупных организациях, как правило, действует и направление безопасной разработки программного обеспечения (РБПО, DevSecOps). Его задача — делать продукты изначально устойчивыми к атакам, встраивая требования безопасности в сам процесс создания ПО.
Ключ к эффективности — применение практик безопасной разработки на всех этапах жизненного цикла ПО, не забывая про моделирование угроз еще на стадии проектирования. Это возможно благодаря подходу Shift Left («сдвиг влево») — переносу рутинных проверок и части экспертизы непосредственно в среду разработчиков. В зрелых организациях DevSecOps не просто «спускают» разработчикам директивы, но и проводят специальное обучение, которое знакомит их с принципами и инструментами безопасной разработки.
Российский рынок таких инструментов активно развивается. При этом доля безопасной разработки в общем объеме рынка информационной безопасности России остается незначительной — всего 4–5%. Это говорит о том, что многие компании по-прежнему воспринимают безопасность как защиту уже созданного продукта, а не как неотъемлемую часть его создания.
Ментальные барьеры для внедрения безопасной разработки
Несмотря на выверенность, логичность и даже поддержку DevSecOps в государственных стандартах (требования к процессам безопасной разработки закреплены, например, в ГОСТ Р 56939-2024) и приказах регуляторов (ФСТЭК России № 17, 21, 117 и 239), многие руководители по-прежнему видят в «сдвиге влево» лишь неоправданные затраты. Этот скепсис держится на трех устойчивых заблуждениях:
- «Безопасность — это тормоз». Зачастую бизнесу кажется, что любая дополнительная проверка неминуемо отодвигает релиз. Идея о том, что правильно выстроенная безопасность на старте (тот самый Shift Left) становится в итоге инструментом ускорения, для них неочевидна. На практике же команды-лидеры, развившие у себя практики безопасной разработки, выпускают обновления за часы — в то время как остальной рынок тратит на релизы недели. Умение сделать ценную подсказку по безопасности на нужном этапе существенно экономит время на лишнее общение между разработкой и защищающими и не приводит к остановке релиза по причине «поспорим в тикетах и решим».
- «Это неподъемные расходы». Владельцы бизнеса хорошо видят прямые издержки: лицензии на инструменты безопасной разработки, зарплаты специалистов, время на обучение. Но часто не учитывают скрытую «стоимость небезопасности» — будущие многомиллионные затраты на авральное устранение инцидентов, потерю репутации, штрафы регуляторов. По последним данным, 70–90% российских сервисов содержат уязвимости. Инвестиции в безопасность со «сдвигом влево» в таких условиях — залог стабильности в будущем.
- «Наши программисты и так все знают». Еще одно заблуждение — уверенность в том, что разработчик, который пишет качественный код, по умолчанию уделяет внимание и вопросам безопасности. По данным GitGuardian, около 15% разработчиков хотя бы раз случайно оставляют конфиденциальную информацию в коде (пароли, токены, ключи доступа), использует уязвимые сторонние библиотеки без должного контроля безопасности. Это происходит потому, что разработка сфокусирована на другом, а именно на достаточно качественном и быстром закрытии поставленных задач (Time-To-Market, TTM). При этом инструменты безопасной разработки должны помогать разработчику быстрее создавать заветные фичи и не должны отбрасывать его назад в этом творческом процессе.
К сожалению, базовое ИТ-образование и в России, и в мире всегда уделяло мало внимания вопросам кибербезопасности в подготовке кадров широкого профиля для рынка разработки (профильные кафедры здесь не учитываются). Поэтому считать, что разработчики интуитивно создают защищенные продукты, — опасная иллюзия.
Как говорить о безопасной разработке с владельцами бизнеса
Заблуждения заставляют бизнес отмахиваться от безопасной разработки как от «головной боли», но диалог можно построить, если перейти на язык выгод. Например, важно донести, что речь идет не о защите от абстрактных угроз, а об обеспечении бесперебойности — о том, чтобы новые функции, на которые сделана ставка, выходили в срок и без происшествий.
Пример: расчеты Endor Labs, которые показывают, что автоматизация обнаружения уязвимостей и проверки рисков на старте экономит 25% времени инженеров, повышает продуктивность команд до 50% и сохраняет компаниям миллионы долларов.
Это управление эффективностью, прямая директива рынка, о которой постоянно говорит министр цифрового развития Максут Шадаев, когда называет информационную безопасность главным трендом цифровой трансформации.
При этом отказ от «сдвига влево» — это история не только про упущенные выгоды, но и связанные с этим риски.
Пример: уязвимость Log4Shell, обнаруженная еще в 2021 году в библиотеке Java. Она получила высший балл опасности и мгновенно поставила под угрозу миллионы сервисов по всему миру — от новостных сайтов и маркетплейсов до финансового сектора. Злоумышленники начали использование уязвимости с первого дня в автоматическом режиме, пытаясь взломать все, до чего дотянутся их сканеры. Последствия известны — тысячи внедренных шифровальщиков, несчетное количество похищенных данных в самых разных отраслях экономики.
Компании с накопленным техническим долгом и без автоматизированного контроля за сторонними компонентами были вынуждены тратить недели и даже месяцы на авральный ручной поиск уязвимого кода во всем своем ПО. При наличии инструментов безопасной разработки та же задача могла быть решена за часы или даже минуты.
Эта история наглядно показывает разницу в трудозатратах и денежных расходах: в одном случае — глобальный кризис и колоссальные внеплановые издержки, в другом — управляемый, рутинный процесс обновлений.
И еще одно неочевидное преимущество DevSecOps — благодаря «сдвигу влево» разработчики лучше узнают свои продукты. Видят архитектуру, легко находят «мертвый» код и слабые места. Это чистый бизнес-плюс, ведь глубокое понимание процессов способствует дальнейшему развитию, «подсказывает», как улучшить существующие решения.
DevSecOps и РБПО: от философии к реализации
Путь от «тушения пожаров» к проактивному «сдвигу влево» — это глубокая трансформация культуры. Она предполагает, что безопасность перестает быть головной болью ИТ-департамента и превращается для бизнеса в управляемый параметр эффективности.
По сути, инвестиции в DevSecOps помогают компаниям не только управлять рисками (выпускать более безопасные приложения), но и оптимизировать всю работу над цифровыми продуктами, например, снижать нагрузку на ИТ-команды и значительно сокращать время выхода на рынок (Time-To-Market, TTM).
Безопасность, таким образом, из статьи расходов превращается в драйвер развития, становится неотъемлемым параметром жизненного цикла ПО, таким же, как качество. Можно предположить, что однажды само определение «безопасная разработка» станет тавтологией — ведь мы же не говорим «качественная разработка»? Как и качество, безопасность должна представлять собой устойчивый отраслевой стандарт, без которого невозможно представить цифровой бизнес.