Прекращение поддержки софта — это проблема, которая так или иначе касается многих, но внимания ей при этом уделяют недостаточно. Представьте, что вы, поддавшись рекламе, покупаете не обычный, а дорогой умный холодильник, с wi-fi и кучей фичей для умного дома. А через два года производитель холодильника прекращает поддержку серверов этой модели. Аппаратная часть, которая могла прослужить еще десятки лет, перестает работать, потому что программная часть больше не функционирует. То же самое справедливо и для индустрии разработки: совместимость устаревшего софта с постоянно обновляемыми платформами — это головная боль.

Пост подготовлен по материалам подкаста Software Engineering Radio. В этом выпуске Росс Андерсон, профессор компьютерных наук и инженерии из университета Кембриджа, автор книги Security Engineering, a Guide to Building Dependable Systems, рассказал о проблемах, связанных с циклом поддержки софта, на примере автомобильного и других рынков.

С развитием умных устройств во всех сферах жизни поддержка софта становится все критичней. Вот с одной стороны, переход на электрокары — это здорово, потому что трансмиссия электрокаров включает всего около 100 деталей. А у трансмиссии для двигателей внутреннего сгорания деталей в 20 раз больше. Не нужно нанимать столько автомехаников. Но вместо них нужен огромный штат специалистов по разработке, который поддерживают «умную» трансмиссию. Так что, по сути, эта нагрузка просто перекладывается на другие плечи. Для Индии это хорошо, потому что у множества местных специалистов техподдержки будет больше работы. А вот для высококвалифицированных механиков, сосредоточенных в основном в Северной Америке и Западной Европе, перемены уже неприятны.

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

У моей жены был Lexus, выпущенный почти 20 лет назад. В прошлом году мы купили вместо него новую машину. Но почти все время, пока «лексус» был у моей жены, мы не могли использовать GPS, потому что навигация и отображение карты были спроектированы для поколения автомобилей 25-летней давности. На дашборде машины постоянно всплывало странное окно с движущейся картой. Оказывается, чтобы эта функция работала корректно, каждый год нужно покупать DVD Lexus с обновлениями мировой карты. Производитель перестал выпускать их лет десять назад, так что целая подсистема автомобиля перестала функционировать. Как заменить ее? Конечно, мы прицепили держатель на решетку вентиляции, установили туда телефон и запускали приложение с картами.

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

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

Жизненный цикл автомобилей

Вообще, мне нравится идея встраивать в устройства некий автоматический тумблер, который по окончании срока поддержки устройства отключает его от интернета в принципе. Так устройство станет более надежным. Моя жена из Кейптауна, мы часто путешествуем по разным континентам. Когда мы приезжаем в Африку, то видим много машин, выпущенных более 20 лет назад. Их первая жизнь прошла в Британии, Сингапуре или Японии; через 10 лет после выпуска их погрузили на корабли в Африку, где машины проездили еще 10 лет, пока не развалились на куски.

Такой срок экспорта имеет логическое объяснение. Во многих развитых странах автомобили раз в год проходят техосмотр. У них проверяют тормоза, фары, колеса и вообще все, что связано с безопасностью на дороге. Очень скоро начнут проверять и софт. Если производитель больше не выпускает апгрейды софта, машину либо экспортируют, либо переработают.

С 2016 по 2019 год в Евросоюзе шли споры о том, как долго автопроизводители должны поддерживать софт. Крупные компании заявили, что они не будут поддерживать софт больше шести лет, поскольку таков срок обслуживания, указанный в договоре продажи. Представители Евросоюза в ответ заявили, что, поскольку автопроизводители обязаны предоставлять запчасти в течение 10 лет, то и софт они должны обновлять столько же. Тогда концерны удалось прогнуть — их политическая позиция была ослаблена «дизельгейтом».

Получается, что через 5–10 лет максимальный срок эксплуатации автомобиля в Европе составит не около 16 лет, как сейчас, а 10 лет. Как минимум в переходный период количество списанных машин увеличится на миллионы. Что с ними делать, в Африку экспортировать? Там, скорее всего, объем рынка будет недостаточен. К тому же не каждой африканской стране интересны европейские авто. В Кению, например, большинство машин прибывает из Японии; местные специалисты привыкли к японским авто и мануалам на японском. Непонятные «европейцы» здесь неинтересны, особенно с перспективой необходимых критических апдейтов софта.

Уменьшая жизненный цикл автомобиля, нужно помнить, что углеродный след автомобиля — это в равных пропорциях выбросы от его производства и эксплуатации. Если списывать авто через 10 лет, за счет производства итоговые выбросы углекислого газа значительно увеличатся.

