Ставка Klarrio на безопасность by Design: почему соответствие требованиям — это не цель

Создание защищённого программного обеспечения напоминает электромонтаж в доме. Можно сделать всё правильно, пока стены ещё открыты, когда электрик работает бок о бок с архитектором, или подождать, пока семья въедет, и потом вскрывать штукатурку в поисках неисправности. Оба подхода в итоге дают работающий свет. Но только один из них позволяет спать спокойно, и только один укладывается в бюджет. Новая белая книга Klarrio — это, по сути, развёрнутый аргумент в пользу того, что индустрия раз за разом выбирает второй вариант, а потом удивляется, когда проводка начинает гореть.

Что произошло

Klarrio опубликовала белую книгу о безопасности by design в разработке облачного программного обеспечения, и центральный тезис звучит острее обычного вендорского материала. Как сообщает Techzine Global, компания утверждает: соответствие регуляторным требованиям должно быть результатом надёжных практик безопасности, но никак не их главной причиной. Формальное соблюдение требований, по их словам, создаёт ложное ощущение безопасности, тогда как реальные риски тихо остаются за кадром.

Общий фон выглядит мрачно. По прогнозам, к концу 2025 года глобальный ущерб от киберпреступности превысит $1,2 триллиона в год. Инструменты атак на основе ИИ снижают порог входа для злоумышленников, а всё то, для чего раньше требовалась целая команда — дипфейки для фишинга, автоматизированные инструменты взлома — теперь доступно любому, у кого есть браузер и дурные намерения.

В эту картину вписывается волна европейского регулирования. Директива NIS2 и Закон ЕС о киберустойчивости (Cyber Resilience Act) обязывают организации принимать проактивные меры безопасности, и Klarrio считает, что большинство компаний просто тонут в этом потоке. Белая книга предлагает иную модель: безопасность на основе рисков, где приоритеты определяются угрозами, наиболее актуальными для реальной деятельности конкретной организации, а не тем, какой столбец в очередном фреймворке оказался пустым.

В подтверждение своей философии Klarrio описывает свою Security Framework, работающую с тремя ролями — синей, красной и фиолетовой командами — а также программу Security Champions, запущенную в начале 2025 года, чтобы системно встроить культуру безопасности в процесс разработки. Ключевой экономический аргумент, от которого должен встрепенуться любой финансовый директор: встраивание безопасности добавляет к стоимости разработки порядка десяти процентов, тогда как добавление её постфактум может обойтись в десять-пятнадцать раз дороже.

Техническая анатомия

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

Доводы об открытости и скорости разработки с открытым кодом реальны и давно отточены, но обратная сторона — поверхность атаки, которая увеличивается каждый раз, когда кто-то выполняет npm install или подтягивает свежий Helm chart. Любой, кто провёл воскресное утро, разбираясь с CVE в транзитивной зависимости, знает эту схему: уязвимость находится не в написанном вами коде, а в коде, которому вы доверились тремя уровнями ниже. Ответ Klarrio — критерии отбора, применяемые до того, как компонент вообще попадает на платформу. Это скучная часть безопасности цепочки поставок, которую никто не выносит на слайды для конференций.

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

Добавьте поверх этого программу Security Champions — и вы получите попытку перенести ответственность за безопасность из центральной команды в продуктовые группы. Это важно, потому что разработчики, пишущие Terraform и манифесты контроллеров, — единственные, кто способен принимать решения по безопасности с той скоростью, которой требует облачная разработка. Центральная команда, проверяющая каждый мерж, — это архитектурный паттерн, подаривший нам шестимесячные циклы релизов, и никто не собирается к нему возвращаться.

Риск-ориентированный подход — самая честная часть фреймворка. NIS2 и Cyber Resilience Act написаны языком обязательств, но угрозы не читают директивы. Платёжная платформа и контентный сайт сталкиваются с совершенно разными противниками, и притворяться, что это не так — верный путь к ситуации, когда форма входа закрыта на все замки, а admin API открыт нараспашку.

Кто пострадает

Больше всего под удар аргументов Klarrio попадают команды, которые последние полтора года выстраивали программы соответствия NIS2 и Cyber Resilience Act, воспринимая их как цель, а не как минимальную планку. Особенно уязвимы регулируемые отрасли — финтех, iGaming, платёжные системы, SaaS, смежный с критической инфраструктурой. Когда чек-лист аудитора становится дорожной картой инженерного отдела, вы оптимизируетесь под аудит и теряете нить модели угроз.

