Разрушители мифов: топ-5 заблуждений о безопасности ПО

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

При всей критической важности безопасность ПО по-прежнему остаётся сложной задачей для многих компаний. Вокруг этой темы существует немало заблуждений, мешающих выстраивать эффективную защиту. В этой статье мы разберем пять типичных мифов о безопасности ПО, развенчаем их и дадим рекомендации, как сделать  вашу инфраструктуру безопаснее.

Проверьте себя. Если совпадает хотя бы два пункта, то безопасность у вас, скорее всего, формальная:

• Разработчики узнают об уязвимостях после релиза.
• Обновления зависимостей откладываются «на потом».
• Нет автоматических проверок в CI/CD.
• Безопасностью занимается отдельная команда, не вовлечённая в разработку.
• Нет SLA на исправление уязвимостей.

В такой ситуации процессы есть, но они не влияют на итоговое качество и скорость разработки.

Безопасность чаще всего «ломается» не из-за отсутствия практик, а из-за того, на каком этапе их применяют.

Чем позже обнаруживается проблема, тем дороже и сложнее её исправить — это ключевая логика, на которой строится подход Shift Left.

Ниже не просто распространённые заблуждения, а типичные точки, где процессы начинают давать сбой.

Заблуждение 1: «Безопасности через сокрытие достаточно»

«Безопасность через сокрытие» (security through obscurity) — это подход, при котором делают ставку на скрытность как на основной способ защиты. Предполагается, что злоумышленники не смогут найти уязвимости, если не знают, какую операционную систему (ОС) вы используете, на каком оборудовании она работает, на каком языке написано приложение и т. д. Однако у этого подхода есть фундаментальные ограничения: например, он мешает внедрять политики вроде “Zero Trust”.

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

Голландский криптограф Огюст Керкгоффс в своей книге «Военная криптография» 1883 года описал принцип, согласно которому в засекреченном виде должна быть только малая часть системы, которую сейчас мы называем ключами, токенами, секретами и паролями.

Что делать

• Не полагаться на скрытность как основной механизм защиты.
• Внедрять подходы вроде Zero Trust.
• Повышать прозрачность в системе.
• Выстраивать сотрудничество между командами безопасности и разработки.

Заблуждение 2: «Мой бизнес слишком мал, чтобы стать целью кибератак»

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

Малому и среднему бизнесу стоит уделять внимание безопасности ПО.

Что делать

• Разработать комплексный план кибербезопасности.
• Регулярно обучать сотрудников.
• Своевременно обновлять программы, приложения, браузеры и ОС.

Заблуждение 3: «Риски несут только внешние угрозы»

В сфере кибербезопасности есть распространенное мнение, что все угрозы приходят извне. Поэтому защитные меры часто строятся против внешних атак, а внутренние риски остаются без должного внимания. Однако согласно отчёту Verizon Data Breach Investigations Report за 2023 год, 74% всех утечек связаны с человеческим фактором: ошибки работников, злоупотребление привилегиями, использования украденных учётных данных или социальной инженерии. 

Что делать

• Учитывать внутренние угрозы наряду с внешними.
• Внедрить принцип наименьших привилегий.
• Ограничить доступ сотрудников необходимым минимумом прав.

Заблуждение 4: «Безопасность замедлит разработку»

Организации нередко откладывают внедрение рекомендации по безопасности из-за опасения, что это задержит выход продукта на рынок и помешает развитию технологий. Да, учёт требований безопасности увеличивает расходы, но внедрение мер защиты на ранних этапах поможет избежать дорогих исправлений потом. Итеративное развитие такого аспекта системы, как информационная безопасность продукта, также является частью жизненного цикла разработки ПО (Software Development Lifecycle, SDLC).

Что делать

• Внедрять меры безопасности на ранних этапах разработки.
• Учитывать безопасность как часть жизненного цикла разработки ПО (SDLC).
• Использовать подход Shift Left.
• Применять автоматизацию, управленческие процедуры и доверие к разработчикам.
• Внедрять проактивные меры безопасности.

Заблуждение 5: «За безопасность отвечает только команда безопасности»

Безопасность ПО — командная работа. У инженерных команд есть соблазн “забыть” про безопасность и сосредоточиться на разработке, но по мере усложнения приложения усложняются и появляются новые векторы атаки. Поэтому важно, чтобы безопасность стала общей задачей.

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

В Axiom JDK, мы понимаем, что одним из самых легкодоступных векторов атаки для злоумышленника являются известные уязвимости в неподдерживаемых версиях используемых open-source технологий. Чем дольше система использует такой код без обновлений, тем больше CVE там будет обнаружено и опубликовано. Всё хорошо, пока мейнтейнер поддерживает версию, которую вы используете, но обычно они фокусируются на так называемой upstream-ветке и старые релизы быстро перестают поддерживаться. Так же дела обстоят и со Spring. Минорные релизы поддерживаются не больше года. Если нужно дольше, то покупайте коммерческую поддержку. В России приобрести поддержку у Broadcom нельзя, зато можно у Axiom JDK. Мы поддерживаем Spring Boot LTS самых популярных версий Spring Boot — 2.7 и 3.5.

Что делать

• Воспринимать безопасность как общую задачу.
• Выстраивать сотрудничество между командами безопасности и разработки.
• Формировать культуру, в которой безопасность — часть процесса.
• Учитывать безопасность на всех этапах разработки и эксплуатации.

Один из самых недооценённых факторов риска — использование неподдерживаемых версий open-source.

Если обновления откладываются:

• Накапливаются CVE.
• Увеличивается вероятность эксплуатации уязвимостей.
• Растёт стоимость исправления.

Пока версия поддерживается — риски контролируемы.После окончания поддержки — каждая новая уязвимость остаётся на вашей стороне и уже вы отвечаете за последствия.

По практике чаще всего встречаются:

• Обновления откладываются «на потом».
• Security-инструменты есть, но их игнорируют.
• Нет SLA на исправление уязвимостей.
• Разработка и безопасность работают изолированно.
• Проверки выполняются нерегулярно.

Все эти сценарии приводят к одному: уязвимости доходят до продакшена.

Отдельный фактор — ограниченный доступ к западной поддержке и инструментам.

Это означает:

• Сложнее получать обновления и патчи.
• Выше риск использования неподдерживаемых версий.
• Больше зависимость от open-source.

В таких условиях особенно важно:

• Контролировать жизненный цикл зависимостей.
• Учитывать сроки поддержки.
• Заранее планировать обновления.
• Почему вопрос поддержки становится критичным (на примере Spring).

Известные уязвимости в неподдерживаемых версиях — это один из самых простых векторов атаки.

Проблема в том, что:

• Upstream-проекты быстро прекращают поддержку старых версий.
• Минорные версии Spring поддерживаются около года.
• После этого безопасность полностью ложится на команду.

В глобальной практике это решается через коммерческую поддержку.

В России доступ к ней ограничен.

Axiom JDK предлагает альтернативу: поддержку Spring Boot LTS для популярных версий (2.7 и 3.5), включая обновления безопасности.

Большинство проблем с безопасностью не связано с отсутствием инструментов.

Они возникают из-за того, что безопасность:

• Внедряется слишком поздно.
• Не встроена в процесс разработки.
• Воспринимается как отдельная функция.

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