Не всем софтверным компаниям приходилось иметь дело с ошибками такой степени важности, как были с автомобилями Toyota (на Хабре), но с каждым днем всё более ясно: любая софтверная компания создает продукты со скрытыми дефектами безопасности. Исключений практически нет.

Если верить провайдеру услуг по тестированию ПО Veracode, который подготовил отчет к конференции RSA в Сан-Франциско, около 60 процентов ПО, пропущенного через их тестирование за последние 18 месяцев, провалило первый цикл тестов. Как отметил Роджер Оберг, старший вице президент по маркетингу Veracode, это были приложения от производителей, достаточно заботящихся о безопасности, чтобы в первую очередь использовать сервисы Veracode.

Данные Veracode не уникальны. В прошлом году исследование, проведенное WhiteHat Security, выявило, что 82 процента корпоративных вебсайтов содержали в себе уязвимости типа «высокая, критичная или особой важности» в обозримом прошлом, а 63 процента имели такие уязвимости на момент исследования.

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

Игра для разработчиков: убей хомячка**

Не надо думать, что для взломов используются сложные и малозаметные ошибки. Каждый год институт SANS (SANS Institute) и библиотека распространенных уязвимостей (CWE, Common Weakness Enumiration), спонсируемая правительством сторожевая собака, публикуют 25 наиболее распространенных и опасных программных ошибок. Как и в предыдущие годы, список 2010 не содержал много новинок, разве что непреднамеренный вывод конфиденциальной информации в сообщениях об ошибках или разрешение на неограниченную загрузку файлов опасных типов. Зато там полно таких детских ошибок как состояние гонки, переполнение буфера и неправильная обработка указателей массивов. Это вечные ошибки, уходящие корнями к рассвету программирования, но их распространенность и в 2010 поражает.

В добавок, факты говорят, что даже использование лучших практик может привести к ошибке. В 2006, Джошуа Блох из Google написал в блоге, что нашел ошибку в бинарном алгоритме сортировки из известной книги-справочника «Жемчужины программирования» Джона Бентли, опубликованной впервые в 1986. Хотя Блох и не пытался унизить Бентли, выяснилось, что Блох сам реализовал бинарный алгоритм поиска для JDK, содержащий точно такую же ошибку, и его оплошность оставалась незамеченной порядка девяти лет.

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

Разработчики приложений с открытым кодом любят расхваливать «закон Линуса», который гласит, что «при наличие достаточного количества глаз, все ошибки выявляются». Другими словами, прозрачность процесса разработки приложений с открытым кодом означает, что ошибки в открытом коде будут обнаруживаться и устраняться быстрее, чем в проприетарном ПО.

Однако, руководитель программы безопасности Microsoft Шон Херман оспаривает это утверждение и не без оснований. По Херману то, что программисты могут осматривать код на наличие ошибок, не означает, что они это делают; более того, практика показывает, что только оплачиваемые программисты на полном рабочем дне достаточно мотивированы на то, чтобы тратить время на осмотр чьего-то кода. Если это так – а мне кажется, что так – то только производители ПО с глубочайшими карманами (и, соответственно, наибольшими коллективами) могут реально выиграть на законе Линуса.

Будьте открыты

Но ничего из выше сказанного не означает, что безопасность ПО гиблый случай. Это не так, ответ кроется в понимании того, что ровно столько можно сделать с кодом. Каждый разработчик несет ответственность за то, чтобы поставлять код наилучшего возможного качества; «наилучшего возможного» является очень важной фразой. После этого, центр усилий любой стратегии безопасности ПО любого разработчика приходится не на процесс разработки, а на то как справиться с инцидентами в безопасности, когда они неизбежно случаться.

Давно минули дни, когда обновления*** доставлялись на CD и дискетах. Сейчас пользователи ожидают быстрого появления обновлений, практически со скоростью обнаружения уязвимостей. Хотя зачастую это может быть непрактичным, производители задерживают распространение критичных обновлений на свой страх и риск.
Напомню вам, что то как производитель распространяет обновления, может быть проблемой само по себе. Было время, когда Microsoft распространяла обновления сразу же, как только они были доступны. Но клиенты жаловались, что создается непомерная нагрузка на ИТ-персонал, который должен постоянно проверять и развертывать обновления. В ответ, Microsoft переключилась на текущую модель распространения – «Вторник обновлений», дважды в месяц. Этот подход тоже подвергся критики, в основном со стороны тех, кто говорит, что «Вторник обновлений» приводит к «Среде взломов»****, когда хакеры охотятся на тех, кто еще не установил последние обновления.

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

Альтернативой является насаждение культуры молчания и скрытности во всём, что касается сбоев безопасности; это прямой путь к провалу. Ситуация с Toyota отчасти нетипичная. Ближе к теме то, с каким нетерпением веб-разработчики ждут HTML 5, который, как ожидается, освободит их от кажущейся бесконечной череды ошибок, пролезших в расширения вроде Adobe Reader и Flash, и которые зачастую не устраняются неделями или даже дольше.

Чем больше исследований типа тех, что делают Veracode и WhiteHat Security, увидят свет, тем лучше заказчики будут понимать, что сбои безопасности являются частью жизни. Как только такое восприятие возобладает, заказчики потребуют не только обновлений, но и более тщательного поиска уязвимостей в безопасности. Вскоре, компании которые не будут регулярно выявлять угрозы в безопасности не смогут выглядеть производителями высококлассных приложений; они стану теми, у кого есть что скрывать.

Пометки к переводу
* — под ошибкой в тексте именуется баг (bug)
** — в оригинале, whack-a-mole, игра в которой из лунок вылезает зверек и по нему нужно ударить молотком; как это называется в русском языке я не знаю, в повседневной жизни использую название «убей хомячка»
*** — под обновлением в тексте подразумевается патч (patch), т.е. исправление ошибки, а не добавление нового функционала
**** — более точно «Среда эксплойтов» (Exploit Wednesday)

P.S. Согласен с мнением автора, иначе не переводил бы. На мой субъективный взгляд, применимо ко всем типам ошибок, а не только в сфере безопасности.