Меньше кода — меньше дыр: почему приложения на Интеграме безопаснее

В 2025 году в мире опубликовали 48 185 уязвимостей с номером CVE — на 20,6% больше, чем годом раньше, и это новый рекорд (разбор Джерри Гэмблина). Это около 130 новых дыр в день. Ядро Linux с 2024 года само регистрирует свои уязвимости и выпускает их тысячами в год.

Программисты не стали хуже. Просто кода стало больше, и его больше проверяют. А каждый новый слой кода — фреймворк, библиотека, плагин, внутренняя «программка на коленке» — получает права в системе и становится ещё одной дверью внутрь.

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

Где живут дыры: в ядре или вокруг него

Показательный пример — WordPress. По данным Patchstack, в 2025 году в его экосистеме нашли 11 334 новых уязвимости (+42% к 2024-му). Из них 91% — в плагинах, 9% — в темах оформления. На само ядро WordPress пришлись единицы, и все низкой важности.

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

В корпоративной ИТ картина та же. Операционную систему и СУБД поставщик закрывает обновлениями. Но вокруг них — десятки внутренних приложений, скриптов выгрузки, интеграций и учётных систем «от подрядчика». У каждого свой фреймворк, свои зависимости, свой автор, который давно уволился. История с бэкдором в библиотеке xz-utils в 2024 году показала цену зависимостей: маленький архиватор едва не открыл удалённый доступ к серверам крупных дистрибутивов Linux. Подключая библиотеку, вы наследуете весь её код и весь код её зависимостей.

Исследователи спорят, растёт ли плотность уязвимостей на тысячу строк вместе с размером программы. Но с главным не спорит никто: чем больше кода, тем больше в нём находят.

Приложение в Интеграме — описание, а не программа

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

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

Даже там, где в приложении есть «логика», она остаётся в рамках ядра:

• Права проверяются на сервере, на каждой записи. Если у пользователя нет доступа, поле не прячется в интерфейсе — сервер его просто не отдаёт. Подробнее — в базе знаний.
• Действия кнопок и триггеры — это формулы и условия, которые считает собственный вычислитель ядра. Произвольный серверный код из описания приложения не запускается.
• Триггер пишет с правами пользователя, который его запустил: обойти права через автоматизацию нельзя. Длина цепочки триггеров ограничена, задачи для ИИ-агента ограничены по частоте.
• ИИ-агент, собирающий приложение, тоже не пишет код. Он меняет описание через те же механизмы и упирается в те же права. Если сравнивать с вайб-кодингом, разница принципиальная: модель не может «случайно» оставить SQL-инъекцию в коде, которого нет.

Что это даёт стратегически

Поверхность атаки не растёт вместе с числом приложений. Десять приложений или сто — снаружи по-прежнему одно ядро. Каждое новое приложение в классической схеме — это новый код, новые зависимости и новый объём проверки. Здесь — новая строка в описании.

Одно исправление закрывает всё сразу. Обновили ядро — защищены все приложения, включая те, о которых никто не помнит. Не бывает «забытого приложения на старом фреймворке», которое три года никто не обновлял.

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

Нет дерева зависимостей у приложения. Приложение не тянет за собой пакеты из npm или PyPI, а значит, его нельзя заразить через подменённую библиотеку.

Почему «написать безопасную ОС» — это другая задача

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

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

Интеграм заходит с другой стороны. Мы не меняем основание, а уменьшаем объём кода над ним: логика приложений переезжает из программ в описание, которое исполняет одно ядро. Эти подходы не конкурируют, а складываются: защищённое основание и минимум прикладного кода над ним.

Честно про границы

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

Монокультура. Ошибка в ядре затронула бы все приложения сразу. Поэтому ядро и держат под самым строгим контролем. И то же свойство работает в обратную сторону: исправление тоже доходит до всех сразу.

ОС, веб-сервер и СУБД никуда не деваются. Интеграм не отменяет уязвимости в операционной системе. Он убирает самый пёстрый и плохо контролируемый слой — собственный код приложений. Основание по-прежнему нужно обновлять: в облаке это делаем мы или хостер, при установке в контур заказчика — ИТ-служба компании.

Главный риск смещается в настройку прав. Если роли выданы «с запасом», платформа честно выполнит то, что разрешено. Безопасность приложения на Интеграме — это точность прав и правил, а не надежда на код. Зато эту настройку видно целиком и её можно проверить.

Дописанный код — снова код. Своя интеграция, внешний скрипт или отдельная страница поверх API снова становятся поверхностью атаки, и к ним применимы обычные требования к проверке.

---

Число уязвимостей растёт вместе с количеством кода, и большая их часть — не в ядрах систем, а в приложениях и плагинах вокруг них. Интеграм убирает этот слой: приложение становится описанием, которое исполняет одно проверенное ядро с серверной проверкой прав. Приложений может быть сколько угодно, а код, который нужно защищать, остаётся тем же. Про защиту данных от потери, шифрование и размещение в контуре заказчика — в статье «Безопасность и отказоустойчивость Интеграма».