В первую неделю ноября 2026 года индустрия открытого программного обеспечения и информационной безопасности столкнулась с прецедентом, меняющим базовые оценки защищённости операционных систем. Американская компания OpenAI опубликовала отчёт о масштабном автономном аудите основной ветки ядра Linux, проведённом мультиагентной системой на базе специализированной модели кибербезопасности следующего поколения. Результаты эксперимента, подробно разобранные профильным порталом Phoronix, о которых также выпустили заметки SecurityWeek и редакция D-Russia, ошеломили сообщество разработчиков: из 2308 выявленных подозрительных участков кода система автоматически подтвердила воспроизводимость 1724 сбоев и сгенерировала 948 уникальных работающих эксплойтов для локального повышения привилегий до уровня суперпользователя (администратора системы).
Речь идёт вовсе не о теоретических предупреждениях статического анализатора и не о рядовых отказах в обслуживании ядра, требующих экзотических условий запуска. Все 948 сценариев атак успешно преодолели штатные аппаратные и системные рубежи защиты современного ядра Linux для процессоров архитектуры x86-64 – случайное размещение адресного пространства ядра в памяти (KASLR), запрет исполнения ядром пользовательского кода и прямого обращения к памяти пользовательских программ в привилегированном режиме, а также механизм жёсткой проверки копирования буферов данных. Более того, в ходе автономного анализа алгоритм самостоятельно открыл десять принципиально новых, по оценке авторов исследования ранее не описанных в научной литературе способов взлома – включая целенаправленное заполнение кэша ядра и перехват управления исключительно через подмену системных структур данных, без внедрения собственного вредоносного кода.
При этом себестоимость всей исследовательской кампании оказалась удивительно скромной. На полный сквозной цикл сканирования, верификации и генерации боевых эксплойтов ушло около 1,21 миллиона долларов при оплате обращений к модели по стандартному программному интерфейсу (API). В пересчёте на один готовый эксплойт уровня root (суперпользователя) общие затраты составили около 1280 долларов – сумму, сопоставимую со стоимостью обычного рабочего ноутбука. Отчёты о выявленных уязвимостях и сгенерированные машиной программные исправления были заблаговременно направлены ведущим инженерам, отвечающим за сопровождение ядра Linux, но сам факт публикации подвёл черту под целой эпохой в развитии информационных технологий.
Миф о врождённой неуязвимости открытого исходного кода рухнул за одни осенние выходные. И главный вызов здесь адресован в первую очередь тем государствам и ведомствам, где безопасность критической информационной инфраструктуры годами строилась на процедурах многомесячной «бумажной» сертификации застывших версий свободного ядра…
Анатомия пятиступенчатого конвейера – как машина обошла десятилетия человеческого аудита
Чтобы понять масштаб произошедшего, необходимо ответить на простой инженерный вопрос. Почему эти сотни критических уязвимостей десятилетиями оставались невидимыми для мирового сообщества разработчиков? Ведь ядро Linux исследуется непрерывно. Корпорация Google много лет финансирует распределённую систему непрерывного тестирования syzkaller, генерирующую миллионы случайных системных вызовов в сутки, а ведущие мировые и российские лаборатории регулярно прогоняют исходные коды через мощнейшие статические анализаторы вроде Coverity, отечественного комплекса Svace или Clang Static Analyzer.
Ответ кроется в принципиальной разнице между классическим поиском программных ошибок и семантическим машинным синтезом цепочек эксплуатации. Традиционный инструментальный фаззинг (автоматизированное тестирование ПО – ред.) ориентируется лишь на покрытие веток кода и действует механически – он перебирает входные параметры системных вызовов в надежде спровоцировать аварийную остановку ядра (kernel panic). Статический анализ заваливает инженеров десятками тысяч предупреждений о потенциально опасных конструкциях, но подавляющее большинство этих сигналов на практике оказывается ложными срабатываниями.
Агентная система OpenAI пошла принципиально иным путём, развернув замкнутый пятиступенчатый исследовательский конвейер:
- На первом этапе, при картировании поверхности атаки и поиске уязвимостей, агенты-разведчики сузили кодовую базу ядра до 5034 целевых участков кода вокруг точек входа, доступных непривилегированному пользователю – это около 2,8 миллиона строк кода, или примерно 7% всего объёма ядра. Затем агенты-аналитики всего за 12 часов выявили в этом массиве 2308 потенциальных уязвимостей: неочевидные состояния гонки (race conditions) при одновременном доступе разных потоков к памяти, ошибки обращения к уже освобождённой памяти (use-after-free), выходы за границы буфера (out-of-bounds) и нарушения целостности счётчиков ссылок.
- На втором шаге проводилась динамическая валидация в изолированных виртуальных машинах. Система автоматически разворачивала целевые сборки ядра Linux со встроенными инструментами автоматического контроля памяти внутри изолированных виртуальных машин. Всего за 30 часов из сформированного списка в 2308 подозрительных участков кода конвейер автоматически воспроизвёл 1724 реальных сбоя – доля подтверждённых находок составила 74,7%, причём лишь в 3,1% случаев неподтверждённые гипотезы объяснялись логическими промахами самой модели.
- Третий и самый впечатляющий шаг конвейера – синтез боевых эксплойтов и анализ вариантов. На стандартной защищённой сборке ядра со всеми включёнными механизмами самозащиты агенты синтезировали 291 рабочий прототип утечки адресов памяти для обхода защиты KASLR и создали 1169 работающих эксплойтов повышения привилегий. После автоматического анализа вариантов и отсева дубликатов, эксплуатирующих одну и ту же первопричину разными путями, было выделено 948 уникальных боевых эксплойтов, модифицирующих системные структуры полномочий процесса и выдающих полный root-доступ.
- На четвёртом этапе выполнялись синтез исправлений и регрессионная проверка. Для каждой из 948 уникальных уязвимостей система автоматически подготовила проекты исправлений исходного кода – патчи, после чего повторно скомпилировала ядро и прогнала собственный эксплойт заново, проверяя устранение уязвимости и сохранность базовой работоспособности подсистемы.
- На завершающем, пятом этапе проводились экспертная верификация и координированное раскрытие – профильные специалисты проверили полученные артефакты и в рамках совместной публичной инициативы OpenAI и компании Trail of Bits Patch the Planet передали отчёты вместе с готовыми патчами ответственным разработчикам и кураторам подсистем ядра Linux.
Перед нами принципиально новый класс систем – полностью автономный цифровой исследователь кибербезопасности, обладающий квалификацией элитного специалиста по низкоуровневой разработке эксплойтов. Команда живых программистов могла безуспешно биться над подобной задачей месяцами, но алгоритм распутывает многоуровневую логическую цепочку между тремя независимыми подсистемами ядра за считанные минуты.
Крах «закона Линуса» и тридцать лет иллюзии открытого кода
В 1999 году издательство O’Reilly выпустило знаменитую программную книгу Эрика Рэймонда «Собор и базар» (выросшую из его одноимённого доклада мая 1997 года на профильной конференции по Linux в баварском Вюрцбурге), где был сформулирован главный постулат эпохи свободного программного обеспечения: «При достаточном количестве глаз все ошибки лежат на поверхности» (Given enough eyeballs, all bugs are shallow). В честь создателя ядра Linux это утверждение вошло в историю как «закон Линуса».
В самой книге 1999 года – куда помимо заглавного эссе вошли работы «Освоение ноосферы» и «Волшебный котёл» – Рэймонд подвёл под этот тезис целостную социально-экономическую базу. В «Волшебном котле» он доказывал корпорациям, что закрывать исходный код ради «безопасности через неясность» (security through obscurity) бессмысленно: пока поиск уязвимостей остаётся ручным человеческим ремеслом, у мирового сообщества защитников суммарно всегда больше глаз и человеко-часов, чем у любого отдельно взятого злоумышленника. Корпорации вроде Red Hat, IBM, Intel и Google десятилетиями продавали открытое программное обеспечение бизнесу и государственным структурам под соусом этого коллективного численного перевеса, но реальность ноября 2026 года перевернула уравнение Рэймонда с ног на голову.
Что же показал эксперимент OpenAI?
Во-первых, рухнула базовая экономическая аксиома «Волшебного котла». Когда атакующая сторона получает возможность арендовать «на выходные» вычислительный кластер за миллион долларов и запустить на нём рой специализированных моделей, у одного атакующего за несколько десятков часов оказывается больше «внимательных глаз», чем у всего мирового сообщества разработчиков за двадцать с лишним лет. В этих условиях щит «коллективной верификации» для открытого исходного кода перестаёт работать, а открытый репозиторий превращается в подробно размеченную топографическую карту для атакующего алгоритма.
Во-вторых, обнажился фундаментальный изъян самой монолитной «базарной» архитектуры, о котором вскользь предупреждал ещё сам Рэймонд. Напомним, что ещё в 1992 году в знаменитом споре с Линусом Торвальдсом профессор Эндрю Таненбаум указывал: сваливать все драйверы, файловые системы и сетевые протоколы в единое привилегированное адресное пространство монолитного ядра – это стратегическая ловушка. И не случайно корпорация Apple при создании macOS и iOS пошла иным путём, положив в основу своего гибридного ядра XNU концепции микроядерной архитектуры Mach и вынеся критические контуры безопасности в аппаратно изолированные среды, а в России последовательную ставку на строгое микроядро с разделением доменов сделала «Лаборатория Касперского» в платформе KasperskyOS. Сегодня же репозиторий ядра Linux разросся до колоссального программного монолита около 40 миллионов строк кода на языках Си и Rust, где все включённые в сборку подсистемы, старые драйверы и сложнейшие механизмы синхронизации памяти работают в общем привилегированном пространстве (ring 0). При этом сам Рэймонд признавал, что при большой базе соразработчиков проблему быстро локализует толпа, но вот проверять и вливать исправления в основную ветку всё равно обязана горстка ведущих разработчиков, отвечающих за сопровождение ядра. Специалистов, способных квалифицированно выверять такие патчи, на всей планете от силы несколько сотен человек, а критические подсистемы годами ведут двое-трое перегруженных кураторов.
В эссе «Освоение ноосферы» Рэймонд справедливо отмечал, что эти ведущие инженеры проверяют поток чужого кода ради профессионального авторитета и признания в «культуре дарения» (gift culture), где статус разработчика определяется его бескорыстным вкладом в общее дело. Но когда машина за один автономный прогон вываливает на стол кураторам подсистем 948 сложнейших эксплойтов и столько же автоматически сгенерированных патчей, «базар» мгновенно захлёбывается в собственном узком горлышке. Живой эксперт физически не способен со скоростью конвейера проверять тысячи нейросетевых заплаток, ошибка в которых грозит взаимными блокировками ядра или порчей данных, никакого престижа в работе ассенизатором за ИИ-фаззером больше нет, а сказать этому «волшебному котлу» формулу «Горшочек, не вари» из выросшей на той же легенде поздней сказки братьев Гримм просто некому.
В-третьих, концепция «базара» изначально строилась на ошибочном отождествлении числа программистов с числом тестировщиков и аудиторов безопасности. Закон больших чисел здесь не работает, а математическое ожидание выявления ошибки не вычисляется простым средним арифметическим – подавляющее большинство участников открытой разработки пишет новый функционал, а сам Линус Торвальдс годами публично отказывался выделять уязвимости в особую категорию, приравнивая их к рядовым ошибкам и не скрывая пренебрежения к специалистам по безопасности. В итоге среди огромной массы контрибьюторов реальным поиском брешей занимаются единицы, а присылаемые извне патчи безопасности нередко отклоняются или месяцами лежат без движения из-за отсутствия к ним интереса у кураторов веток. Нагляднее всего этот парадокс подтвердил российский опыт – когда на базе Института системного программирования имени В.П. Иванникова РАН заработал Центр верификации ОС Linux, относительно небольшая команда отечественных исследователей стандартными методами статического анализа и верификации сразу же начала сотнями находить в ядре ошибки, годами ускользавшие от «всевидящего» мирового сообщества.
Сотни уязвимостей, которые искусственный интеллект выявил за 12 часов анализа и подтвердил за 30 часов работы в виртуальных машинах, дремали в кодовой базе ядра годами. Как показал статистический разбор истории коммитов ядра Linux, проведённый руководителем проекта самозащиты ядра Linux Кисом Куком и прослеживающий возраст уязвимостей вглубь истории репозитория вплоть до апреля 2005 года, опасные уязвимости живут в ядре незамеченными в среднем от пяти до шести с лишним лет, а печально знаменитые ошибки повышения привилегий вроде уязвимости Dirty COW (CVE-2016-5195) кочевали из релиза в релиз по девять–десять лет. Открытость текста программы сама по себе не гарантирует защищённости, когда скорость и глубина машинного анализа на два порядка превосходят пропускную способность человеческого сообщества.
Экономика zero-day в руинах – арсенал спецслужб по цене рабочего ноутбука
До недавнего времени мировая экосистема информационной безопасности держалась на хрупком экономическом балансе. Разработка надёжного, боевого эксплойта уровня ядра с гарантированным обходом штатных механизмов аппаратной и системной защиты была штучной, ювелирной работой – искусством единичных исследователей.
На закрытом рынке кибероружия – у специализированных западных компаний-посредников вроде Zerodium или Crowdfense, которые легально скупают у исследователей сведения о неизвестных разработчикам брешах для перепродажи разведслужбам и оборонным ведомствам, – рабочий эксплойт локального повышения привилегий в ядре Linux оценивался в диапазоне от ста до трёхсот тысяч долларов. Подготовка подобной атаки требовала от исследователя трёх-шести месяцев кропотливого ручного труда – обратного инжиниринга, отладки в ассемблере, подбора структур ядра и сотен часов экспериментов на физических тестовых стендах. Столь высокий финансовый и интеллектуальный порог входа долго служил естественным барьером, но в ноябре 2026 года этот экономический рубеж испарился. Уязвимости нулевого дня (zero-day) для ядра Linux перестали быть эксклюзивным арсеналом спецслужб и крупных группировок целевых атак (APT), располагающих миллионными бюджетами.
Когда общая себестоимость уникального root-эксплойта опускается до 1 280 долларов (а непосредственно синтез боевого эксплойта по подтверждённому сбою обходится в среднем всего в 359 долларов), рынок торговли уязвимостями нулевого дня теряет прежний экономический смысл. Любая криминальная группировка средней руки, обладающая доступом к арендованным серверам с современными ускорителями вычислений или корпоративному аккаунту нейросетевых моделей, получает возможность штамповать боевые цепочки атак промышленным способом.
Возникает критическая асимметрия нападения и защиты:
| Параметр | Традиционная разработка эксплойта человеком | Автономный конвейер ИИ-фаззинга (OpenAI, 2026 г.) |
|---|---|---|
| Время поиска и создания цепочки | 3–6 месяцев исследовательской работы команды | 12 часов на поиск кандидатов и 30 часов на верификацию 1724 сбоев (вся кампания с разбором – 10 дней) |
| Себестоимость одного root-эксплойта | 100 000 – 300 000 долларов США | Примерно 1280 долларов США общих затрат (359 долларов на этап синтеза эксплойта) |
| Объём арсенала за один прогон | 1–2 штучные уязвимости под конкретный релиз | 948 уникальных верифицированных эксплойтов (из 1169 эксплойтов повышения привилегий) |
| Устойчивость к механизмам защиты | Высокая (требует ручной адаптации под ядро) | Полный автоматический обход штатных аппаратных и системных механизмов защиты ядра |
| Скорость генерации исправлений | Недели и месяцы обсуждений в списках рассылки | Автоматический синтез и проверка патча в рамках единого автономного цикла |
Атакующая сторона получает подавляющее преимущество в скорости. Сообщество защитников пытается в ручном режиме разобрать почти тысячу полученных отчётов, но злоумышленники могут с лёгкостью направить аналогичную модель на специализированные ветки ядра, проприетарные модули или специфические дистрибутивы, создавая лавину направленных атак быстрее, чем выходят ежемесячные бюллетени безопасности.
Сертификационный тупик – почему «бумажное доверие» превратилось в мишень
Теперь перенесёмся из глобального контекста в российскую действительность. Как эта технологическая революция отражается на национальной безопасности и суверенитете отечественной критической информационной инфраструктуры?
В рамках государственной программы импортозамещения последних десяти лет ядро Linux де-факто стало безальтернативным фундаментом технологической независимости страны. Именно на ядре Linux построены все основные операционные системы, включённые в Единый реестр российского программного обеспечения по постановлению правительства РФ от 16 ноября 2015 г. № 1236 – Astra Linux («Группа Астра»), ОС «Альт» («Базальт СПО»), «РЕД ОС» («РЕД СОФТ»), «РОСА Линукс» («НТЦ ИТ РОСА») и мобильная система «Аврора» («Открытая мобильная платформа»). А уже под управлением этих операционных систем работают серверы государственных информационных систем, центры обработки данных крупнейших банков, технологические контуры промышленных предприятий, суперкомпьютерные кластеры и узлы телекоммуникационных сетей.
Как же государство до сегодняшнего дня выстраивало проверку защищённости этих систем?
Сам по себе статус отечественного продукта в базовом реестре по постановлению № 1236 подтверждает лишь его российское происхождение и исключительные права правообладателя. Предусмотренный во исполнение федерального закона № 58-ФЗ перечень доверенного российского ПО (постановление правительства РФ от 28 ноября 2025 г. № 1931) до сих пор не заработал (и в задуманном виде вряд ли когда-нибудь полноценно заработает), да и по своей сути он сводится лишь к предоставлению закупочного преимущества в рамках национального режима по постановлению правительства РФ от 23 декабря 2024 г. № 1875. Поэтому реальная проверка защищённости операционных систем для значимых объектов КИИ (по приказу ФСТЭК России от 25 декабря 2017 г. № 239) и государственных информационных систем (по приказу ФСТЭК России от 11 апреля 2025 г. № 117) строится на процедуре сертификации во ФСТЭК России по Положению о системе сертификации средств защиты информации (приказ ФСТЭК России от 3 апреля 2018 г. № 55) и Требованиям к уровням доверия (приказ ФСТЭК России от 2 июня 2020 г. № 76).
Посмотрим, как работает этот сертификационный контур на практике. Разработчик операционной системы формирует релиз дистрибутива на базе долгосрочной ветки ядра (Long Term Support – LTS 5.10, LTS 5.15 или LTS 6.1) и по Требованиям к уровням доверия передаёт исходные тексты в аккредитованную испытательную лабораторию вместе с результатами собственного статического, динамического и фаззинг-анализа. При этом сама лаборатория работает по прямому коммерческому договору с заявителем, и поскольку обе стороны объективно заинтересованы ещё и в существенном ускорении работ по сертификации, стремление выявлять сотни глубоких уязвимостей представляет собой блокирующий фактор для быстрого завершения испытаний.
Финалом этой экспертной и документальной работы становится сертификат соответствия и утверждённый формуляр изделия. В формуляре жёстко фиксируются контрольные суммы дистрибутива и исполняемых файлов, включая само ядро, а отдельно оформляется перечень всех заимствованных компонентов с открытым кодом, причём заказчик вправе бессрочно использовать сертифицированный экземпляр ОС, произведённый в период действия сертификата, пока вендор оказывает техническую поддержку.
И вот здесь при столкновении с машинным синтезом эксплойтов возникает опаснейшая нормативно-техническая ловушка:
- В действующих регламентах ФСТЭК России порядок внесения изменений в сертифицированное средство защиты информации (приказ № 55) уже допускает ускоренный контур: правила разрешают вендору рассылать патчи безопасности заказчикам до завершения испытаний и проводить испытания обновлений самостоятельно, без внешней лаборатории, при наличии у разработчика сертификата соответствия процессов безопасной разработки (РБПО) по ГОСТ Р 56939-2024 (приказ ФСТЭК России от 1 декабря 2023 г. № 240). Однако эта процедура остаётся добровольной – без сертификата по приказу № 240 разработчик обязан проводить испытания каждого обновления, затрагивающего функции безопасности, через аккредитованную испытательную лабораторию и орган по сертификации.
- Возникают жёсткие ножницы нормативных сроков – по Требованиям к уровням доверия (приказ ФСТЭК № 76) разработчику отводится 48–72 часа только на рассылку уведомления и компенсирующих мер и до 60 суток на выпуск самого обновления безопасности. В то же время от оператора значимого объекта КИИ новая Методика оценки уровня критичности уязвимостей ФСТЭК России (от 30 июня 2025 г.) требует устранить критическую уязвимость за 24 часа, но перед установкой любого патча для открытого ПО обязывает провести его предварительное тестирование по методике регулятора.
- Наконец, сохраняется бумажно-формулярная инерция – в редакции приказа ФСТЭК от 20 января 2026 г. № 9 при любом изменении состава заимствованных компонентов с открытым кодом изготовитель обязан за пять календарных дней подать скорректированный перечень под угрозой приостановки сертификата. И хотя январский приказ № 9 перевёл подачу протоколов испытаний и перечней открытых компонентов в чисто электронный вид, само техническое заключение, изменения технических условий и извещения об изменении формуляра с новыми контрольными суммами по-прежнему подаются во ФСТЭК России на бумажном носителе в двух экземплярах с двадцатидневным сроком рассмотрения. В сочетании с правом бессрочного использования ранее выпущенных экземпляров СЗИ это побуждает заказчиков КИИ годами держаться за сертифицированные базовые ветки ядер LTS.
В прошлом, когда поиск уязвимостей вёлся людьми вручную, эта модель худо-бедно работала за счёт общей медлительности ручной киберразведки. Но против автономного ИИ-фаззинга статическая фиксация базовых ядер превращается в идеальную мишень.
Что мешает вероятному противнику загрузить исходные коды конкретной базовой версии сертифицированного отечественного ядра (например, общедоступной долгосрочной ветки ядра 5.15 или 6.1 с наложенными специфическими модулями) в собственный закрытый конвейер фаззинга? За тридцать часов вычислений и пару тысяч долларов противник получает пакет из десятков гарантированно работающих эксплойтов уровня суперпользователя, созданных точно под те сборки и контрольные суммы ядра, которые зафиксированы в формулярах и применяются в контурах КИИ.
При этом службы безопасности внутри периметра значимых объектов КИИ оказываются зажаты между алгоритмической атакой и собственными регламентами – между требованием закрыть критическую брешь за 24 часа и обязанностью дождаться официального пересобранного обновления с проверенным формуляром. «Бумажное доверие», сведённое к проверке наличия сертификата или реестровой записи, превратилось в опасную иллюзию безопасности – с таким документом организация без труда закрывает отчётность перед проверяющими комиссиями, но на практике остаётся беззащитной перед алгоритмической атакой.
От бумажного формуляра к непрерывной защите – три шага для отечественного ПО
С появлением автономного ИИ-фаззинга прежняя модель разовой сертификации перестала справляться со скоростью угроз, и перед российскими регуляторами и разработчиками встаёт задача стратегического масштаба. Защититься от алгоритмических атак двадцать первого века методами бумажного документооборота середины века двадцатого уже не выйдет.
Нам необходимо признать простую истину: защищённость операционной системы больше не может обеспечиваться разовой выдачей сертификата соответствия и фиксацией контрольных сумм в согласованном формуляре (паспорте) на средство защиты информации. При появлении автономного искусственного интеллекта безопасность становится непрерывным инженерным процессом, где главным критерием защищённости становится время реакции от обнаружения уязвимости до доставки проверенного исправления.
Чтобы перестроить защиту отечественных платформ под скорости машинного анализа, регулятору и отечественной индустрии предстоит сделать три неотложных шага.
1. Модернизация регламентов сертификации ФСТЭК России и переход к модели непрерывного доверия
Прежде всего необходимо в полной мере задействовать то, что уже предусмотрено в действующем режиме, и сделать этот порядок обязательным для всех базовых операционных систем, сертифицируемых как средства защиты информации. Правовая основа для ускоренного выпуска исправлений уже создана в приказах ФСТЭК России № 240 и № 55 – это сертификация процессов безопасной разработки (РБПО) по ГОСТ Р 56939-2024, которая даёт вендору право самостоятельно проводить испытания патчей безопасности и оперативно направлять их заказчикам без ожидания сторонней лаборатории. Для разработчиков операционных систем и средств виртуализации, сертифицируемых во ФСТЭК России для значимых объектов КИИ и государственных информационных систем, наличие сертифицированного конвейера безопасной разработки по приказу № 240 должно стать обязательным базовым условием.
Следующий шаг – довести до конца начатый в январе 2026 года перевод процедур ФСТЭК России в цифровой формат под скорости машинного анализа. Приказом № 9 регулятор уже перевёл в электронный вид протоколы испытаний и перечни заимствованных компонентов, но для технических заключений и извещений об изменении формуляров с контрольными суммами по-прежнему требуется подача бумажных экземпляров с двадцатидневным рассмотрением. Эту бумажную ступень целесообразно полностью заменить автоматизированной передачей машиночитаемых уведомлений об обновлении контрольных сумм. Одновременно назрела синхронизация 60-суточного норматива выпуска обновлений для разработчиков по приказу № 76 с 24-часовым требованием по устранению критических уязвимостей для операторов систем по Методике ФСТЭК России от 30 июня 2025 года, а также прямая легализация в регламентах ФСТЭК России технологий сквозного обновления ядра «на лету» без перезагрузки серверов (live-patching), чтобы оперативное закрытие уязвимости в оперативной памяти не нарушало статус сертифицированного изделия. Впрочем, для промышленных контуров и систем АСУ ТП, где работа оборудования жёстко завязана на специфические драйверы, даже ускоренный выпуск патчей не станет универсальным решением – конечные потребители зачастую не могут оперативно вносить изменения в ядро из-за известной проблемы нарушения совместимости при обновлении исходного кода и риска аварийных сбоев при патчинге «на лету».
2. Создание национальной суверенной «фабрики» опережающего ИИ-фаззинга и смена модели финансирования испытаний
Всё описанное выше в части сертификации касается только средств защиты информации (СЗИ). Так устроены документы ФСТЭК России: если отечественная операционная система из реестра не сертифицирована во ФСТЭК России и не является СЗИ, то требования приказов № 55, № 76 и № 240 к ней вообще не предъявляются, и никакой формуляр с контрольными суммами у такой операционной системы никто проверять не будет. Между тем и сертифицированные сборки, и обычные реестровые дистрибутивы строятся на одних и тех же базовых ядрах Linux, поэтому, когда ведущие американские лаборатории разворачивают конвейеры поиска эксплойтов на своих закрытых моделях, нашей стране необходим собственный инструмент опережающего анализа кода.
Речь идёт о создании общеотраслевой «фабрики» непрерывного ИИ-фаззинга и верификации свободного программного обеспечения. Фундаментом для такой инициативы должен стать Институт системного программирования имени В.П. Иванникова РАН (ИСП РАН) и действующий на его базе Центр верификации ОС Linux, накопивший уникальные компетенции в области статического анализа кода, семантического разбора и развития ядра Linux в рамках профильного консорциума. К этой работе должны быть напрямую подключены ведущие отечественные разработчики операционных систем – «Группа Астра», «Базальт СПО», «РЕД СОФТ», «НТЦ ИТ РОСА», «Открытая мобильная платформа» – и флагманы практической кибербезопасности в лице Positive Technologies, «Лаборатории Касперского» и BI.ZONE.
При этом необходимо трезво оценивать кадровый масштаб задачи. Выявить в ядре тысячу ошибок с помощью искусственного интеллекта – лишь полдела, тогда как квалифицированно устранить такую лавину уязвимостей своими силами без разрушения работоспособности системы несопоставимо сложнее. Во всей российской отрасли, включая совокупные команды всех отечественных разработчиков операционных систем, настоящих архитекторов ядра насчитываются буквально единицы и десятки, поэтому ни один вендор в одиночку физически не способен тянуть и сопровождать такую самостоятельную ветку ядра. Только объединённый консорциум вокруг ИСП РАН позволит сконцентрировать этот штучный кадровый ресурс – суверенная «фабрика» должна непрерывно, в режиме двадцать четыре на семь, прогонять через отечественные специализированные модели кодовые базы используемых в стране ядер, компиляторов и системных библиотек, чтобы находить бреши первыми, совместно выверять защитные патчи и синхронно распространять их по экосистеме отечественных дистрибутивов.
Смена модели финансирования испытаний и мировой опыт – почему за аудит безопасности критического кода должно платить государствоЧтобы уменьшить риски описанной выше контрактной зависимости испытательных лабораторий от проверяемых разработчиков, государству целесообразно изменить сам принцип финансирования сертификационных испытаний и перейти к прямому государственному финансированию независимого аудита и верификации базовых системных платформ.
Проблема коммерческого конфликта интересов при сертификации хорошо известна в мировой истории информационной безопасности. В первоначальной американской системе оценки защищённости по «Оранжевой книге» (TCSEC, 1980–1990-е годы) испытания операционных систем проводил государственный Национальный центр компьютерной безопасности США (NCSC) за счёт федерального бюджета, без какой-либо коммерческой оплаты со стороны вендора. Когда в конце 1990-х годов индустрия перешла к аккредитованным коммерческим лабораториям в рамках «Общих критериев» (Common Criteria), где работу испытателей оплачивает сам заявитель, регуляторы в США и Европе быстро столкнулись с тем, что разработчики выбирают самую «покладистую» лабораторию.
Именно поэтому в последние годы в Германии – через федеральное ведомство BSI и государственный фонд Sovereign Tech Agency, во Франции – через агентство ANSSI для приоритетных решений и в институтах Евросоюза в рамках программ аудита открытого кода EU-FOSSA и FOSSEPS проверку критического свободного ПО и базовых компонентов безопасности вновь перевели на прямое государственное финансирование независимых аудиторов, когда заказчиком и плательщиком выступает государство, а не проверяемый разработчик.
3. Радикальное сокращение поверхности атаки, формальная верификация и изоляция контуров
Наконец, нам пора избавиться от опасной привычки тянуть в сертифицированные дистрибутивы всю необъятную международную кодовую базу ядра без разбора. Полнофункциональное универсальное ядро из многомиллионной кодовой базы оправдано на пользовательских рабочих станциях, но на серверах критической инфраструктуры и в промышленных контроллерах АСУ ТП тысячи лишних модулей и драйверов в привилегированном пространстве суперпользователя создают недопустимый риск.
Отечественным разработчикам и заказчикам необходимо перейти к жёсткой профильной минимизации ядер, математически доказуемым механизмам защиты и глубокому разделению контуров:
- Полное исключение из защищённых сборок устаревших драйверов оборудования, не используемого на объектах КИИ – напомним, что все 948 эксплойтов OpenAI были получены при анализе 5 034 целевых участков кода вокруг точек входа, доступных непривилегированному пользователю, а сокращение кодовой базы одновременно снимет неподъёмную нагрузку с немногочисленных отечественных разработчиков ядра.
- Принудительное отключение или строгая изоляция высокорискованных подсистем ядра, таких как интерфейс асинхронного ввода-вывода io_uring, встроенная виртуальная машина ядра eBPF или непривилегированные пространства имён, в серверных и промышленных сборках, где эти механизмы не требуются для штатной работы.
- Повышение роли формальной верификации кода и математических моделей управления доступом. В условиях, когда открытый код десятилетиями писался тысячами программистов по наитию, с опорой лишь на «чувство прекрасного», только строгие математические подходы – формально верифицированные мандатные модели управления доступом и математическая проверка ключевых инвариантов кода – позволяют добиться уверенности в отсутствии фундаментальных архитектурных и логических ошибок.
- Ужесточение требований к изоляции систем, точек входа и каналов связи при развитии микроядерных архитектур. Там, где оперативная установка патчей невозможна из-за технологических ограничений и привязки к оборудованию – прежде всего в АСУ ТП и критических промышленных контурах, – главным рубежом защиты от уязвимостей нулевого дня становится жёсткая физическая, сетевая и криптографическая изоляция систем и входных шлюзов в сочетании с аппаратными механизмами доверенной среды исполнения (TEE, TrustZone, аппаратные мониторы целостности по образцу платформ Apple) и переходом к микроядерным операционным системам (включая платформу KasperskyOS), архитектурно исключающим захват всей системы через уязвимость в отдельном драйвере.
Эксперимент OpenAI подвёл окончательную черту под романтической эпохой открытого кода, где безопасность наивно измерялась количеством энтузиастов, заглядывающих в репозиторий на выходных. В мире, где алгоритмы за считанные дни синтезируют почти тысячу боевых эксплойтов по 1280 долларов за штуку, защитить критическую инфраструктуру способен только ещё более оперативный и системно выстроенный конвейер упреждающей верификации.
Вопрос сегодня стоит предельно прагматично – успеем ли мы перестроить отечественные процедуры сертификации и создать собственные «фабрики» алгоритмической защиты прежде, чем чужой цифровой конвейер начнёт методично проверять на прочность серверы нашей критической инфраструктуры? Выбор у нас невелик, но сделать его нужно прямо сейчас…