Хрупкость программного обеспечения

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

Причиной хрупкости могут стать алгоритмы, не учитывающие весь спектр входных данных.

• Один из типичных случаев — алгоритм, допускающий деление на ноль или уравнение для аппроксимации, которое используется для экстраполяции за пределы исходных данных. К хрупкости также приводит использование структур данных с ограниченным диапазоном допустимых значений. Наиболее ярко это проявилось в конце 1990-х годов, когда выяснилось, что ряд программ рассчитан лишь на двухзначный ввод года; это привело к срочному обновлению огромного количества хрупкого ПО перед 2000 годом.
  • Ещё одним примером уязвимости перед нетипичными данными стал сбой Cloudflare 18 ноября 2025 года, когда жёстко заданный лимит не справился с аномальным объёмом данных конфигурации, что вызвало системную панику^[2].
• Ещё одна распространённая форма хрупкости проявляется в графических пользовательских интерфейсах, которые основываются на ошибочных предположениях. Например, при использовании экрана с низким разрешением окно программы может оказаться слишком большим и выходить за пределы отображаемой области. Возможно и обратное — окно слишком мало для большого экрана, без возможности изменения его размера, либо элементы интерфейса расположены некорректно из-за устаревших предположений разработчиков о разрешении. Ещё одна характерная проблема возникает, если пользователь выбирает нестандартную цветовую схему, из-за чего текст сливается с фоном, или нестандартный шрифт, который не помещается в выделенное поле и обрезает инструкции или надписи.

Часто старый исходный код просто забрасывается в пользу полностью нового проекта (переписывания системы с нуля), чтобы избавиться от ограничений устаревшей архитектуры, однако такой подход требует значительных временных и финансовых ресурсов.

Некоторые причины возникновения хрупкости программного обеспечения:

• Пользователи ожидают стабильности интерфейса. После внедрения той или иной функции крайне трудно убедить аудиторию принять существенные изменения, даже если функция была реализована неудачно или мешает дальнейшему развитию системы.
• Большой объём документации отражает текущее поведение системы; внесение изменений в документацию может быть дорого и трудоёмко. К тому же невозможно отозвать все устаревшие экземпляры документации, поэтому пользователи продолжают обращаться к неактуальным источникам.
• Первоначальные разработчики, обладавшие глубоким знанием всех нюансов, могут покинуть проект, не оставив исчерпывающей документации. Множество важнейших деталей могли передаваться только устно между членами команды и со временем быть безвозвратно утрачены, хотя некоторые нюансы восстанавливаются с помощью археологии программного обеспечения — сложного и ресурсоёмкого процесса.
• Вероятно, на протяжении времени выпускались многочисленные патчи, вносящие незаметные изменения в поведение системы. Многие патчи, устраняя одну ошибку, могут приводить к появлению других, более сложных для выявления сбоев. Если такие дефекты не обнаруживаются во время регрессионного тестирования, они усложняют последующую модификацию системы.
• Более тонкие проявления хрупкости встречаются в системах искусственного интеллекта, которые часто строятся на скрытых предположениях о входных данных. Если эти предположения оказываются неверными или неявно заданными, система способна реагировать совершенно непредсказуемо. Кроме того, инструменты ИИ-автодополнения ускоряют накопление технического долга: их применение приводит к росту сложности кодовых баз на 41 % и восьмикратному увеличению дублирования кода^[3][4]. ИИ также подвержен «галлюцинациям» (например, уверенному использованию несуществующих библиотек^[5]). Ситуация усугубляется слепым доверием разработчиков к сгенерированному коду, что ведёт к появлению скрытых логических ошибок и уязвимостей^[6].
• Программная система может быть хрупкой из-за излишней жёсткости зависимостей. Например, затруднения возникают при переходе на новые версии компонентов. Если один компонент ожидает, что другой выдаёт значения только в определённом диапазоне, а этот диапазон меняется, то это может привести к ошибкам по всей системе — на этапе сборки (компиляции) или во время выполнения (исполнения).
• Во время поддержки (этап жизненного цикла информационной системы) количество технических ресурсов для внесения изменений ограничено по сравнению с этапом разработки.

В 2025–2026 годах внедрение инструментов искусственного интеллекта для поиска ошибок привело к резкому росту числа выявляемых уязвимостей. В 2025 году было зарегистрировано более 48 000 CVE^[7], а в 2026 году прогнозируется удвоение этого показателя. При этом компании применяют ИИ преимущественно для превентивного внутреннего обнаружения недостатков, а не для их эксплуатации^[8]. Для снижения хрупкости программного обеспечения формируются новые требования к его архитектуре. Ключевыми подходами становятся непрерывная безопасность (Shift-Left)^[9], проверяемость на уровне архитектуры (Verifiability-as-Architecture) и устойчивость к недетерминированности. Изменяется роль ручного тестирования (QA): фокус смещается на стратегические ранние проверки ИИ-кода, при этом общее время тестирования сокращается^[10]. Для выявления хрупких участков применяются современные автоматизированные методы, такие как статическое тестирование безопасности с ИИ (AI-augmented SAST), симуляция атак до развёртывания (shift-left DAST) и управление состоянием безопасности приложений (ASPM correlation)^[11].