“Разработчики и безопасность, это не война, а разговор на разных языках. Один говорит на языке функций и дедлайнов, другой — на языке угроз и комплаенса. И пока они не найдут общего кода, скорость будет проигрывать.”
Где начинается разрыв
Разработчик получает задачу: добавить в форму поле для телефона и сохранить его в профиль пользователя. Для него это — один endpoint, миграция базы данных и пара строк в интерфейсе. Он оценивает задачу в два дня. Затем приходит специалист по безопасности и говорит: «Телефон, это персональные данные по 152-ФЗ. Нужно шифровать поле в базе, обеспечить маскировку при выводе в логах, получить согласие на обработку, реализовать механизм удаления по запросу субъекта и провести оценку влияния на риски». Оценка тут же вырастает до двух недель.
Для разработчика это выглядит как искусственное усложнение. Его цель — сделать функцию рабочей и отправить её пользователям. Цель специалиста по безопасности — исключить риски, которые могут проявиться через месяцы или годы. Разработчик мыслит в плоскости конкретного кода и ближайшего спринта. Безопасность мыслит в плоскости системы, регуляторных требований и потенциальных инцидентов. Это два разных горизонта планирования, которые редко пересекаются в повседневной работе.
Язык требований против языка реализации
Требования по безопасности часто приходят в виде документов: политики, стандарты, приказы ФСТЭК. В них написано: «должна быть обеспечена аутентификация», «данные должны храниться в зашифрованном виде», «необходимо вести журналы безопасности». Для разработчика это абстракции высокого уровня. Ему нужны конкретные ответы: какой алгоритм шифрования использовать? Где хранить ключи? В каком формате писать логи и куда их отправлять?
Отсутствие перевода с языка регуляторики на язык инженерии создаёт вакуум. Разработчик либо игнорирует требования, потому что не понимает, как их применить, либо реализует их формально, создавая видимость compliance. Например, ставит галочку «логирование включено», но пишет логи в локальный файл, который никто не мониторит. С точки зрения проверки — требование выполнено. С точки зрения реальной безопасности — бесполезно.
Метрики, которые всё портят
В большинстве команд разработки ключевые показатели, это скорость. Количество закрытых задач, story points за спринт, time to market. Менеджеры смотрят на burndown-чарты и спрашивают, почему команда замедлилась. Безопасность же измеряется отсутствием событий: не было утечек, не было штрафов, не было инцидентов. Это негативная метрика. Её нельзя «закрыть» как задачу в Jira, её можно только поддерживать.
Когда разработчик тратит время на безопасность, его метрики падают. Он не может показать менеджеру красивый график с надписью «предотвратил пять потенциальных уязвимостей». Он может показать только сдвинутые сроки по фичам. В этой системе оценок вклад безопасности всегда невидим, а её стоимость — всегда очевидна. Это фундаментальный перекос, который заставляет воспринимать безопасность как накладные расходы, а не как часть продукта.
Культура «сначала выпустим, потом починим»
В индустрии десятилетиями доминировала agile-максима: «работающий продукт важнее исчерпывающей документации». На практике это часто вырождается в «сначала выпустим MVP, а безопасность и масштабирование добавим позже». Но «позже» никогда не наступает. Начинается гонка за новыми функциями, технический долг по безопасности копится, а переписать криво сделанную криптографию или систему аутентификации становится в разы дороже, чем сделать её правильно с нуля.
Проблема в том, что неработающая функция видна сразу — её нельзя продать. Неработающая безопасность невидима до момента взлома. Это создаёт иллюзию, что на безопасности можно сэкономить время. Риск откладывается в будущее, а скорость получается здесь и сейчас.
Безопасность как внешний контролёр
Часто команда безопасности существует отдельно от команды разработки. Она не участвует в планировании спринтов, а подключается на этапе code review или, что хуже, на этапе приёмки. В этот момент разработка уже завершена, команда мысленно перешла к следующей задаче. И тут приходит ревьюер с десятком критических замечаний: «Уязвимость инъекции», «Небезопасные прямые ссылки на объекты», «Ключи в коде».
Для разработчика это выглядит как саботаж. Он сделал рабочую фичу, а теперь ему говорят переделывать половину кода. Чувство собственности и завершённости нарушено. Если бы эти требования были озвучены в начале, их можно было бы учесть в архитектуре. Но на поздних этапах правки, это всегда костыли, хаки и недовольство. Безопасность воспринимается не как партнёр, а как надзиратель, который только и ждёт, чтобы сказать «нет».
Что не так с инструментами
Инструменты автоматизированной проверки безопасности (SAST, DAST) часто настроены так, что создают больше шума, чем пользы. Они выдают сотни предупреждений, большинство из которых — ложные срабатывания или малозначительные code style issues. Разработчик вынужден тратить время на разбор этого потока, теряя концентрацию на реальных задачах.
Хуже того, эти инструменты обычно не интегрированы в привычную среду разработки. Они работают где-то на стороне, отчёт приходит раз в неделю отдельным файлом. Проблемы, найденные в понедельник, к пятнице уже забыты, а контекст их возникновения утерян. Безопасность снова становится внешним, навязчивым процессом, а не частью потока разработки.
Регуляторный страх вместо понимания
В российском IT, особенно в госсекторе и финтехе, безопасность часто диктуется не технической целесообразностью, а страхом перед регулятором. Требования ФСТЭК или 152-ФЗ выполняются не потому, что это делает систему надёжнее, а потому, что «иначе не пройдём аттестацию» или «будет штраф». Такой подход убивает любую мотивацию разбираться в сути.
Разработчик не изучает, как работает ГОСТ-шифрование или механизм контроля целостности. Он просто копирует кусок кода из прошлого проекта, который «прошёл проверку». Это ритуал, а не инженерия. Ритуалы не развиваются, их нельзя оптимизировать. Они всегда будут восприниматься как бюрократическая помеха, потому что не несут для разработчика ясного технического смысла.
Как сдвинуть фокус с вражды на сотрудничество
Конфликт между скоростью и безопасностью — не данность. Это следствие процессов, которые можно изменить.
Сдвигать безопасность влево
Вместо того чтобы проверять код в конце, нужно встраивать безопасность в самое начало жизненного цикла. Участие security-архитектора в проектировании новой фичи. Использование шаблонов (security patterns) и безопасных библиотек по умолчанию. Проведение threat modeling для новых функций до написания первой строчки кода. Это превращает безопасность из контролёра в консультанта.
Говорить на языке разработки
Требования безопасности должны приходить не в виде PDF-приказа, а в виде готовых решений для кода. Не «нужно шифровать», а «используй вот этот модуль из нашего внутреннего репозитория, он уже сертифицирован, вот пример вызова». Не «нужно логировать», а «вот конфигурация для структурированного логгера, которая автоматически исключает чувствительные данные». Безопасность должна предоставлять API, а не документацию.
Измерять правильные вещи
Вместо того чтобы считать только скорость разработки, стоит ввести метрики, которые учитывают безопасность. Например, время от обнаружения уязвимости до её исправления (mean time to remediation). Или количество security-требований, учтённых на этапе дизайна. Важно показывать, что команды, которые работают с безопасностью «на опережение», в долгосрочной перспективе двигаются быстрее, потому что им не приходится постоянно останавливаться на экстренные патчи и переделки.
Автоматизировать рутину
Проверки, которые можно автоматизировать, должны быть встроены в CI/CD пайплайн и не требовать ручного вмешательства. Статический анализ кода, проверка зависимостей на уязвимости, сканирование конфигураций. Эти проверки должны падать быстро и давать чёткие, actionable рекомендации прямо в merge request. Идеал — когда разработчик получает feedback по безопасности так же быстро, как и feedback от линтера или unit-тестов.
Итог: не враг, а системная ограничивающая
Безопасность, это не враг скорости. Это такая же системная ограничивающая, как производительность, отказоустойчивость или удобство поддержки. Никто не называет нагрузочное тестирование «врагом скорости», хотя оно тоже требует времени и ресурсов. Его воспринимают как часть качества продукта.
Ключ — в изменении восприятия. Когда безопасность перестаёт быть внешним набором запретов и становится внутренним свойством кода, разработанного с учётом угроз, исчезает и конфликт. Разработчик перестаёт бороться с требованиями и начинает использовать безопасные практики как инструменты для создания более надёжного и, как ни парадоксально, более быстрого в долгосрочной поддержке продукта. В конце концов, самый медленный код, это тот, который пришлось полностью переписать после инцидента.