Чтобы продлить жизнь автомобилям хотя бы на вторичных рынках, нужно озаботиться поддержкой программного обеспечения. Дело это непростое, потому что ПО для автомобиля — это обычно совместный труд примерно 40 разных компаний. Контроллер тормозов, контроллер двигателя, система доступа без ключа, контроллер выдвижной крыши… очень много софта. Критически важными здесь могут быть всего 3–4 компонента. Интеграционное тестирование безопасности — это сложный и дорогой процесс. Кто будет этим заниматься?

Жизненный цикл софта

Это подводит меня к другому вопросу: как определяется жизненный цикл программного продукта? В 1960-е годы, когда IBM начали продавать свои мейнфреймы в компании, стало понятно, что IT-индустрия все меньше начинает зависеть именно от IT-специалистов. С тех пор, наверно, треть всех проектов в области софта закончилась катастрофой. И это только в компаниях — в правительстве доля таких проектов достигает двух третей.

В ответ на эти изменения стал развиваться подход программной инженерии (software engineering). У его истоков стоял Брайан Рэндалл, работавший тогда в университете Ньюкасла. Идея была в том, чтобы применить к ПО тот же подход, который в Ньюкасле используют для строительства кораблей. Все начинается с общего плана строительства. Затем закладывают киль, строят каркас корпуса, размещают двигатели, стелют палубы, заполняют пустоты. Такой последовательный подход должен был сработать и в создании софта.

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

Разные подходы к обновлению ПО

Ситуацию здесь усугубляет то, что вендоры ПО подходят к поддержке и взаимодействию по-разному. Создатели языка Rust горят работой и выпускают патчи даже к тем версиям, которые пока не дошли до публики. Технологические гиганты в ответ на обращения часто и вовсе отмалчиваются, не желая сотрудничать и изменять свои продукты. А некоторые, типа Oracle, переходят в атаку: «Нет у нас в Java никакой уязвимости, это в вашем редакторе проблема». Это разные культуры работы с продуктом; в таких условиях невозможно договориться о едином сроке поддержки софта.

У меня есть немалый опыт в поиске уязвимостей софта. Когда мы приходили с ними в компании с разработкой на аутсорсинге, те посылали нас к своим подрядчикам. Подрядчики, в свою очередь, отвечали, что это не уязвимость. У первой линии поддержки обычно есть список вещей, к которым они должны относиться серьезно — например, к вопросам удаленного выполнения кода. Если прийти к ним с чем-то не из списка, они ответят, что это для них «слишком сложно». Любой сценарий, выходящий за пределы стандартных, приходится эскалировать на пользователей софта. Если они забеспокоятся, то поставщик софта может потерять клиента, поэтому он начинает включаться быстрее .

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

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

Если вы заказываете софт в Индии, разработчик обычно обязуется поддерживать его в течение 90 дней. В Китае ситуация хуже, потому что индустрия электроники развивается прежде всего за счет аппаратной составляющей, а уже потом там думают о поддержке. В 2016 году с помощью ботнета Mirai была проведена массовая DDoS-атака на камеры видеонаблюдения производства Xiaomi во Вьетнаме и Бразилии. Все эти камеры имели стандартный пароль администратора; с помощью сканирования IPv4 можно было захватить камеры и использовать их в DDoS-атаках. Это стало стандартной схемой работы Mirai: с тех пор было выпущено несколько сотен версий ботнета для подобных уязвимостей. История получила большой резонанс: таможня в США и Европе разворачивала целые контейнеры с IoT-устройствами, которые могли быть уязвимы.

Эта и ряд других историй (например, атака на правительственные агентства США с помощью ПО SolarWinds в 2019–2020 гг.) поднимают вопрос о проверке поставщиков ПО. Раньше было достаточно проверить финансовую информацию за последние три года и посмотреть приятные глазу презентации. Сейчас же нужна более тщательная процедура, и не все на это готовы.

Стандартизация отраслей

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

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

С автомобилями все сложнее. В обычной машине предусмотрено порядка 10 беспроводных интерфейсов на разных частотах. Есть своя SIM-карта для взаимодействия с мобильной сетью, есть Bluetooth. Есть как минимум две частоты для доступа без ключа (для входа и выключения сирены). Атака может произойти через каждый из этих сервисов. После проникновения атаке подвергается софт — уязвимо даже простейшее ПО, соединяющее модули беспроводной связи с «мозгами» машины. Никто не заинтересован в интеграционных тестах, и подобные система становятся легкой мишенью.

Создание описательной базы ПО

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

