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

Когда руководителю предприятия озвучивают стоимость внедрения DevSecOps, он часто разводит руками. Проблема в том, что безопасники, проджекты, тимлиды и бизнесмены говорят на разных языках. Узкие технические задачи специалистов не дают мгновенную прибыль, а их польза маячит где-то на горизонте. В статье разберём, как говорить с владельцем компании на его языке — языке денег, рисков и репутации.

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

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

Методология безопасной разработки ПО (SSDLC) – относительно новое явление на российском рынке, несмотря на то, что появилась она еще 15 лет назад. Процесс внедрения SSDLC – довольно хлопотное и затратное занятие, успешных кейсов в России пока не так много. Однако результат внедрения оправдывает все ожидания и инвестиции.

Классическая концепция Software Development Life Cycle (SDLC) состоит из следующих шести шагов:

Десятки российских IT-компаний занимается разработкой своих продуктов. Подходы разные, но суть одна: программисты пишут тысячи, сотни тысяч и миллионы строк кода. При этом, по статистике, каждые 1000 строк содержат 50–60 критичных дефектов. У зрелых команд показатель 10–15 / 1000 строк. Тут важно разграничить два понятия - качественный код и безопасный код.

Однако при развертывании приложения выясняется, что в нем есть уязвимости, и злоумышленник может получить доступ к данным.Элементарный вариант: подобрать трехзначный код, если количество попыток ввода данных никак не ограничивается. И таких сценариев может быть несколько. Код качественный, так как система работает, но небезопасный, так как в систему легко проникнуть извне.

Безопасная разработка или подход DevSecOps подразумевает внедрение безопасности на каждом этапе разработки нового ПО. Его задача - не устранять возможные уязвимости готового приложения, а не допустить их возникновения. Приведем простую аналогию: подушки безопасности добавляют в момент сборки автомобиля, а не после тестирования или даже аварии. На каждом этапе разработки у специалистов свои “подушки”.

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

Нередко бывает, что новое ПО нужно уже “вчера”, особенно в условиях санкций. Быстро растут бизнес-системы, разработка также ускоряется. Внедрение безопасности тоже должно работать на опережение. Если ловить ошибки на этапе проектирования продукта и исправлять, то будут сокращены затраты на исправление цепочки дефектов после выпуска приложения. Клиент хочет продукт через месяц. Если на финальной стадии выявляется уязвимость, то исправление может занять еще месяц. В результате срыв сроков, удар по репутации.

1. Не говорите «безопасность» — говорите «деньги».
Плохо:Нам нужно внедрить безопасную разработку, чтобы соответствовать стандартам и защитить систему.

Хорошо:Если сейчас не учесть риски, можно потерять клиентскую базу и заплатить штраф в 3 млн рублей.

Владелец не думает категориями OWASP, XSS или утечек. Он думает цифрами: сколько потеряем, если не сделаем. Поэтому сначала — ущерб. Потом — причина. Только потом — решение.

2. Приводите реальные кейсы

Безопасная разработка кажется абстракцией, пока не вспоминаешь Tinkoff, «Госуслуги» или «Яндекс», у которых уже были проблемы с уязвимостями.

Пример:

В 2023 году у сервиса Х утекли данные 200 000 клиентов. Всё из-за простой ошибки в коде — никто не проверил права доступа. Компания потратила полгода на устранение последствий и потеряла часть пользователей. Мы можем избежать этого.

Чем ближе пример к вашему бизнесу, тем лучше он работает.

3. Покажите риски: что случится, если не делать

Безопасность кажется необязательной, потому что её отсутствие сначала не видно. Поэтому покажите, что происходит не сразу, но обязательно:

Всё, что можно посчитать, — считайте. Всё, что нельзя, — показывайте на чужих ошибках.

4. Дайте понятное решение

Плохо:Нам нужно внедрить DevSecOps, провести аудит, начать threat modeling...

Хорошо:Мы можем нанять специалиста, который проверит наш код и покажет слабые места. Это займёт две недели и обойдётся в Х тысяч. Это дешевле, чем устранять последствия инцидента.

Владелец хочет не безопасность, а спокойствие. И желательно — за понятные деньги.

5. Поддерживайте простым вопросом

Если всё равно сомневается, спросите:

Представь, что завтра наши данные утекают в сеть. Что мы делаем? Кто виноват?

Если ответа нет — продукту нужны инструменты и специалисты.

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

Через 2 дня именно эту тему — с примерами, кейсами и разбором инструментов-сканеров будут обсуждать на бесплатном митапе в Йошкар-Оле. Регайтесь и приходите.