Сильнее всего давление ощущают платформы, где преобладает открытый исходный код. Если семьдесят-девяносто процентов вашего стека — заимствованный код, ваша безопасность — это по сути ставка на дисциплину других людей при выпуске релизов. В большинстве инженерных организаций выбор зависимостей воспринимается как вопрос удобства для разработчиков: удобный ли API, читабельна ли документация, много ли звёзд на GitHub. Модель Klarrio требует рассматривать это как решение в области рисков — а значит, кто-то старший должен сказать «нет» популярной библиотеке, потому что её мейнтейнер работает нерегулярно. Это тяжёлый разговор, и в большинстве команд нет никого, кто готов его вести.

Ближайшие девяносто дней покажут, кто серьёзен, а кто просто делает вид. CTO, которые тихо надеялись, что NIS2 — это история про бумаги, обнаружат, что их советы директоров читали те же публикации, что и аудиторы. Все, кто управляет B2B-платформой для клиентов из ЕС, начнут видеть в опросниках по закупкам формулировки про безопасность by design, и ответ «мы соответствуем NIS2» перестанет быть достаточным, когда следующий вопрос звучит как «покажите вашу модель угроз».

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

План действий для инженерных команд

Начните с честного аудита зависимостей. Не Snyk-отчёта, а реального разговора о том, у каких из ваших семидесяти-девяноста процентов open-source компонентов есть настоящий мейнтейнер, реальный процесс раскрытия уязвимостей и стабильный ритм релизов. Подход Klarrio с критериями отбора — правильный паттерн: фильтруйте компоненты на входе, а не в момент инцидента.

Создайте функцию фиолетовой команды, даже если у вас нет бюджета на отдельную красную. Роль, которая реально меняет положение дел, — это переводчик: человек, чья работа — обеспечить превращение результатов пентеста в инженерные задачи. Без этой роли результаты работы красной команды превращаются в PDF, который никто не читает.

Выберите модель Security Champions и обеспечьте её ресурсами по-настоящему. Один инженер на команду с выделенным временем, а не волонтёрский список, который разваливается под давлением спринта. Цель — сделать безопасность свойством того, как команда пишет код, а не воротами, через которые код проходит.

Переосмыслите нарратив про соответствие требованиям изнутри наружу. Наложите свои обязательства по NIS2 и Cyber Resilience Act на реальную модель угроз, а не наоборот. Если модель угроз порождает контроли, которых также требует регулирование, — соответствие достигается автоматически. Если вы начинаете с регулирования, вы получаете папку с документами.

И сделайте расчёты прямо перед советом директоров. Десять процентов в процессе разработки против десяти-пятнадцати раз после — это самое полезное число во всей белой книге. Вынесите его на слайд.

Ключевые выводы

• Основной аргумент Klarrio: соответствие требованиям — это побочный эффект хорошей безопасности, а не конечная цель. Формальные программы по NIS2 и Cyber Resilience Act создают ложное ощущение защищённости.
• Экономика очевидна: безопасность, встроенная в проектирование, обходится примерно на десять процентов дороже при разработке, тогда как ретрофитинг может обойтись в десять-пятнадцать раз дороже.
• Современные платформы на семьдесят-девяносто процентов состоят из open-source компонентов — от Kubernetes до экосистемы CNCF. Это и есть ваша реальная поверхность атаки, и большинство команд её не контролируют.
• Модель синей/красной/фиолетовой команд работает только в том случае, если фиолетовая функция действительно замыкает цикл между обнаружением уязвимостей и выпуском исправлений.
• Программа Security Champions, запущенная Klarrio в начале 2025 года, — культурный паттерн, достойный копирования: переносите ответственность в продуктовые команды вместо того, чтобы создавать узкое место в центральной команде.

Вернёмся к полупроведённому дому. Индустрия десятилетие притворялась, что можно сначала въехать, а потом пустить электрика работать вокруг мебели. Белая книга Klarrio напоминает: цена этого выбора не теоретическая — это множитель, и регуляторы вот-вот начнут снимать показания счётчиков.