Стоимость поддержки софта

Мы немного отвлеклись от основной темы. Вернемся к примеру из начала поста. Люди хотят себе новый холодильник, который прослужит 10 или 20 лет без каких-либо ограничений. Вы, как производитель холодильников, можете купить софт для своих устройств у какой-нибудь компании. Тогда вам нужно очень осторожно все оценивать и обсуждать. Либо вы можете использовать опенсорсный проект, и если с ним что-то пойдет не так, вы сможете подключить к нему своих специалистов и исправить ситуацию. К счастью, история IT развивается так, что в любой отрасли, которой угрожает монополист, неизменно появляется игрок, использующий открытый исходный код.

Оба этих варианта стоит оценивать при планировании жизненного цикла ПО. Частая ошибка здесь — это не учитывать весь срок поддержки. Двоюродный брат моей жены делает в Индии всякие мелкие запчасти для машин — контроллеры лобового стекла, дворников и т.п. Выпуская что-то подобное, нужно помнить, что после выпуска ваше устройство сначала будет 3 года в режиме R&D, потом семь лет в составе автомобилей в шоурумах. И еще 10 лет вы должны будете поддерживать на нем софт. Этот пример справедлив для автомобильной отрасли Европы, но и в других отраслях есть подобные требования.

Исходя из этого, задумайтесь, на каком языке вы будете писать софт. Лет 20 назад вы бы наверняка остановились на Java. Сейчас эта идея так себе, потому что у Oracle начались проблемы с оплатой лицензий. Вы могли бы сказать: давайте писать на прекрасном языке C++. Сейчас же, в том числе из-за проблем  с безопасностью C++, люди все-таки ориентируются на такие языки, как Rust, Golang, C# и т. д.  Уверены ли вы, что через 20 лет Rust все еще будет развиваться? Если вы собираетесь все делать самостоятельно, то оценивайте все и с точки зрения собственной экспертности. На что вы сделаете ставку в карьере? Rust? Java?

Недавно я общался с главным разработчиком Github Copilot — AI-помощника для разработки. Я спросил, будут ли они добавлять в AI возможность писать на устаревших языках типа Cobol. Он ответил уклончиво: может быть, будет в будущих релизах. Если у нас все равно будет такой помощник, может, и выбор языка не имеет значения? Нет, язык все-таки важен; пока вы не научитесь хорошо в нем ориентироваться, вы не сможете его поддерживать на должном уровне.

AI-помощники могут помочь, да и в случае устаревания стека к вашим услугам есть целый рынок, который зарабатывает на поддержке старого софта. Micro Focus заработал немало на инструментах поддержки Cobol — это одна из самых успешных историй на IT-рынке Британии за последние годы. Но есть и печальные примеры: банк NatWest, входящий в топ-5 страны, был почти уничтожен, потому что передал поддержку мейнфреймов IBM на аутсорс индийской компании, которая убедила клиента, что имеет соответствующую экспертизу. Один мой знакомый, работавший в банке, после инцидента ушел на пенсию и переехал в пустыню в Израиле. Если тогда ты приходил в NatWest, чтобы снять сто фунтов, тебе выдавали купюру и делали запись на бумажке. Так продолжалось примерно 10 дней, пока не восстановили мейнфреймы. Знание того, как работает местный финтех, убеждает меня держать деньги в разных банках.

Много открытых вопросов

Подведу итог. Сегодня мы имеем две схемы создания устойчивых в долгосрочной перспективе продуктов. Есть автомобили, которые не подсоединены к интернету, и поэтому мы тестируем их многократно вдоль и поперек. Есть смартфоны, которые безопасны, потому что обновления приходят каждый месяц. Но смартфон на Android остается безопасным только год-два, а потом на него перестают выходить обновления. С iPhone этот срок может растянуться до пяти лет.

А что, если вы начнете подключать к интернету свою машину? Тогда, если она будет иметь уязвимость, ее смогут использовать удаленно, чтобы спровоцировать аварию. Так что придется обновлять софт каждые 3–6 месяцев. Кто должен это регулировать? Кто будет требовать от производителей обновлять, например, софт радионянь, чтобы к девайсу вашего ребенка не подключился какой-нибудь извращенец?

Проанализировав эти опасности, в Евросоюзе установили два года как минимальный срок обновления софта для всех продаваемых устройств. Для холодильников, стиральных машин и автомобилей добились 10-летней поддержки. Сейчас идет полемика вокруг Android-смартфонов — для них добиваются 5-летнего срока обновления. Другими словами, хотят от Samsung такого же отношения к пользователям, как у Apple.

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