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

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

Ставки уже очевидны. В Соединенных Штатах в 2025 году было зафиксировано 3322 случая утечки данных, что стало рекордным показателем. На кибератаки пришлось 80% из них. Эти цифры не говорят о том, что каждая защита потерпела крах, но они говорят об одном важном факте: добавление новых продуктов безопасности не привело к исчезновению основной проблемы.

Я посвятил десятилетия созданию технологий, и один урок постоянно возвращается: когда система систематически дает сбой в одном и том же месте, добавление еще одного слоя вокруг нее необязательно является прогрессом. Иногда приходится менять границу безопасности.

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

Это порождает другую проблему — информационный шум. Центр управления сетью может получать тысячи оповещений в день. Одни из них являются реальными угрозами, другие — безвредны. Когда защитники не могут надежно их различать, они в конечном итоге сталкиваются с той же проблемой, с которой враги столкнулись на заре тестирования на COVID-19: тест, дающий слишком много ложноположительных результатов, становится менее полезным, даже если лежащая в его основе наука безупречна.

Гораздо правильнее задать вопрос: действительно ли машина делает то, что должна?

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

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

Это кардинально отличается от ситуации, когда мы просим другую программу обнаружить атаку постфактум. Аппаратное обеспечение невозможно удаленно переписать так же легко, как программное. Оно может обеспечить границу безопасности, которая не зависит от идеальности каждой строки кода.

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

Нам отчаянно нужен этот рубеж обороны, поскольку уязвимости безопасности памяти, такие как переполнение буфера, остаются упорно распространенными. По данным CISA, Microsoft сообщала, что примерно 70% ежегодно назначаемых ей идентификаторов CVE связаны с проблемами безопасности памяти, в то время как Google сообщал о схожей доле среди серьезных ошибок безопасности в Chromium. CISA также отмечает,. что эти проблемы сохраняются несмотря на многолетнее применение фаззинга, статичного анализа, «песочниц» и других методов тестирования.

Это приобретает еще большую значимость по мере того, как искусственный интеллект ускоряет обе стороны противостояния. В феврале 2026 года компания Anthropic сообщила, что Claude Opus 4.6 помог выявить и подтвердить более 500 уязвимостей высокой степени тяжести в программном обеспечении с открытым исходным кодом. Тот же потенциал, который дает защитникам беспрецедентную видимость, может дать злоумышленникам беспрецедентную скорость. Anthropic предупредила, что модели ИИ уже способны выявлять новые уязвимости, и традиционного времени, доступного для раскрытия информации и устранения последствий, может оказаться недостаточно.

Отчет Verizon о расследовании утечек данных за 2026 год делает эту необходимость еще более очевидной. Эксплуатация уязвимостей стала главным вектором первоначального доступа, на ее долю пришлось 31% утечек в наборе данных. В отчете Verizon также отмечается, что ИИ помогает злоумышленникам ускорять процесс эксплуатации.

Будущее может развиваться по одному из двух сценариев.

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

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

Мы не должны ждать, пока это мрачное будущее наступит.

Языки с безопасной работой с памятью, лучшие практики разработки, тестирование, патчи и традиционная кибербезопасность — все это имеет значение. Аппаратный надзор не заменяет их. Он обеспечивает для них запасную линию обороны.

Поэтому в следующий раз, когда вы будете оценивать встроенную платформу, подключенное устройство или технологию, управляющую чем-либо в физическом мире, задайте более сложный вопрос, чем «Насколько безопасно это программное обеспечение?» Спросите: «Что следит за процессором, когда программное обеспечение дает сбой?»

Именно к этому кибербезопасность должна прийти в дальнейшем