Google заявляет, что ее усилия по приоритизации разработки безопасного для памяти программного обеспечения за последние шесть лет существенно сократили количество уязвимостей безопасности памяти в ее операционной системе Android.
В отчете, публикация которого запланирована на среду, Google сообщает, что процент уязвимостей Android, связанных с проблемами безопасности памяти, снизился с 76 процентов в 2019 году до ожидаемых 24 процентов к концу 2024 года, что значительно меньше отраслевой нормы в 70 процентов.
Это существенное снижение профиля риска кода Android, которое член команды по безопасности Android Джефф Вандер Ступ и старший инженер-программист Google Алекс Реберт связывают с принятием безопасного кодирования — набора методов разработки программного обеспечения, которые пытаются избежать появления уязвимостей с помощью языков программирования, безопасных для памяти, включая Rust, статический анализ и проектирование API.
Команда Android заметила, что скорость отката изменений Rust составляет менее половины от C++
«Переход от предыдущих поколений к безопасному кодированию можно увидеть в количественной оценке утверждений, которые делаются при разработке кода», — говорят Вандер Стоп и Реберт.
«Вместо того чтобы сосредотачиваться на применяемых вмешательствах (смягчение последствий, фаззинг) или пытаться использовать прошлые показатели для прогнозирования будущей безопасности, безопасное кодирование позволяет нам делать строгие утверждения о свойствах кода и о том, что может или не может произойти на основе этих свойств».
Разработка программного обеспечения на языках программирования, безопасных для памяти, таких как C#, Go, Java, Python и Swift, а также Rust, является важной частью безопасного кодирования. Ошибки безопасности памяти, такие как переполнение буфера, представляют собой большинство серьезных уязвимостей безопасности в больших кодовых базах, и это осознание привело к широкому движению в государственном и частном секторе, чтобы создавать меньше ошибок безопасности памяти.
В основном эта цель достигалась путем рекомендации не использовать C и C++, которые требуют ручного управления памятью и приводят к уязвимостям памяти, если разработчики не проявляют особой старательности. (Это не ускользнуло от внимания сообщества C/C++, где безопасность памяти также стала приоритетом.)
Для Google международный крестовый поход за безопасность памяти означал больше разработок в Rust для Android среди других проектов, который предоставляет гарантии безопасности памяти без ущерба для производительности, по крайней мере, большую часть времени. И это повысило производительность.
«Безопасное кодирование улучшает корректность кода и производительность разработчиков, сдвигая поиск ошибок еще дальше влево, еще до того, как код будет проверен», — говорят Вандер Стоп и Реберт.
«Мы видим, что этот сдвиг проявляется в таких важных показателях, как показатели отката (аварийный возврат кода из-за непредвиденной ошибки). Команда Android заметила, что показатель отката изменений Rust составляет менее половины показателя C++».
Хорошей новостью для организаций с большим количеством небезопасного устаревшего кода является то, что переписывание старого кода на новых языках, вероятно, не является необходимым. Как отмечают Вандер Стоеп и Реберт, уязвимости имеют период полураспада — они со временем исчезают по мере развития кода. «Например, исходя из среднего времени жизни уязвимостей, 5-летний код имеет в 3,4 раза (используя время жизни из исследования) до 7,4 раз (используя время жизни, наблюдаемое в Android и Chromium) меньшую плотность уязвимостей, чем новый код», — заявили они.
Это не значит, что старые ошибки чудесным образом становятся неэксплуатируемыми. Скорее, общая плотность уязвимостей уменьшается — статистический выигрыш, но не гарантия безопасности.
Несмотря на это, сосредоточившись на том, чтобы сделать старый код совместимым с безопасным для памяти кодом и написав новый код на безопасных для памяти языках, естественная скорость распада существующих уязвимостей имеет тенденцию делать большие кодовые базы безопаснее с течением времени без обременительного пересмотра кода. Если вы перестанете делать новые ошибки безопасности памяти, старые ошибки станут менее серьезной проблемой, по крайней мере в совокупности.
«Внедрение безопасного кодирования в новом коде предлагает смену парадигмы, позволяя нам использовать неотъемлемое ослабление уязвимостей в наших интересах, даже в крупных существующих системах», — говорят Вандер Стоп и Реберт.
«Концепция проста: как только мы перекрываем кран новых уязвимостей, они уменьшаются экспоненциально, делая весь наш код более безопасным, повышая эффективность проектирования безопасности и облегчая проблемы масштабируемости, связанные с существующими стратегиями безопасности памяти, так что их можно применять более эффективно и целенаправленно». ®