Типичная ситуация: небольшая компания заказывает сайт. Менеджер говорит — «нам нужен SSL и всё». Разработчик говорит — «вам нужен WAF, CSRF-токены, rate limiting и мониторинг». Организатор корпоратива в углу переживает, что через месяц презентация нового продукта, а они ещё не решили, кто отвечает за безопасность.

Что происходит на самом деле

Каждая сторона видит свой кусок пирога. Заказчик считает бюджет и думает: SSL-сертификат стоит 10 долларов в год, зачем платить больше? Разработчик смотрит на репу и думает: каждый эндпоинт — потенциальная дыра. Организатор мероприятия думает: презентация через 3 недели, API уже упал дважды, и никто не понимает, кто виноват.

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

Три узла разговора

Первый узел: терминология. Когда разработчик говорит «ваше API уязвимо к SQL-инъекции», заказчик слышит «что-то техническое, наверное дорого чинить». Организатор корпоратива слышит «презентацию придётся отложить».

Второй узел: приоритеты. Разработчик хочет переписать авторизацию с нуля. Заказчик хочет запустить лендинг к пятнице. Организатор хочет, чтобы к моменту презентации ничего не легло.

Третий узел: ответственность. Кто решает, какой уровень безопасности достаточен? Разработчик говорит — «я сделал по ТЗ». ТЗ написал заказчик. ТЗ не читал организатор, потому что думал про фуршет.

Как это обычно заканчивается

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

Организатор корпоратива обычно оказывается в роли буфера: переводит с языка разработчиков на язык заказчика и обратно. Без переводчика они не договорятся — у них разные модели угрозы.

Что реально работает

Один конкретный чек-лист на старте проекта. Не 50 пунктов — пять. Что защищаем? Кто отвечает за каждую часть? Что делаем, если что-то пошло не так? Какой канал связи для инцидентов? Когда пересматриваем?

Эти пять вопросов снимают 80% будущих споров. Не потому, что дают идеальную безопасность — а потому, что создают общий язык. Заказчик видит, что разработчик думает про риски. Разработчик видит, что заказчик понимает, за что платит. Организатор мероприятия наконец может планировать.